gcc and compiling speed

[Vincent Diepeveen]

At 21:05 29-2-2004 -0700, Theo de Raadt wrote:
>> Sure, as long as you do timing tests and put it in bugzilla when you do
>> it. If you can narrow down classes of slow testcases then you'll be
>> helping as opposed to adding to the noise which you are currently doing.
>
>Eric,

>On the box where you are right now, what is the speed difference
>between gcc2 compiling your kernel, versus gcc3 compiling your kernel.

>Since I can bet gcc3 is slower for you, have you submitted detailed
>test results for that?
>
>Frankly, as consumers of your compiler we don't have a clue how to
>start submitting results like you are suggesting we do.  Clearly it is
>not about test cases when we can't find anything faster!
>
>We just see one point of analysis: This new compiler is even more of a
>slug than the previous one.

IMHO the improved quality GCC delivers which will execute the code faster
is more important than the slowdown. The slower compiling speed is always
less of a concern considering the processors having become that faster.

I remember all those old GCC 2.xx snapshots crashing one after each other
at difficult code. Specint2004 still showed some problems with some code i
wrote at different compilers, not with latest gcc's though!

Yet all 2.xx versions starved from problems. All that improved. Improvement
means usually more complexity and that eats cycles.

Nevertheless lossless speeding up compile time is always good.

>But if you want, keep on ignoring what we point out... I'm sure Redhat
>keeps buying you faster machines...

Just buy a dual opteron and let it profile with 2 cpu's simultaneously with
16 registers!

That will speed it up quite some!

btw At multiprocessor BSD machines, does gcc get run using all processors
there instead of running all threads at 1 processor? If not, i know
something to speed you up quite some...