[m-dev.] LLDS accurate GC status

[Peter Ross]

On Wed, Oct 15, 2003 at 09:49:58AM +1000, Fergus Henderson wrote:
> 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.
> 
So do you have any ideas on how to work around this for the high level
backend?
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------