GCC 3.3, GCC 3.4

[Devang Patel]

On Monday, February 3, 2003, at 12:04 AM, Tim Josling wrote:

>
>> 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!

Matt Austern at Apple did similar experiment by using ggc placeholder.
(same interface as ggc, no collection, allocate memory using mmap in 
chunks and
satisfy memory allocation requests from these chunks etc..).

He got around ~12% speedup for sample c++ source.

-Devang