[MLton-devel] first benchmarks with generational gc

[Matthew Fluet]

> * The code size impact of card marking in the mutator is negligible.

Excellent, if a little surprising.

> * The run-time impact of generational gc was not very much, except a
>   couple of major slowdowns (DLXSimulator, tsp) and one major speedup
>   (nucleic).

DLXSim was written during my "purely functional" phase; it simulates
immutable arrays with (very long) lists.  An update looks like:
      fun update (IA ia, i, x) = IA ((List.take (ia, i)) @ 
				     (x::(List.drop (ia, i + 1))));
So, while there are shared tails, it's generating a lot of garbage every
cycle of the simulation.  A lot of the stuff that is tenured is likely to
be garbage the next time around.

Which doesn't explain anything ... shouldn't that be exactly the case
where a generational GC would shine?
Or, maybe it is exactly right.  The cost of (stop-and-copy) GC should be
almost exactly the same with and without generational GC, because almost
all of the reachable data will be in the nursery; i.e., we won't save much
by stoping the trace at the old-generation boundary.  But, the nursery is
half the size of the non-generational heap, so we're GCing twice as often.
Unfortunately, GC only seems to account for 22% of the benchmark, which
doesn't seem enough to double the running time.

Are the increases in compile time for the -generational {true,false}
due to the fact that that compiler was compiled from mlton-stubs.cm?



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel