From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 86E47BC8E for ; Thu, 23 Jun 2005 11:28:08 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5N9S8nk029097 for ; Thu, 23 Jun 2005 11:28:08 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA01970 for ; Thu, 23 Jun 2005 11:28:07 +0200 (MET DST) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.206]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5N9S7RK029091 for ; Thu, 23 Jun 2005 11:28:07 +0200 Received: by nproxy.gmail.com with SMTP id n15so50650nfc for ; Thu, 23 Jun 2005 02:28:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hR0weCcI4Dc8a1WsOurZf4QlFF15ki2cjIhA4ZTY+kUsr509yQjS8LqRG491ASyIJL/AbIZfyAycbzWZBzIKbfU8iAmBqQVbRb+albGbtWtt8TnMOQK4OPX6aJukEo3YWZfTM9G0/9BXnwhzf2coqUlQfZ3P0JpwxBDxuyVW67g= Received: by 10.48.142.11 with SMTP id p11mr33645nfd; Thu, 23 Jun 2005 02:28:06 -0700 (PDT) Received: by 10.48.237.20 with HTTP; Thu, 23 Jun 2005 02:28:06 -0700 (PDT) Message-ID: <3d13dcfc0506230228198b1b2b@mail.gmail.com> Date: Thu, 23 Jun 2005 11:28:06 +0200 From: David MENTRE To: =?ISO-8859-1?Q?Fr=E9d=E9ric_Gava?= Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future? Cc: caml-list@inria.fr In-Reply-To: <001001c577ce$45b9cce0$0100a8c0@mshome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3d13dcfc05062300215e4be9ee@mail.gmail.com> <001001c577ce$45b9cce0$0100a8c0@mshome.net> X-Miltered: at nez-perce with ID 42BA80A8.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42BA80A7.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml's:01 pointers:01 gava:01 gava:01 lablgtk:01 parallelism:01 bsmllib:01 bsmllib:01 parallelism:01 developping:01 ocaml:01 inference:01 posix:01 mutexes:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.2 X-Spam-Level: Hello Fr=E9d=E9ric, Thank you for the different pointers. I've heard of BSP approach previously but I'm not up to date with latest news. 2005/6/23, Fr=E9d=E9ric Gava : > There is also the fact that you do not develop parallel programs for the > same things than sequential ones: what is the interest to have a parallel > language for just an application that play a MP3 ? Good question that I did not considered when asking my own question. Right now, I'm writing a user program (with Lablgtk2 user interface) and a server program (network, file and databases I/O, lot of in memory data structures, few computation intensive parts, mostly algorithmic issues). On the user side, I see no real need of parallelism, except if it can improve responsiveness (e.g. user graphical front-end and back-end that interact with the server on the network). On the server side, it is different. If I have a dual core machine (and *I'm going to have* a 2- or 4-core machine), I would like my server to reply as fast as possible to clients, which implies that some tasks must be done in the background, with all the implied synchronization issues. As you see, my programmer profile is quite different from the expected usage of BSMLlib (if I have understood BSMLlib description correctly): no data parallel programming, rather control parallel programming. > Using parallelism is > good for some specific cases and thus need specifics libraries. Developpi= ng > a "big language" that is good for parallel computing and sequential > computing seems (it is my opinion) to be a too much harder work. I'm not interested in THE parallel paradigm that will solve all parallel programming issues. After 50 years of research, no consensus have emerged yet. That's said, it does not mean that OCaml should not provide tools to improve the current state of affair. It is already doing that with type inference, GC or sum types. Programming parallel code with Posix mutexes and threads is a nightmare. I have to say that I had a very pleasant experiment with OCaml typed channels (aka Concurrent ML channels). I'm just wondering if INRIA people consider that unknown (to a wide public) constructs could be offered to ease concurrent programming. And knowing that current ocaml cannot handle real concurrent threads is a real concern. Yours, david