[mercury-users] What Triggers a GC?

[Fergus Henderson]

On 21-Oct-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> 
> Back on this benchmarking thing...  I've getting fluctuating results.  At
> one point (using rotd-08-13 I think) I was getting within a factor of
> 2.4 or so of the speed of the C implementation.  Now, using rotd-10-17,
> I'm down to about 3.2, or 2.9 if I'm willing to turn GC off (which is
> probably cheating).  Most odd.

This is probably related to our recent changes affecting the
inlining heuristics.

rotd-10-17 also had a bug which causes us to generate a bunch of
read-only data that is not needed.  That will probably give you a small
slowdown due to cache effects.  That has been fixed in rotd-10-21.

Our regression tests catch most bugs, but we don't have any automated
performance tests in our test suite, since it's a bit hard to determine
success/failure criteria, and so these kinds of performance bugs do
slip into our rotd releases on occaision.

> Anyway, io__report_stats told me that 4 MBytes of heap had been used and
> 7 odd GCs had taken place.  This really is surprising to me because I've
> gone to some lengths to make sure the code doesn't allocate any memory.  So
> I popped the code through the profiler, trying to find where this memory is
> going, but no dice - mprof agrees with me that nothing is being allocated
> (and I've checked that I'm not using any of the mprof-invisible predicates
> Fergus listed a couple of weeks ago).

There may still be a few things that mprof does not account for that
weren't in my list.  I'll look into that.

> So what causes a GC to take place?

Memory allocation.

> For example, a little bit of code like
> 
> set_code(Codes0, Hash, Key, Code) = Codes :-
>         Codes1 = array__set(Codes0, Hash, Key),
>         Codes  = array__set(Codes1, Hash + hash_table_size, Code).
> 
> which I would expect to compile to just a handful of instructions (with
> array bounds checking turned off), along the lines of
> 
> 	  Codes0[Hash] = Key;
>         Codes0[Hash + hash_table_size] = Code;
>         Codes = Codes0;
> 
> but it actually compiles to
...
>         call_localret(ENTRY(mercury__fn__array__set_3_0),

array__set is not being inlined here.
Clearly it ought to be.  That is a performance bug.
I'll look into that one too.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------