GCC 3.3 compile speed regression - AN ANSWER

[Jan Hubicka]

> On Tue, Feb 11, 2003 at 05:21:04PM -0800, tm_gccmail@mail.kloo.net wrote:
> > It depends on your evaluation metric.
> > 
> > GCC supports more targets with every release, so by that metric, it is
> > becoming better.
> 
> Linux supports more targets with each release, too.
> 
> > You're measuring quality by one criteria on a single testcase.
> > 
> > GCC has improved greatly in areas such as C++ conformance, C++ abstraction
> > reduction, Java support, and function inlining, which may not necessarily
> > be relevant to you.
> 
> But it does get worse for C project like that Linux kernel.  That was
> the whole point of the lkml thread.  And in fact people complained about
> exactly that:  gcc adds tons of fancy new features but forgets plain
> C over it (yeah, I know it's not exactly right, but sometimes it looks
> like that)
> 
> > Similarly, we can evaluate Linux quality by another criteria, such as
> > the number of lines of source code in the kernel.
> 
> Which is not a qiality criteria at all.  (not that gcc gets smaller..)
> 
> > Or for variety, you can compare 2.0.34 and 2.5.x running on an 8 megabyte
> > 386-based machine. I suspect that 2.5.x wil not run faster than 2.0.34 on
> > this machine.
> 
> actually it's the plan to at least get 2.5 running nicely on it and stuff
> like the reverse mapping VM will help that goal greatly (and yes, espececially
> small machines need lots of finetuning til 2.6).
> 
> Rather compare plain 2.0.34 with 2.5 for 2MB coldfire boxens:  2.5 runs
> nicely and 2.0 doesn't run at all..
> 
> > Well, it would be more helpful if they actually tracked down and reported
> > specific incidents rather than complaining in general.
> 
> Binary searching between 2.95.3 and gcc 3.x for compile-time regressions? :)
http://www.suse.de/~aj/SPEC contains graph with times of compilation
over quite large period of GCC development.  Perhaps someone can look
over it :)

Honza