Re: [Caml-list] Re: Why OCaml rocks

[Jon Harrop <jon@ffconsultancy.com>]

On Friday 09 May 2008 21:40:45 Gerd Stolpmann wrote:
> Am Freitag, den 09.05.2008, 19:10 +0100 schrieb Jon Harrop:
> > If OCaml is good for concurrency on distributed systems that is great but
> > it is completely different to CPU-bound parallelism on multicores.
>
> You sound like somebody who tries to sell hardware :-)

:-)

> Well, our algorithms are quite easy to parallelize. I don't see a
> difference in whether they are CPU-bound or disk-bound - we also have
> lots of CPU-bound stuff, and the parallelization strategies are the
> same.
>
> The important thing is whether the algorithm can be formulated in a way
> so that state mutations are rare, or can at least be done in a
> "cache-friendly" way. Such algorithms exist for a lot of problems. I
> don't know which problems you want to solve, but it sounds like as if it
> were special problems. Like for most industries, most of our problems
> are simply "do the same for N objects" where N is very large, and
> sometimes "sort data", also for large N.

Right. Those are embarassingly parallel problems, which is why you are not 
suffering from a lack of fine-grained parallelism as we are. Some problems 
require fine-grained parallelism but, on a more general note, we are trying 
to push parallelism as deep into our libraries as possible so that users can 
benefit from their multicore machines whatever they are doing.

The ability to spawn parallel computions efficiently is of the utmost 
importance here. Without it, multicore holds no advantages (e.g. for that 
matrix multiply benchmark with n<100).

> > Parallelism is easy in F#.
>
> Wonders must have happened I'm not aware of. How does F# prevent
> deadlocks?

Parallel programming is typically extremely well suited to data parallel 
constructs (parallel for and so forth) so deadlocks are not a problem. 
However, F# is also unusually good for improving robustness even in the 
presence of low-level threading constructs because, just like OCaml, mutation 
is contained and typically reversed for performance-critical sections of 
code. So the number of locks in a large parallel F# applications is tiny 
compared to Java/C# and it is perfectly feasible to manage their potential 
interactions (i.e. to avoid deadlocks) by hand.

> > > This is a quite theoretical statement. We will rather see that most
> > > application programmers will not learn parallelism at all, and that
> > > consumers will start question the sense of multicores, and the chip
> > > industry will search for alternatives.
> >
> > On the contrary, that is not a theoretical statement at all: it already
> > happened. F# already makes it much easier to write high performance
> > parallel algorithms and its concurrent GC is the crux of that capability.
>
> Don't misunderstand me, I'm not anti-F#.

This will all apply to OCaml when it gets a parallel GC this summer. :-)

> I only have no interests right 
> now in taking advantage of multicores by concurrent GC's. I rather want
> to have an ultra-fast single-core execution. I can do the
> parallelization myself.

Right. Our customers are loving parallelism right now and want to make the 
most of their multicore machines today. This is pushing us to make everything 
as multicore friendly as possible.

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