SML numerical benchmark and MLton

[Stephen Weeks]

> If the
> library is so slow that it takes an order of magnitude more time to obtain
> quick answers during the development time than what it takes with other
> tools (i.e. Yorick) then that is too much.

Aha.  I didn't realize that an order of magnitude would matter during
development.  Did you try MLton's defunctorizer (mlton -d)?  It runs
pretty quickly (~1000 lines/sec), and you can feed the output back
into NJ.  I suspect it'll only get you some of what you want.  Much of
the benefit is probably coming from monomorphisation.  Another way to
achieve that (using only -d) would be to change your uses of #include
into functor applications.  But your approach is really pretty
simple.

> Secondly, I must admit that none of the previous optimizations did no better
> to the performance of the MLton compiled code.

To be clear, I was interested in a comparison of
  * your original code compiled by MLton
  * your semi-automatically optimized code compiled by MLton

> It is also remarkable that while in single pass tests MLton performs as well
> as the hand-made C code (namely Yorick), when repeating the +* or *+
> operations several times and averaging one obtains larger times. I thought
> the differences were due to GC but your previous post leaves me a bit
> puzzled.

Strange.  It might be due to the code getting larger causing problems
for the C backend.  If you send me how to demonstrate the two
differences, I will investigate.

On a related note, I was curious about your comments about the speed
of Ocaml.  I was also interested if you had any code where you had
both an SML and an Ocaml version.  I recently did some benchmarking of
Ocaml and it did quite well on a few small benchmarks, and I am
looking for more code to try.  Thanks.