This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Fergus Henderson <fjh at cs dot mu dot OZ dot AU>
- Cc: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>, <davem at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Wed, 14 Aug 2002 10:36:05 -0400 (EDT)
- Subject: Re: Faster compilation speed
On Wed, 14 Aug 2002, Fergus Henderson wrote:
> On 13-Aug-2002, Loren James Rittle <email@example.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