Team PLClub ICFP entry -- comparing the performance of OCAML and SML
John H. Reppy
jhr@research.bell-labs.com
Thu, 12 Oct 2000 17:05:30 -0400
I've done a quick de-camlification of this program, which seems to improve
its performance under SML/NJ by a factor of 2 or more on the chess.gml
example (733MHz PIII; SML/NJ 110.29). My changes were:
1) use Unsafe.Array.{sub,update} where CAML is using unsafe array
operations.
2) replace curried arguments by tuples.
3) replace the inner loop and reference cell in the matrix multiplication
by a tail-recursive function and function parameter.
I think that this example illustrates the danger of making casual
performance comparisons. There are clearly stylistic differences
in the most efficient style of SML programming vs the most efficient
style of CAML programming.
The CAML version of this program is still faster than the SML/NJ version,
but the difference is 30% (instead of a factor of 3). I suspect that
there are other changes to the coding style that could be made to improve
the performance under SML (for example, I'd use a record to represent the
transformation matrix, instead of an array).
W.r.t. the revised numbers below, the numbers for SML/NJ 110.25 on fractal
and large look suspect.
- John
In message <14822.6721.428985.597681@eponym.epr.com>, "Stephen Weeks" writes:
>
>
> At the request of several SML/NJ developers, I reran the benchmarks with some
> newer versions of SML/NJ: 110.25 and 110.29. Here are the results.
>
> 110.9.1 110.25 110.29
> OCAML MLton SML/NJ SML/NJ SML/NJ
> holes 1.8 3.5 6.4 4.7 5.0
> fov 1.5 2.1 6.1 4.8 4.4
> intercyl 1.6 2.4 8.9 6.5 6.0
> snowgoon 2.9 4.0 13.2 8.6 8.4
> dice 3.9 5.7 15.5 11.3 10.8
> golf 1.5 2.5 5.8 4.3 4.2
> cone-fractal 3.7 4.9 13.0 9.0 8.4
> large 4.3 3.1 3.9 3.9 7.6
> pipe 5.4 5.3 17.9 13.2 11.3
> chess 16.0 17.8 60.4 40.4 38.6
> fractal 12.2 8.7 40.6 26.9 41.1
>
> geom-mean 3.6 4.4 12.2 9.0 9.5