Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
thousands of CPU cores
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-07-11 (14:03)
From: Basile STARYNKEVITCH <basile@s...>
Subject: Re: [Caml-list] thousands of CPU cores
Jon Harrop wrote:
> Ironically, given the hype surrounding functional programming for parallelism, 
> all open source FPLs were left behind. On Linux, even the future prospects 
> are bleak: no tail calls on the JVM, prohibitively difficult to implement an 
> efficient concurrent GC yourself and Mono is going nowhere.

It is not specific to Linux (and probably not even to *opensource* 
functional programming languages; I believe proprietary functional 
languages implementations face the same problems). In my perception, 
functional programming requires *blindly fast* memory allocation for 
values which are becoming garbage quickly. This seems a property of 
functional programming (and more generally any programming style 
discouraging side effects), in other words functional programming need 
very efficient garbage collectors (A.Appel wrote stuff on this almost 
20? years ago).

And coding efficient parallel generational collector is really hard, at 
least on current hardware (ask Damien Doligez). Perhaps chip makers 
might acknowledge the importance of supporting read & write barriers on 
the bare metal (which seems easy, more a managerial/merket decision than 
a technical one; on x86 we've got MMX, then SSE1, ... SSE5, AVX but no 
additional instructions for read & write barriers...). There is a 
chicken&egg issue here (no hardware assist for good GC, so no good 
functional language implementation on multicore).

As a case in point, I suggest an experiment (which unfortunately I don't 
have the time or motivation to realize). Replace the current Ocaml GC 
either in bytecode or in nativecode ocaml by Boehm's collector (which is 
multithread compatible). I'm sure you'll get a significant performance 
loss, but you should gain the true multi-threading feature. Of course, 
synchronization issues will appear, very probably in application code 
(and some C function wrappers).


email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***