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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 40ED3BBAF for ; Fri, 11 Jul 2008 17:30:19 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAOAYd0hMYB4YYWdsb2JhbACSHRoEHAWcb4F0 X-IronPort-AV: E=Sophos;i="4.30,346,1212357600"; d="scan'208";a="27243556" Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Jul 2008 17:30:18 +0200 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id ocGk1Z0091GXsucA2fWHvx; Fri, 11 Jul 2008 15:30:17 +0000 Received: from 192.168.1.101 ([24.118.226.214]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id ofWD1Z00J4eAatC8TfWEqu; Fri, 11 Jul 2008 15:30:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=OhViZNB-e98A:10 a=8ouaYcUtM-LDO0dq5YcA:9 a=xxSOvwR3RxVshEzbQkeh0w5oVqUA:4 a=LY0hPdMaydYA:10 Subject: Re: [Caml-list] thousands of CPU cores From: Bill To: Xavier Leroy Cc: J C , caml-list@yquem.inria.fr In-Reply-To: <487768E2.6000108@inria.fr> References: <487768E2.6000108@inria.fr> Content-Type: text/plain Date: Fri, 11 Jul 2008 10:23:47 -0500 Message-Id: <1215789827.6014.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1-1mdk Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; 0200,:01 parallelism:01 gerd:01 stolpmann:01 ocaml:01 subsumed:01 synchronous:01 trade-off:01 upside-down:01 wrote:01 caml-list:01 functions:01 latency:01 algorithms:03 preliminary:03 On Fri, 2008-07-11 at 16:06 +0200, Xavier Leroy wrote: . . . > The interesting question that this community should focus on > (rather than throwing fits about concurrent GC and the like) is coming > up with good programming models for parallelism. I'm quite fond of > message passing myself, but agree that more constrained data-parallel > models have value as well. As Gerd Stolpmann mentioned, various forms > of message passing can be exploited from OCaml today, but there is > certainly room for improvement there. Perhaps this is subsumed by some of the terminology flying around this discussion, but what about (synchronous) dataflow? I had some pretty good-looking preliminary results implementing telecom algorithms in dataflow networks. One nice side-effect was that latency and throughput could be tied to the "aspect ratio" (length vs. breadth) of the dataflow network. This could be an opening for the design-space trade-off design style that hardware designers are used to but that is rare in software. The resulting designs look upside-down to software designers -- instead of a few big processes doing complicated work and communicating/coordinating with each other there is a large number of small functions each doing its thing to the next item on its input queue and passing it on. -- Bill Wood