Re: Faster compilation speed

[Jeff Sturm <jsturm at one-point dot com>]

On Wed, 14 Aug 2002, Fergus Henderson wrote:
> On 13-Aug-2002, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:
> > Has anyone ever tested gcc with its own GC disabled
> > but boehm-gc enabled?  OK, this is a red herring question.  Even if
> > performance was greater, portability concerns are what caused the
> > decision to build a new custom scan-GC verses reusing boehm-gc...
>
> Yes, but GCC could use the Boehm GC on systems which supported it,
> if the Boehm GC was faster...
>
> I think this would be a very interesting experiment.

I tried it a year or so ago on the 3.0 sources.  Had a ggc-boehm.c
operating mostly conservatively.  Using ggc's marking infrastructure may
be possible, but seemed difficult to interface with boehm-gc.

One of the difficult problems is that boehm-gc doesn't want to follow
pointers through ordinary (malloc'ed) heap sections.  So I overrode
malloc/free to use the GC methods.

I made ggc_collect() a no-op, since boehm-gc knows when it needs to
collect, and overriding its heuristics doesn't really help matters anyway.

Overall it seemed to shave a few minutes off the bootstrap time, but also
increased memory usage considerably.  I expected this.  Tuning frequency
of collection typically amounts to a size/speed tradeoff.  I don't think
conservativeness was an important factor in heap size.

It could've been interesting to try incremental/generational collection.
I didn't do that.

My impression based partly on that experiment is that
allocation & collection overhead in GCC is not all that substantial, and
the real gains are going to be elsewhere, i.e. improving temporal locality
as has been discussed lately.  That isn't a problem that any GC is going
to fix.  (I also don't think it's a necessary evil of GC, rather it's how
you use the allocator... e.g. creating too many short-lived objects is a
bad thing.)

Jeff