Re: [Caml-list] More cores

[Jon Harrop <jon@ffconsultancy.com>]

On Friday 19 December 2008 14:04:22 Dario Teixeira wrote:
> Hi,
>
> > Is it time to start rethinking concurrency in OCaml?
> > (...)
>
> That's a recurrent topic in this list.  I'll summarise the arguments
> and save us all some time:
>
> i) Someone raises the issue that it's time for Ocaml to go multicore.
>
> ii) A few voices go "yeah!" and state that with a concurrent GC,
>     Ocaml can take over the world.  Their argument is as follows:
>
>     1) Ocaml gets a concurrent GC;
>     2) ...
>     3) Profit!

Or:

ii) People used to choose OCaml because it was fast but lack of support for 
multicores means that OCaml is no longer competitively performant for many 
tasks on today's computers.

> iii) A voice of reason notes that the devil is in step 2) above.
>      If your programming paradigm for concurrency is Threads+Mutexes,
>      then you are exposing yourself to a world of pain in race
>      conditions.  At this point someone usually links to Xavier's
>      standard speech on concurrency (which is a few years old, but
>      as poignant now as it was then).

iii) Your "voice of reason" also said that multicore computers "have never 
really taken off, at least in the general public":

http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html

> ...
> While I tend to agree with viewpoints iii) and v), I do think a healthy
> discussion on the subject of multicore is in order.  Though I suggest we
> focus the discussion on concurrency models that will allow us to take
> advantage of those multicores in a safe, sane manner: 

At this point, you need to distinguish between concurrency and parallelism.

OCaml can already handle concurrency reasonably well, particularly when CPU 
usage is low. Perhaps OCaml has a future in that specific domain but it is 
not my remit so I am not the best person to comment on this (ask Gerd).

OCaml is extremely bad at parallelism, even embarassingly parallel tasks 
because OCaml still has to marshall all the data in a gather operation or 
resort to manual memory management. However, the problems are entirely with 
the current implementation and not with the language at all. So a new 
implementation could address this problem.

> a) Could Jocaml be the future of Ocaml?

For concurrency perhaps but not for parallelism.

> b) How do we handle the global mutability issue?

Avoid mutation when it is likely to get out of control (e.g. Erlang-style 
concurrent applications) but keep it available because it gives huge 
performance improvements in many parallel applications. F# already has good 
solutions in both cases so we can just copy them.

I spent a lot of time thinking about the future of the ML family of languages 
in the open source world recently. I believe I have an another way forward 
that some people might find interesting. I think ML has proven its worth and 
it is time to begin developing a completely new open source ML 
implementation. There are various different ways to accomplish this and the 
goals are quite obvious (IMHO). However, finding a route that is likely to 
lead to those goals that is socially acceptable (i.e. not a fork) and 
technically feasible (i.e. incrementally adding useful features and garnering 
users) was not easy. I believe the best course of action is to develop an 
embedded DSL for OCaml (e.g. for higher-performance numerics) and evolve it 
into a completely new ML implementation.

I have actually already started this using the excellent LLVM project and I 
just obtained the first promising results yesterday: a simple benchmark where 
my compiler runs OCaml code 3x faster than ocamlopt does.

There are a *lot* of low hanging fruit here. So I think it should be 
relatively easy to create a tool that is useful for a significant number of 
people. The most interesting aspect is that developing this project as a DLL 
that is entirely accessible from within OCaml makes it possible to address 
many of OCaml's own problems for existing OCaml programmers.

If anyone has any ideas about this I'd love to hear them.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e