MLton vs OCAML

[Stephen Weeks]

> I'm some what surprised.  Any idea what MLton isn't doing that OCaml is?

Here's some info.  First, BTW, the numbers I sent earlier were slightly slow for 
MLton, since I compiled without -DMLton_safe=0.  Here are the new numbers.

		OCAML	MLton SML/NJ		MLton alloc 
		time	time  time		 M	M/s
holes		 1.7	 5.6	12.4		138	25
fov		 1.4	 2.0	11.3		 66	33
intercyl	 1.6	 2.3	13.5		 48	19
snowgoon	 2.9	 3.9	24.4		 33	 8
dice		 3.8	 5.4	29.1		102	19
golf		 1.6	 3.4	11.5		 70	20
cone-fractal	 3.8	 4.8	25.4		 48	 9
large		 4.3	 3.4	13.2		 60	15
pipe		 5.4	 5.1	32.4		114	21
chess		15.9	19.3	99.4		151	 7
fractal		12.1	10.3	86.4		 19	 2

geom-mean	 3.5	 4.8	23.9


Here are the results of profiles for the benchmarks.  I've included the top 3
cps functions for each benchmark.  Below, I have a brief description of what the
function does.  Depending on the benchmark, there are 5 different functions that
dominate the time, and some have the time spent fairly equally among several
functions.  The three worst offenders, holes, dice, and golf, are slow because
they are spending a lot of time in the evaluator (x_897), which shouldn't
happen.  Looking at the CPS code, I see that the flattener has flattened the
evaluator into a 21 argument function.  This is clearly a mistake, and is
killing MLton.  Fixing that problem alone should make MLton comparable to OCAML
across the benchmarks.

holes.gml
x_897                                   59.16%
x_2379                                   9.34%
**C overhead**                           9.34%

fov.gml
x_2379                                  32.60%
x_4931                                  12.71%
x_4115                                   9.39%

intercyl.gml
x_2379	                      21.05%
x_4944                        21.05%
x_4151                        18.66%

snowgoon.gml
x_4918                                  21.64%
x_4151                                  16.89%
x_4115                                  14.25%

dice.gml
x_897                                   44.02%
x_2379                                   9.33%
x_4151                                   6.41%

golf.gml
x_897                          41.03%
x_2379                         10.00%
x_4151                          7.24%

cone-fractal.gml
x_4918                                  43.72%
x_4247                                  17.57%
x_2379                                  10.25%

large.gml
x_4151                        16.14%
x_4944                        15.92%
x_2379                        12.11%

pipe.gml
x_4151                                 17.64%
x_4944                                 14.03%
x_4918                                 12.63%

chess.gml
x_4151                                  20.55%
x_4115                                  19.30%
x_4918                                  17.11%

fractal.gml
optimize_rec_75               71.40%
x_4918                         9.05%
x_5638                         5.06%


x_897	evaluator					line 64 of eval.sml
	all symbolic -- horrible flattenning
x_2379  main loop of ray tracer				line 825 of render.sml

x_4918	does a ray intersect a bounding sphere?		line 594 of render.sml
	all doubles -- looks pretty optimal

x_4151  matrix times vector				line 98 of matrix.sml
	all doubles -- looks pretty optimal

optimize_rec_75
	scene optimizer
	recursive descent of scene

> How much of a pain was converting it to SML from OCaml?

Pretty painful because they have so much more syntax for stuff (like for loops,
array subscripting) and because they have more built in libraries.  It took me
about 5 hours to translate 1000 lines of code.