On Thursday 31 May 2007 06:50:05 Yuanchen Zhu wrote:
> The performance numbers were as following:
>
> Ocaml (unsafe) : user: 39.674s, real: 41.356s
> MLton (safe):  user:  17.981s, real: 21.968s

You may be interested to know that there are no optimizing SML compilers for 
AMD64, which is a much better platform for numerical work:

  http://www.ffconsultancy.com/languages/ray_tracer/results.html

OCaml is over 60% faster on this benchmark.

Having said that, I notice that twice as many people are downloading the x86 
demos on my site compared to the x64.

> let hconvolve kern (img:t) r =
>   let sup = Array.length kern - 1 in
>   let img' = create (size img) in
>     for y = 0 to height img - 1 do
>       for x = 0 to width img - 1 do
>         let s = ref 0.0 in
>           for i = 0 to sup do
>             let (kx, ky) = kern.(i) in
>               s := !s +. ky *. getReflected img y (x + kx) 1.0 r

I can think of various ways to rearrange this that might help performance.

> The new running time is:
>
> Ocaml (unsafe) : user: 21.477s, real: 23.366s

What is the running time for safe OCaml?

> 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?

> Although note that the MLton version has array-bound check enabled and
> used the two-line high order function version of hconvolve.

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

> So the moral of the story: To use Ocaml for numerically intensive
> work, code in C style in the inner loops.

Absolutely.

> 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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e