Re: [Caml-list] Comparison of OCaml and MLton for numerics

["Yuanchen Zhu" <yzhu@fas.harvard.edu>]

> > The new running time is:
> >
> > Ocaml (unsafe) : user: 21.477s, real: 23.366s
>
> What is the running time for safe OCaml?

Safe OCaml adds another 4.5s.

>
> > which is much in line with MLton:
> >
> > MLton (safe):  user:  17.981s, real: 21.968s
>
> What platforms and architectures did you benchmark on? May we have the code to
> benchmark it ourselves?

I am on a Pentium M 1.8GHz with 1GB mem, running Ubuntu 7.04, with
mlton_20061107 and ocaml 3.09.2. I've packed the code and uploaded it
at:

http://www.people.fas.harvard.edu/~yzhu/hdrRc.tar.bz2

Just wget it and unpack, go into the hdrRc directory, and run
./build-and-test.sh. Take a look at build-and-test.sh for the build
and test parameters.

I couldn't get Mlton to include the SMLNJ-lib's ArrayQSort module, so
I just copied the file containing it into the same directory. Also,
the Ocaml version parses its parameters (using the incredibly helpful
Arg module) so the executable requires some extra argument. The SML
version just hard code the parameters.

> You might also try an FFT-based convolution if your filter is dense.

It's true that I might be able to get better performance using FFT, or
even using a GPU based convolution, if I'm willing to invest a lot
more time and energy. But wouldn't it be nice to be able to write in
terse high-level style, but at the same time be able to compile it to
exectuable with performance close to C?

> > This brings me to the next question: is there any plan to implement
> > type specialization optimization for ocamlopt? For numerics, this is
> > really crucial if you want write both in an elegant functional style
> > and get good performance. Also, I remember reading somewhere that the
> > current code base of Ocaml is ill-suited for implementing this kind of
> > optimization. May I ask what exactly needs to be done to the current
> > code base in order to support that? I have some compiler-writing
> > background and this sounds like an interesting project to work in my
> > past time.
>
> Writing OCaml programs that generate OCaml programs is by far your best bet
> here. We use a replacement standard library that uses autogenerated code to
> eliminate boxing and perform unrolling and type specialization where
> possible.
>
> As I can autogenerate my code, I would much rather the OCaml developers
> concentrated on things that I cannot get around, like the lack of a 32-bit
> float storage type and a more efficient internal representation of complex
> numbers.

That sounds very interesting. Could you elaborate or give an example?