This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 compile speed regression - AN ANSWER
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? :)