This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]