Re: GCC 3.3, GCC 3.4

[Mike Stump <mstump at apple dot com>]

On Thursday, January 30, 2003, at 12:21 PM, Neil Booth wrote:
> As I pointed out elsewhere, changing a GC default is simply papering
> over the problem; we're not really getting any faster.
Yes, it really is faster.  It really is better.  Consider for example 
that we had the value be 2KB, and 1% increase, and someone said bumping 
it up to 30% and 8MB is wrong and just papers over the real problem.  
We'd laugh at them, just the same way I laugh at you now.

The reason why it is better, is that taken on the whole, the sum time 
of all compiles goes down and user satisfaction with build speed 
improves.

Now, if the compiler were magically made to allocate less data using GC 
during a compile, the compiler would also happen to be faster, and that 
is also good.  It is a win-win situation in that case.

If you want to prove me wrong, come up with the data that shows that 
compile times would go down, and/or that users would be less happy.  We 
can then weigh how much we want to care about a 386 with 8MB compiling 
X v the rest of the gcc users.  Personally, I say special people, 
special flags, though, it we can make it right for both sets of people, 
that is even better.  Geoff is trying the later.

> But it's worse than that - if someone later comes along with
> improvements that improve our algorithms and data structures (those are
> where the real problems lie), the new GC default is going to reduce or
> eliminate the impact of that improvement, an impact that would have 
> been
> noticeable had the GC defaults not been changed, and the improvement
> is less likely to happen.
We have two ways of fixing the problem, one trivial, and one hard, you 
suggest not fixing it the easy way, because we'd rather not fix it, 
than fix it the easy way?  [blink]

The changes are not mutually exclusive.  Both changes make gcc better.  
Each change by itself makes gcc better.

> I think it's fair to say that in all the slowdown since
> 2.95 we've never really identified anything that is causing it (apart
> from GC itself, but that doesn't apply for regressions from 3.0).
No it isn't.  I found a regression dealing with GC to the tune of, what 
was it, 10% or so.  Geoff spotted why min_expand was miscalculated and 
did the patch for it.

It is trivial to use the binary search script that finds regressions 
and plug in your favorite test case, and find the patches that caused 
the regressions.  No one has cared to do that.
Hint, good beginner project.

Also, some of the slowdown as laid at the feet of a much larger 
libstdc++, not that that is bad, it just is.  Now with PCH, maybe we 
want to have a header called <all> that includes all the normal C++ 
headers and precompile it, and switch all the normal C++ headers to 
#include <all>.
Hello world then sees a nice speed improvement.