[MLton] self-compile blues

Stephen Weeks MLton@mlton.org
Wed, 15 Sep 2004 17:22:03 -0700


> After racking up 36 minutes of CPU usage over a period of an hour and a
> half and causing about 7 million pageins and pageouts, mlton-compile has
> only gotten to removeUnused2 in closureConvertSimplify.  This is during
> the self-compile in make all-no-docs.
> 
> Is this normal for a relatively fast (1 GHz) machine with a fairly
> sizeable memory (1 GB)?

It seems slow.  But I haven't run MLton built by the C codegen in a
while.  The usual rule of thumb is it's a factor of two slower than
the native codegen.  Factoring everything in and making a wild guess,
I'd think you could do the pre codegen in under 20 minutes.

> 1) How much memory does a self-compile really need?

You might be able to squeeze by with a heap size of 512M.

> 2) What, exactly, does ram-slop affect?  Is it only the GC'd heap, or is
> the whole size of the process taken into account?

ram-slop is multiplied by the total RAM size to get the maximum size
of the GC'd heap.  It doesn't take anything else into account.

You could also use fixed-heap 600m (or whatever size) instead of
ram-slop, since we're experimenting.