This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 compile speed regression - AN ANSWER
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: tm_gccmail at mail dot kloo dot net, <jsm28 at cam dot ac dot uk>, <gcc at gcc dot gnu dot org>
- Date: Wed, 12 Feb 2003 09:15:06 -0800 (PST)
- Subject: Re: GCC 3.3 compile speed regression - AN ANSWER
On Wed, 12 Feb 2003, Jan Hubicka wrote:
>
> You can take a look at http://www.suse.de/~aj/SPEC. It plots such
> lines. For SPECint score at -O2, 2.95 did 369, current GCC does 398 and
> with profile feedback 2.95 didn't supported 410. This is about 11%
> speedup. (7.8% in apples-to-apples comparsion witout profile feedback)
Well, right now suse.de doesn't seem to want to reply to me. I'd like to
see what the improvement in the gcc part of the benchmark is, since that's
imho the only actually interesting part of SpecInt.
But anyway, the improvement in general doesn't seem to be borne out on the
kernel.
> This is not complette image of the development, but I don't see the
> trend of getting bigger and slower code in post-2.95 releases
> (I agree that is has commonly been the case for eariler and partly for
> 3.0 as well).
>
> In case you notice different results, can you give the examples?
Well, the kerrnel mailing list thread started by Martin Bligh on Feb 3,
and the thing basically compares kernels compiled with gcc 3.2 with 2.95,
and finds no improvement (some things imrpoved, others deproved, all in
the noise).
But the kernel compile times went up from 46 seconds to 69 seconds (yeah,
that's on pretty beefy hardware, obviously).
That's a 50% slower compile, with no visible improvement in resulting
code quality.
NOTE! People have said that the kernel is not very amenable to
optimizations. That's likely absolutely true - probably partly because
kernels in general tend to be less optimizable than most code (lots of
dependencies, very few loops, etc).
But I bet it's also largely because the kernel has been optimized heavily
and the code tends to be "simple" for the compiler (for example, the
kernel does some profile-directed optimizations simply thanks to manual
annotation of "this error path normally never happens" etc). So it's kind
of a hard to improve a lot.
That said, at least some comparisons with the Intel compiler on an older
kernel imply that the Intel compiler improves things like UDP and TCP
latency by 10-25% on 2.4.18 (in fact, the UDP path was apparently
magically improved by up to 30%, which is damn impressive):
http://marc.theaimsgroup.com/?l=linux-kernel&m=103559880923586&w=2
so compiler code generation quality still _does_ matter. It's not as if
the code is unoptimizable.
So: 50% slower compiles from 2.95 to 3.2. With no noticeable improvement.
Linus