SML numerical benchmark and MLton

[Stephen Weeks]

> I just wanted to drop you a note saying that the new version
> of SMLapl is out. Finally I had time to revise the code and
> find what was making SML/NJ be so slow and it was just two
> stupid complex numbers -- I had to inline the code myself.
> 
> The new code and the new benchmarks are at the same place
> 
> 	http://www.arrakis.es/~worm/smlapl.tgz

Thanks for the pointer.
 
> Now SML/NJ-compiled code is 1.7 times slower than
> MLton.

I must admit I am a bit curious why you're going to so much effort to
speed up SML/NJ (include files, manual defunctorization, inlining,
...), given that you can just use MLton to generate your "production"
code.  I would be interested to hear if any of your manual
optimizations speed up the MLton generated code as well.

> Also, measures now take place over several iterations
> and so the GC might be important --but that's more realistic
> anyway.

You might be interested in the gc-summary command line option that one 
can give to MLton generated executables.  For smlapl, it shows that
the GC time is negligible.

% ./tests @MLton gc-summary --
Real tensors: (+, *, /, +*, *+)
100      3     3     3    41    52
200     15    13    12   343   393
300     35    29    29  1693  1888


Real tensors: (+, *, /, +*, *+)
100      5     7     5   136   107
200     28    26    33   960  1059
300     74    65    75  3620  4461


stack size(bytes): 4,096
max semispace size(bytes): 28,839,936
GC time(ms): 1,720 (2.5%)
number of GCs: 75
bytes allocated: 736,163,740
bytes copied: 78,629,948
max bytes live: 3,604,848