[MLton] building mlton from the sources

[Matthew Fluet]

On Thu, 24 Jan 2008, Gergely Buday wrote:
> Hi All,
>
> http://mlton.org/SelfCompiling
>
> writes "Building with SML/NJ takes some time (roughly 10 minutes on a
> 1.6GHz machine)". I built from the latest sources with mlton-20070826
> and it took 26 minutes to run through the self-compilation cycle
> twice. I have an AMD Athlon(tm) 64 Dual Core 4200+ (it's said this is
> equivalent to 2Ghz) with 4G of RAM.
>
> Is building with mlton so slower than building with sml/nj? And, is it
> a proper result for such a machine?

Actually, that 10 minutes is probably out of date.  That is, the amount of 
code in the MLton compiler has grown since that time.  I don't have any 
real numbers handy, but from a clean checkout, it takes longer for SML/NJ 
to compile MLton once than for MLton to compile MLton once.  On the other 
hand, SML/NJ's cutoff recompilation can be much faster than MLton's whole 
program compilation if one only makes a small change to the sources. 
Your 26 minute bootstrap time sounds consistent with my experience on a 
2GHz AMD Opteron.

The major downside with compiling MLton with SML/NJ is that the resulting 
compiler is much slower.  That is, using an SML/NJ compiled MLton to 
compile MLton is painfully slow -- on the order of an hour or so on some 
machines.  I've also found that the I/O in an SML/NJ compiled MLton can be 
quite slow; I've seen upwards of 5minutes to emit a front-end IL program 
to a file.  The corresponding output with a MLton compiled MLton is less 
than a second.

However, this shouldn't be taken as a demonstration of poor performance on 
SML/NJ's part.  When compiling MLton with SML/NJ, we carefully rebind much 
of the SML/NJ provided Basis Library so that Int.int and Word.word 
correspond to Int32.int and Word32.word, respectively, (so that it matches 
what is provided by MLton) rather than the default Int31.int and 
Word31.word provided by SML/NJ.  Since SML/NJ uses boxed 32-bit 
integer/word values, there is a performance penalty.  And, as is often the 
case in a software project, we make use of various programming idoms that 
we know will be compiled well by MLton, but may not be compiled as well by 
SML/NJ.