All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@arcor.de>
To: Andrew Morton <akpm@digeo.com>,
	Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Cc: cw@f00f.org, torvalds@transmeta.com, geert@linux-m68k.org,
	alan@lxorguk.ukuu.org.uk, perex@suse.cz,
	linux-kernel@vger.kernel.org
Subject: GCC speed (was [PATCH] Isapnp warning)
Date: Sun, 22 Jun 2003 15:22:29 +0200	[thread overview]
Message-ID: <200306221522.29653.phillips@arcor.de> (raw)
In-Reply-To: <20030621191705.3c1dbb16.akpm@digeo.com>

Hi Andrew,

On Sunday 22 June 2003 04:17, you wrote:
> Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> kernel which is 200k larger.
>
> It is simply worthless.

Recently, we did an unscientific but nonetheless informative tour through 
various optimization and compiler version questions here:

   http://marc.theaimsgroup.com/?t=105167074500002&r=3&w=2
   [RFC][PATCH] Faster generic_fls

As a result, my general impression is GCC 3.2 (and, I presume, GCC 3.3 as 
well) comes out better than 2.95.3 in terms of binary performance on x86.  I 
seem to recall there was one case in one algorithm variation on one procesor 
type where 2.95.3 won marginally, and otherwise GCC 3.2 took the trophy every 
time, sometimes by a significant margin.  I was able to get satisfactory 
performance in terms of size as well, by tweaking compile options.  (In 
general, just mindlessly setting O3 seems to work well.)

So I like GCC 3.2 in terms of code quality, at least for the limited set of 
things I've tested, but that's not the only consideration.  Current GCC is a 
whole lot better in terms of C99 compliance and produces better warnings.

As for compilation speed, yes, that sucks.  I doubt there's any rational 
reason for it, but I also agree with the idea that correctness and binary 
code performance should come first, then the compilation speed issue should 
be addressed.  I hope the gcc team does make it a priority at some point.  
For my own part, I'm putting together a cluster to address the compilation 
speed issue, i.e., I don't really care about it.  Even a dual PIII turns in 
satisfactory results in that regard, or a single K7.

Regards,

Daniel


  parent reply	other threads:[~2003-06-22 13:07 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-15 18:36 [PATCH] Isapnp warning Geert Uytterhoeven
2003-06-21 12:31 ` Alan Cox
2003-06-21 14:59   ` Geert Uytterhoeven
2003-06-21 15:04     ` Sean Neakums
2003-06-21 19:51     ` Andrew Morton
2003-06-21 23:53       ` Linus Torvalds
2003-06-22  0:11         ` Arnaldo Carvalho de Melo
2003-06-22  1:41           ` Chris Wedgwood
2003-06-22  1:43             ` Arnaldo Carvalho de Melo
2003-06-22  2:17               ` Andrew Morton
2003-06-22  2:27                 ` Chris Wedgwood
2003-06-22  2:59                   ` Andrew Morton
2003-06-22  5:50                     ` Herbert Xu
2003-06-22  3:43                 ` Martin J. Bligh
2003-06-22  4:24                 ` Paul Mackerras
2003-06-22  8:32                   ` Geert Uytterhoeven
2003-06-22 13:34                     ` Daniel Phillips
2003-06-22  5:39                 ` gcc 3.3: largest *and* smallest kernels (was Re: [PATCH] Isapnp warning) Barry K. Nathan
2003-06-22 11:31                   ` Alan Cox
2003-06-22 13:22                 ` Daniel Phillips [this message]
2003-06-22 17:32                   ` GCC speed (was " Andrew Morton
2003-06-22 17:56                     ` Linus Torvalds
2003-06-22 18:58                     ` Henning P. Schmiedehausen
2003-06-22 19:12                       ` Sam Ravnborg
2003-06-22 19:13                       ` Andrew Morton
2003-06-22 19:32                         ` Henning Schmiedehausen
2003-06-22 19:51                       ` Adrian Bunk
2003-06-22 19:12                     ` Daniel Phillips
2003-06-23  1:05                     ` Larry McVoy
2002-01-04 11:32                       ` Pavel Machek
2003-07-17 10:18                         ` Christoph Hellwig
2003-07-17 10:23                           ` Jakub Jelinek
2003-07-17 10:27                             ` Christoph Hellwig
2003-06-22  8:49               ` [PATCH] Isapnp warning Russell King
2003-06-22  8:39             ` Jörn Engel
2003-06-22 14:07   ` Daniel Phillips
2003-06-22 15:00     ` Jan-Benedict Glaw
  -- strict thread matches above, loose matches on Subject: below --
2003-06-22 19:03 GCC speed (was [PATCH] Isapnp warning) John Bradford
2003-06-22 20:07 John Bradford
2003-06-22 20:27 ` Michael Buesch
2003-06-23  7:40 John Bradford
2003-06-23 13:17 ` Larry McVoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200306221522.29653.phillips@arcor.de \
    --to=phillips@arcor.de \
    --cc=acme@conectiva.com.br \
    --cc=akpm@digeo.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=cw@f00f.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@suse.cz \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.