From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id B29AABBAF for ; Fri, 11 Jul 2008 16:03:52 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIBADAFd0g+BBBpd2dsb2JhbACBWpBNAQwFAgQJDwWceA X-IronPort-AV: E=Sophos;i="4.30,345,1212357600"; d="scan'208";a="15007257" Received: from smtp-105-friday.nerim.net (HELO kraid.nerim.net) ([62.4.16.105]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Jul 2008 16:03:52 +0200 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by kraid.nerim.net (Postfix) with ESMTP id CA293CF1EF for ; Fri, 11 Jul 2008 16:03:51 +0200 (CEST) Received: from [192.168.0.1] (glinka.lesours [192.168.0.1]) by hector.lesours (Postfix) with ESMTP id 401F020F192 for ; Fri, 11 Jul 2008 16:02:34 +0200 (CEST) Message-ID: <48776844.3050708@starynkevitch.net> Date: Fri, 11 Jul 2008 16:03:48 +0200 From: Basile STARYNKEVITCH User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] thousands of CPU cores References: <1215781305.28798.19.camel@flake.lan.gerd-stolpmann.de> <200807111443.53853.jon@ffconsultancy.com> In-Reply-To: <200807111443.53853.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; basile:01 basile:01 parallelism:01 fpls:01 generational:01 damien:01 ocaml:01 bytecode:01 nativecode:01 ocaml:01 multithread:01 wrappers:01 faiencerie:01 92340:01 reine:01 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: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***