[m-dev.] LLDS accurate GC status

[Fergus Henderson]

On 14-Oct-2003, Michael Day <mikeday at yeslogic.com> wrote:
> 
> > I did some speed comparisons of the compiler built in asm_fast.agc with -O2,
> > and it gets about a 25% improvement compared to the asm_fast.gc -O2 version,
> > and a 20% improvement compared to the hlc.gc -O5 version that is
> > installed on ceres (all using gcc 2.95.4).
> 
> Wow! That is fantastic :)
> 
> Is this speed up a recent phenomenon?

Yes.

> (I had the impression some how that
> the last benchmarks showed accurate garbage collection to be slower than
> the conservative collector).

Accurate GC is slower than the conservative collector when used with the
high-level back-end.  The reason is that with the high-level back-end,
we don't control register allocation; in order to keep track of the
locations of pointers, so that they can be traced and updated by the
collector, we need to take their addresses, which prevents the C compiler
from putting them in registers.  So for the high-level back-end,
accurate GC inhibits register allocation.  For the low-level back-end,
we do our own register allocation (to our own virtual register set,
some of which get mapped to real registers), so we have enough
information for the GC to trace values even when they are stored in
registers.  Thus the overhead of accurate GC is much smaller for the
low-level back-end.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------