Browse thread
thousands of CPU cores
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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).
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
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} ***