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.5 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 1A1F7BBC4 for ; Thu, 2 Apr 2009 09:10:06 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoAADMB1EnUnwdkjWdsb2JhbACCIZNyAQEBAQkJCgkPBrgOg30G X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="26855393" Received: from relay.pcl-ipout02.plus.net ([212.159.7.100]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 02 Apr 2009 09:10:05 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYEAO4B1EnUnw6U/2dsb2JhbACCIcxEg30G Received: from fhw-relay07.plus.net ([212.159.14.148]) by relay.pcl-ipout02.plus.net with ESMTP; 02 Apr 2009 08:10:05 +0100 Received: from [87.115.30.229] (helo=leper.local) by fhw-relay07.plus.net with esmtp (Exim) id 1LpH3r-00029b-SX for caml-list@yquem.inria.fr; Thu, 02 Apr 2009 08:10:04 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Efficient parallel programming without a concurrent GC Date: Thu, 2 Apr 2009 08:16:21 +0100 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904020816.21471.jon@ffconsultancy.com> X-Plusnet-Relay: 421afb1bf8ca40de1e8d145ec243ea0c X-Spam: no; 0.00; ocaml's:01 camlp:01 ocaml:01 ocaml's:01 toolchain:01 parallelism:01 ocaml:01 bigarray:01 arrays:01 frog:98 gcs:01 macros:01 short:01 data:02 data:02 I believe I have envisaged a useful and feasible way to combine the benefits of OCaml's GC with efficient parallel programming without requiring a concurrent GC. I have been considering the ramifications of being able to quote HLVM code in camlp4 macros as a DSL from within OCaml programs. That would combine OCaml's better toolchain with HLVM's better numerical performance and (in the future) efficient parallelism. For example, a program might initialize an OCaml bigarray representing the physical state of a simulation or computer game environment and call into HLVM to have the state updated in-place using efficient parallel algorithms implemented as multithreaded code. The result could even be passed directly to OpenGL for visualization. In particular, the OCaml code responsible for the UI would benefit from short pause times whereas the HLVM code responsible for number crunching would benefit from high throughput. This approach appears to solve almost all of the outstanding problems because the programmer can choose between two different ways to execute code that have different characteristics and the two modes of evaluation can run concurrently using shared state for O(1) communication. Moreover, neither side is burdened with the inefficiencies of a concurrent GC. The disadvantage is that the two GCs must remain oblivious to each other so data passed between them must be managed manually. However, that seems like a small price to pay because the data will inevitably be arrays of value types that are easily managed. Does that sound valuable? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e