Re: Compile performance of Linux kernels in mainline gcc

[Jan Hubicka <hubicka at ucw dot cz>]

> 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.

At the time I was testing profiledbootstrap originally, the difference
has been roughtly 10% on building binutils, 24% looks bit far off the
range here :(
It would be interesting to know oprofile of the build just for case some
of kernel sources is reproducing some nasty corner case (I would not
expect kernel sources to be significantly different from the GCC
components I use for profilng and I see similar slowdowns there too, but
anyway we might give it a try)

Honza
> 
> 
> >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
>