SML numerical benchmark and MLton
Stephen Weeks
sweeks@wasabi.epr.com
Fri, 22 Oct 1999 11:51:45 -0700 (PDT)
> 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