[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.