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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id D3D61BBAF for ; Tue, 22 Dec 2009 14:12:06 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0CAOdUMEvRVdrVkGdsb2JhbACPb4F2gheGdz8BAQEBCQkMBxMDqiSBMoUtiFIBAgMFhC4E X-IronPort-AV: E=Sophos;i="4.47,436,1257116400"; d="scan'208";a="39178083" Received: from mail-bw0-f213.google.com ([209.85.218.213]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Dec 2009 14:11:59 +0100 Received: by bwz5 with SMTP id 5so4121443bwz.3 for ; Tue, 22 Dec 2009 05:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J25272vjs5XsgAjjsu4ShHnjwkM+QESlkEgFDhKDO9c=; b=DjlnDFcgUCOIyhkRuz0O4IVG27iRB2lGdYNXLd08MlaD1jP+XbbOm7ke5o1Zpd14Rf fPR/SJyBJV9kLEiII9gDFTkwaiwZSlhzbQaZmFrUX1HPU3He124MLrnTBDkvf2Xgv5GR SIGAHp5VyoegflcwLsSFz/EpX4ZUer2FDtkbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hLUaR5VxrZItTchgzApEVPx+9j9cne2bxsouIN6oyt95PJB3japHvuKKzavaqdC7I0 f1X/Oz5nr/aNsJj2Zrb3TPT7L1MKxUu58gz17rFPjtc4uO6igT9qh85XJgJ6QCr9ppwl SyuHU61zQagxw36wwvMT41TUhM8uV6DFncplw= MIME-Version: 1.0 Received: by 10.204.154.142 with SMTP id o14mr5887845bkw.125.1261487518909; Tue, 22 Dec 2009 05:11:58 -0800 (PST) In-Reply-To: <3ae3aa420912212040i23309f7cw4485db33352c1853@mail.gmail.com> References: <3d13dcfc0911250305i43a684e4u5a96ec420b6ce350@mail.gmail.com> <200911292311.29580.jon@ffconsultancy.com> <4a708d20911291416x2be905f7p93f559543a77d97f@mail.gmail.com> <3ae3aa420911300830h63a04b21r2e09fb4e34cdb7f7@mail.gmail.com> <4a708d20912200638q5e7d72acu9cae3b564ada085d@mail.gmail.com> <3ae3aa420912212040i23309f7cw4485db33352c1853@mail.gmail.com> Date: Tue, 22 Dec 2009 15:11:58 +0200 Message-ID: <320e992a0912220511s6e5f271ftb0a72b73e9daf437@mail.gmail.com> Subject: Re: [Caml-list] Looking for information regarding use of OCaml in scientific computing and simulation From: Eray Ozkural To: linasvepstas@gmail.com Cc: Lukasz Stafiniak , caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocaml:01 eray:01 ozkural:01 low-level:01 c-like:01 semantics:01 inherently:01 high-level:01 parallelism:01 one-to-one:01 monads:01 functors:01 low-level:01 ocaml:01 combinators:01 On Tue, Dec 22, 2009 at 6:40 AM, Linas Vepstas wro= te: > 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. For instance, you can implement the aforementioned parallel quicksort rather easily, but it's true that message passing is low-level. The really bad thing about MPI is that it assumes some C-like environment. C has the worst semantics ever, so programs that require/encourage such a style of writing are inherently, well, bad =3D) And yes, MPI's difficult to debug. 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. However, let's not forget about the new GPU architectures, which are sort of hybrid. The newer GPUs will have more exotic on-chip interconnection networks. > 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 suppose a "spawn" directive would not be very hard to implement. Or a parallel let block. I don't know what kind of direction the caml researchers have in mind (except for some INRIA projects I've read about) but I suppose it can be done (closures could be a nice interface, I think). Message Passing/Distributed Memory can also be accommodated I suppose. For distributed memory, you just need an addressing scheme to denote the processor number. You could allocate with a parallel new that takes a processor number argument for instance. For message passing, you need one-to-one, collective, and one-sided communications. On top of an imperative but failsafe and debuggable interface, you could provide neat functional blocks. For instance, you could present the user with a shuffle/map/reduce interface like in Google's grid computing platform. I would also like to have some computing-abstraction (like Monads, but more flexible) so I can easily build networks of sequential algorithms (kind of like Communicating Sequential Processses). It would also be nice to have functors that implement commonly occurring parallel programming patterns (such as master-slave dynamic load balancing or pipelining). Such things are difficult to manage in a low-level language like C, but they would be a piece of cake in ocaml. Or is fate sending that my way? Oh, not again! :) 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 Best, --=20 Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct