mlton self-compile

[Jagannathan, Suresh]

Interestingly, there's an active compiler group there
that's interested in RSSA-style issues.  In general, they
don't have a lot of representation in functional language
implementations, and it seems that they'd like to build
up some strength there.

I'll keep you posted.

-- sj

-----Original Message-----
From: Stephen Weeks [mailto:sweeks@acm.org]
Sent: Friday, March 15, 2002 12:27 PM
To: MLton@sourcelight.com
Subject: mlton self-compile



> I've been invited to give a talk on MLton at Toronto as part of my
> job-hunting quest.

Cool.  Who is there that might be interested?

> I was going to use the released benchmarks, but
> notice that there aren't any numbers that show the cost of
> compiling/running MLton on any of the other systems.  I guess the G0
> number is SML/NJ, but I was wondering if you tried a self-compile
> using the Kit or Moscow-ML.

Sometimes the G0 number is running an SML/NJ compiled MLton,
sometimes (usually, these days) it is a previous version of MLton.

It is impossible to compile MLton with Moscow ML because of
performance problems in their signature elaboration.

It is probably possible with the Kit, but I haven't tried in years.
It would definitely be neat if you want to try it.  To do so, you need
to build a mlton-stubs-in-kit directory that makes the Kit basis look
like the MLton basis.  Anyways, their current code generation is so
horrible that the resulting executable will probably run 5-10x slower
than MLton.

Separately compiling MLton with SML/NJ takes about the same amount of
time as whole-program compiling MLton with MLton (e.g. about 5 minutes
on my machine).  I don't really know, but I would guess that the
resulting executable runs about 5 times slower than a MLton compiled
MLton.   In order to get reasonable comparison, you need to change the
value of MLton.debug in lib/mlton-stubs-in-smlnj to false (since that
is the default in MLton).  Actually, to be really fair, you need to
undo a lot of the stubs stuff because it makes SML/NJ use 32 bit
integers and words, which I'm sure hurts.

Whole-program compiling MLton with SML/NJ takes hours (4 or 5 IIRC)
and 1G of memory.  Maybe even worse with 110.39 based on a recent
comp.lang.ml post.  I've not benchmarked the resulting executable, but
my guess would be that it is 1.5-2X slower than MLton.