Re: [patch] Move loop structures to gc memory

[Alexandre Oliva <aoliva@redhat.com>]

On May 17, 2007, "Daniel Berlin" <dberlin@dberlin.org> wrote:

> On 5/17/07, Mike Stump <mrs@apple.com> wrote:
>> On May 16, 2007, at 5:47 PM, Ian Lance Taylor wrote:
>> > Putting something in GC memory unnecessarily is inevitably slower than
>> > not putting it in GC memory, if only because GC requires overhead to
>> > track objects.

>> But, the cost can be as cheap as:

> It's not that cheap right now.
> Unless you are going to make it this cheap, can we please stop
> pretending it's this cheap?

This argument seems backwards.

If our GC memory allocator is slow, this affects *every* call of
ggc_alloc.

Moving objects out of the GC pool because ggc_alloc is slow is a
local, limited fix, that merely papers over the real problem.

It seems quite obvious to me that speeding up ggc_alloc such that it's
on par with other, faster allocators, would achieve not only the
intended benefit of moving objects out of GC (except for alloca(),
which is truly unbeatable), but also speed everything else up.

Surely it is possible to allocate memory faster, since other
allocators do it, and it's not like doing so in a GC-enabling way
requires significant overhead.

Then why paper over the problem that slows all of GCC down?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}