GCC 3.3, GCC 3.4

[Tim Josling]

> On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote:
> > I'm interested in improving the quality of GCC.  Your statment above
> > indicates you're interested in pointing to a number and saying "look,
> > it's lower", regardless of what that means long-term.  Hell, let's
> > not free anything at all and turn GC off altogether; GCC would be 
> > faster
> > for 90% of files I imagine.
> 
> Guess what?  For smaller programs, it already does that!  So, you are 
> just describing status quo.

It is one thing to stop collecting; it is another to turn off GC. 

Tests I did last year showed that even without doing collection, gcc is slowed
down by the requirements of GC:

1. Allocating storage of similar sizes together, sacrificing locality.
2. Wasting space by rounding up allocations to the next power of 2, wasting
space and increasing working set sizes.
3. Having bits of GC code all over the place impacting code locality and
working set sizes.

Turning off GC slows down the part of the build of GCC attributable to the
xgcc/cc1/ld by 5%. 

However removing it and allocating sequentially (each allocation is next to
the previous one) reduces build xgcc/cc1/ld compile time by about 5%.

Add these together and the requirements of GC slow down the compiler by about
10% (though collecting gets half of it back)! And most compiles don't need or
benefit from it!

One possible solution is:

Use a simple contiguous allocator, up to a certain amount of memory. If that
runs out, restart the compile using ggc-page. Most compiles would not be
affected, and the few that do need GC will get it without too much overhead.
You could have an option -ggc-force to avoid the restarts.

Tim Josling