GCC 3.3 compile speed regression - AN ANSWER

[Lars Segerlund]

  I checked with some source , microsofts compiler, the intel compiler 
and an old lattice compiler, gcc is somewhere around 4-6 times slower 
than these compilers, now this was a really bad test from benchmarking 
perspective, but still Tubo-C and Turbo-C++ did a lot of lines/sek.

  So I think gcc need's have compilation speed as a long term goal.

  ( IMHO ) Lars Segerlund.

Marc Espie wrote:
> In article <3E483557.8049885F@OARcorp.com> you write:
> 
>>
>>Steven Bosscher wrote:
>>
>>>Op ma 10-02-2003, om 21:54 schreef Phil Edwards:
>>>
>>>>On Monday 10 February 2003 01:58 pm, Steven Bosscher wrote:
>>>>
>>>>>>Op ma 10-02-2003, om 20:47 schreef Mike Stump:
>>>>>>
>>>>>>>On Monday, February 10, 2003, at 06:31 AM, Michael S. Zick wrote:
>>>>>>>
>>>>>>>>Who is complaining?  If we can define the group for which this is a
>>>>>>>>concern, then perhaps we can define a way to satisfy that group.
>>>>>>>
>>>>>>>Apple is complaining on behalf of our users.
>>>>>>
>>>>>>The thread on linux-kernel was also quite clear.  Some people even
>>>>>>discussing a fork.
>>>>
>>>>For speeding up compilation times?  What changes would they make in such
>>>>a fork that couldn't be made in the mainline compiler?
>>>
>>>I don't know, but if it had made sense I would probably have
>>>remembered.  But they discussed just about every free and nonfree C
>>>compiler and how it could/would/should help them get a kernel compiled
>>>faster.
>>>(Somebody complained that it took him 20 minutes to compile a kernel,
>>>that was unacceptable to him :-)
>>
>>Something deep inside me can't resist saying "buy a faster machine" or
>>"think more, compile less". Full sarcasm mode on. 
> 
> 
>>Seriously, when compile times were uniformly slow, batch, or overnight
>>we old timers put a lot more thought into fixing problems on paper.  
>>These young whipper snappers just want to let the computer do
>>everything.
> 
> 
> It will probably make a lot more sense if I post numbers for you.
> 
> On my PIII 1.2GHz box, building an OpenBSD kernel takes 5 minutes.
> the basic source distribution takes about 1 hour, XFree roughly 40 minutes.
> The whole ports tree takes about one day.
> 
> About half of it is spent in qt3, and kde.
> 
> kdelibs and kdebase each take over an hour to build.
> 
> We are talking gcc 2.95.3.
> 
> On the amiga next to it (68040@40MHz), building a generic kernel takes 
> 3 hours. The basic source distribution takes slightly less than two days. 
> I don't even a good idea what the time would be for the ports tree, but 
> you can figure it out.
> 
> The Sun3 that Miod Vallat uses has a 68030 (I think) and it takes slightly
> over one week to build the whole source distribution.
> 
> Now, you have to double these numbers for gcc 3.2, and it's even worse for
> more recent versions.
> 
> Basically, recent gcc kill old boxen. Maybe you feel those should be dead.
> Some people disagree. And cross-compiling does not really solve the problem:
> building stuff is still a very good way to exercise a system and shake out
> bugs.
> 
> Bottom line is, recent gcc are slowly killing linux and unix distributions 
> on slow hardware, because they force cross-compilation, and cross-compilation 
> does not find bugs.
>