From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 18A35BBAF for ; Tue, 22 Dec 2009 19:35:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAF6gMEvUnwdji2dsb2JhbACCGZkvAQEBCgsKBxEGuxKEMwQ X-IronPort-AV: E=Sophos;i="4.47,437,1257116400"; d="scan'208";a="52666308" Received: from relay.pcl-ipout01.plus.net ([212.159.7.99]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Dec 2009 19:35:40 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAOafMEtUXebz/2dsb2JhbACCGdUIhDME Received: from relay02.plus.net ([84.93.230.243]) by relay.pcl-ipout01.plus.net with ESMTP; 22 Dec 2009 18:35:40 +0000 Received: from [87.114.35.173] (helo=leper.local) by relay02.plus.net with esmtp (Exim) id 1NN9a7-0004qe-TX for caml-list@yquem.inria.fr; Tue, 22 Dec 2009 18:35:40 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Looking for information regarding use of OCaml in scientific computing and simulation Date: Tue, 22 Dec 2009 19:49:47 +0000 User-Agent: KMail/1.9.9 References: <3d13dcfc0911250305i43a684e4u5a96ec420b6ce350@mail.gmail.com> <3ae3aa420912212040i23309f7cw4485db33352c1853@mail.gmail.com> <320e992a0912220511s6e5f271ftb0a72b73e9daf437@mail.gmail.com> In-Reply-To: <320e992a0912220511s6e5f271ftb0a72b73e9daf437@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200912221949.47285.jon@ffconsultancy.com> X-Plusnet-Relay: 3ddcb0697cefd38bb6deac533a1ca2de X-Spam: no; 0.00; ocaml:01 eray:01 ozkural:01 parallelism:01 ocaml:01 high-level:01 parallelism:01 combinators:01 2009:98 2009:98 frog:98 closures:01 wrote:01 wrote:01 caml-list:01 On Tuesday 22 December 2009 13:11:58 Eray Ozkural wrote: > On Tue, Dec 22, 2009 at 6:40 AM, Linas Vepstas =20 wrote: > > However, if you are =A0interested in merely using the system > > to do your "real" work, then writing message-passing code > > is an utter waste of time -- its difficult, time-consuming, error > > prone, hard to balance and optimize & tune, works well only > > for "embarrasingly parallel" code, etc. =A0Even the evil > > slow-down of NUMA is often better than trying to > > performance-tune a message-passing system. > > Message passing doesn't work well only for embarrassingly parallel > code. Message passing doesn't necessarily work well for embarrassingly-parallel=20 problems either because you cannot use in-place algorithms and scatter and= =20 gather are O(n). > For instance, you can implement the aforementioned parallel=20 > quicksort rather easily, But you cannot improve performance easily and performance is the *only*=20 motivation for parallelism. So the fact that you can make naive use of=20 message passing easily from OCaml is useless in practice. > What message passing really is, it is the perfect match to a > distributed memory architecture. Since, as you suggest, multicore > chips have more or less a shared memory architecture, message passing > is indeed not a good match. Yes. Conversely, shared memory is effectively a hardware accelerated form o= f=20 message passing. > > Let me put it this way: suggesting that programmers can > > write their own message-passing system is kind of like > > telling them that they can write their own garbage-collection > > system, or design their own closures, or they can go > > create their own type system. Of course they can ... and > > if they wanted to do that, they would be programming in > > C or assembly, and would probably be designing new > > languages. =A0Cause by the time you get done with message > > passing, you've created a significant and rich programming > > system that resembles a poorly-designed language... been > > there, done that. > > For a functional language, am I right in expecting a high-level and > clean interface for explicit parallelism? I think that is a perfectly reasonable thing to expect but you still need t= o=20 understand its characteristics and how to leverage them in order to make go= od=20 use of the feature. > I suppose a "spawn" directive would not be very hard to implement. You cannot implement it with useful efficiency in OCaml. > Message Passing/Distributed Memory can also be accommodated I suppose. Sure but it is worth remembering that distributed parallelism across cluste= rs=20 is a tiny niche compared to multicores. > OcamlP3l looks pretty cool. Parallel combinators? Definitely what I'm > talking about, as usual the future is here with ocaml ;) > > http://ocamlp3l.inria.fr/eng.htm Try solving some real problems with OCamlP3L and F#. I'm sure you'll agree= =20 that the OCaml approach is certainly not the future. =2D-=20 Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e