gcc and compiling speed

[Daniel Berlin]

>
> We don't believe it is restricted to just our kernel.  And we've never
> really talked about kernel compile speed, instead we measure "make
> build" time, that meaning the compilation of the full system --
> kernel, bootblocks, all the libraries, everything.  It is a giant
> source tree.

Right, so why don't you kindly do us a favor, and profile a run of gcc 
over the entire source tree, and tell us what the top functions are, 
since you don't think it's useful to preprocess pieces of source that 
have significantly slowed down, and send them to us so we can reproduce 
and fix it.

>
> A 40% slowdown from just changing compilers ... how do you explain
> that?  I explain it by saying the compiler builds the entire system
> 40% slower.
>

Has anyone disputed that it builds your source tree slower?
Or do you just like pointing it out?

> More than that, we think everything compiles slower, on all
> architectures.  There is some variance; some systems slow down more
> than others.
>

> And thus far, there's been no real evidence contrary.

For your source tree, this is true.
This is also because nobody from OpenBSD provides us with anything 
other than whining.  We ask for preprocessed sources. Nobody provides 
it.

Note that when someone like Gerald provides us with preprocessed C++ 
sources of his app that used to compile fast, and then compiled slow 
and took lots of memory, people spent significant amounts of time 
reducing the memory usage and compile time of his application

See http://gcc.gnu.org/ml/gcc/2004-01/msg01255.html for a show that 3.4 
is faster at compiling the linux kernel than 3.2 is.
Maybe you too have forgotten to disable checking.
If not, we need profiles or code that we can use to reproduce it.
>
> Perhaps the gcc people are sticking to microbenchmarks?
>
No.
Kindly explain how you expect people without access to openbsd 
machines, to profile and find the cause of the slowdowns, without, you 
know, specific examples or preprocessed source or function profiles?

> We don't know.  But they keep asking for micro-test reports... Why
> don't they compare themselves to see how much slower it is.
Because it's worthless to suggest that everyone go download a copy of 
openbsd and use it, just to see how much slower it is?
  Did i mention that no one is likely to do this?
If you want people to track down why it's slower, we need concrete 
examples of code that has slowed down in compilation speed.
Yes, we need micro-tests.  GCC is made up of many thousands of pieces 
of code.  Do you honestly think there is some single piece of code 
responsible for a 40% slowdown?  We need code that compiled fast, and 
doesn't compile fast now, so that we can attempt to fix the problem.
If you aren't willing to provide this,  at the very least we would need 
profiles showing what functions are using up most of gcc's time while 
compiling your source tree, for both gcc <old version> and gcc <new 
version>

> For
> the best impact, I recommend using a sparc64.  But an i386 or powerpc
> will show it too.
>
Nobody is going to take you up on this offer.