This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compile performance of Linux kernels in mainline gcc
- From: "Giovanni Bajo" <giovannibajo at libero dot it>
- To: "Andi Kleen" <ak at suse dot de>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Sat, 30 Oct 2004 12:30:45 +0200
- Subject: Re: Compile performance of Linux kernels in mainline gcc
- References: <20041030070951.GA18074@wotan.suse.de>
Andi Kleen wrote:
> Quick representative results:
>
> gcc 3.3-hammer:
> 210.32user 31.62system 3:57.66elapsed
>
> 4.0 snapshot:
> 262.71user 30.50system 4:48.46elapsed
>
> 4.0 is nearly a minute slower overall than 3.3. -O2 compile
> performance is quite bad. Also the resulting kernel crashed early at boot.
While I do not necessarily agree, there have been some statements in the past
about ignoring the compile time regression at -O2. The idea is that 4.0
optimizes code much better (or: has many more optimizers) than 3.3, so we
should not care that much if compilation time goes up a little. (of course,
this does not affect 5000% regressions which are clearly bugs, etc.).
> The suse 3.3-hammer was compiled with profiledbootstrap, while
> 4.0 only got an ordinary bootstrap (I can try it later with a
> profiledbootstrap but I'm not sure I should expect much difference)
Well, yes, try again. I remember impressive numbers about profiledbootstrap. I
don't think it is going to be a 24% difference, which is the compile-time
regression we see now.
>This is 3.3:
>
> text data bss dec hex filename
>3848609 845308 512376 5206293 4f7115 vmlinux
>
>And this is 4.0-20041030:
>
>3879469 856616 499944 5236029 4fe53d vmlinux-40
>
>.text segment has grown by about 30k, data by ~11k
Was this compiled with -Os? Comparing size of binaries compiled with other
options is mostly useless since the compiler is not concerned about size that
much. Of course, if you showed a 200% regression it would be an interesting
data point, but a 0.8% increase is within noise.
One thing that you could do is to analyze better this. I suggest you to compare
sizes of single object files: I expect some files to be better and some files
to be worse. If you take the worse files and extract the worse functions from
them, you might find relatively small code snippets showing bigger regressions,
like more than 20%. Those are good candidates for bug reports. But please, do
this with -Os.
Giovanni Bajo