mlton vs NJ compiled mlton

[Stephen Weeks]

> These times are truly very fine indeed, but it really isn't fair to not count
> the gcc and as times as part of the MLton times.

Yes it is fair, when I am comparing the resulting mlton executable's running
time.  The gcc time when each executable is running is the same, 36 seconds.

> 		NJ	mlton	mlton mutator + gc
> 		----	-----	-----------------
> pre codegen	1671	239	(96 + 143)
> codegen	 666 	202	(142.16 + 60.05)
> total 	2337	441 	(238.10 + 202.66)

Notice that I did include the gcc time when I compared SML/NJ and mlton on
compile time.

> It took SML/NJ 419 seconds to separately compile mlton, while it takes mlton
> 477 seconds to compile itself.

I stand by both the compile and run times I sent.

> How do these fine times jive with what we saw from before: that MLton  didn't
> speed  MLton up by much?  Was that from back in the days when MLton was small
> enough that SML/NJ could do  a  whole-program  compilation  of  it?   Was  it
> because the new SML/NJ is worse?

I think these roughly compare with our old separately compiled ratio.  And yes,
SML/NJ used to be able to compile MLton whole-program, but that was probably
about 50,000 lines ago.

> I  can  see  from  the failure of SML/NJ doing a whole program compilation of
> MLton that you are truly regretting the fact that we don't use MLRisc.

Indeed.  I guess I should send the NJ folks a bug report.