Re: [Caml-list] OC4MC : OCaml for Multicore architectures

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

First, like everybody else, I'd like very much to try this out.
Is there any chance it could compile on Snow Leopard :-)
(I suppose it's near impossible, but still ask...)

From: Jon Harrop <jon@ffconsultancy.com>
> Visual Basic has been a *lot* faster than OCaml for several years now, not 
> least because it makes efficient multicore programming easy. Even Python is 
> beating OCaml on benchmarks now:
> 
> http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.html

IIRC, currently Visual Basic is just a "skin" for C#. You have to
write all the types, so it's rather hard to call it "Basic". And yes,
MS has invested a lot in the CLR, and that pays.

Your benchmark seems strange to me, as you are comparing apples with
oranges. Hashtables in Python are a basic feature of the language,
and they are of course implemented in C. In ocaml, they are
implemented in ocaml (except the hashing function, which has to be
polymorphic), using an array of association lists!
(Actually the pairs are flattened for better performance, but still)
What is impressive is that you don't need any special optimization to
get reasonably good performance. Actually the only tuning you need is
to start from a reasonable table size, which you didn't (never start
from 1, you will have to redo all the hashing every time the table
needs to be grown).

> Even if that were not the case, the idea of cherry picking interpreted 
> scripting languages to compete with because OCaml has fallen so far behind 
> mainstream languages (let alone modern languages) is embarrassing. What's 
> next, OCaml vs Bash for your high performance needs?

OCaml was never touted as an HPC language! The only claim I've seen is
that it intends to stay within 2x of C for most applications. (Which
is not so easy these days, gcc getting much faster.)

Actually, I believe that Philippe's point is rather different.
Making a functional language work well on multicores is difficult.
If I tell you that you just have to modify a bit your program to get a
near linear speedup, then it looks great. But in practice it is rather
having to rethink completely your algorithm, to eventually get a speedup
bounded by bandwidth, and starting from a point lower than the original
single thread program. There are applications for that (ray tracing is
one), but this is not the kind of needs most people have.

By the way, I was discussing with numerical computation people working
on BLAS the other day, and their answer was clear: if you need high
performance, better use a grid than SMP, since bandwidth is
paramount. And you have to write in C or FORTRAN (or asm), because the
timing of instructions matter. The funniest part was that those people
were working on integer computations, but had to stick to floating
point, because timing on integers is unpredictable, making
synchronization harder.

Cheers,

Jacques