From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 6CF88BC57 for ; Tue, 20 Jul 2010 17:02:54 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsCAFFXRUzRVdY0kGdsb2JhbACSfIxpCBUBAQEBCQkMBxEDH69IghCGJS6IVAEBAwWFLQSDe4Re X-IronPort-AV: E=Sophos;i="4.55,233,1278280800"; d="scan'208";a="66717154" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 20 Jul 2010 17:02:50 +0200 Received: by bwz14 with SMTP id 14so3694426bwz.39 for ; Tue, 20 Jul 2010 08:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2Cdv20bfjEEt9/WHNwA9in/5oZHXeTbfTvb40ltJIr4=; b=V8gB904Nhchqve6S03osmuz4HKKxk/kossvmXDWucXhfTu5tOBa/tGER+6HsWD8AeI mF2Fbo6i6a1Tun+r6aowUqADriNAKZ88E3pPpZKyCoK9Qx6teKogZ1YS5hV3ZugzqOkB tY0fQxo0JayglXvOAcPBZWHIbfqhNYS9XluAM= 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; b=MK9i/BQf0+aD1FxfZrDyHPlZcUYOT/FRu1z8Sm0NcAlxiyGP34xqfKc07MgsaQdOrX gBVekRPdeY03LDtT0OBqy9CvjExc54dtgq0JvUyReMjUZ1N4DQQpdBwpjUT6l3WaVrc1 zjdSBowCoT6N493G28pcTAVlrQzC/Hw7rvi4E= MIME-Version: 1.0 Received: by 10.204.163.133 with SMTP id a5mr5300669bky.6.1279638169761; Tue, 20 Jul 2010 08:02:49 -0700 (PDT) Received: by 10.204.16.195 with HTTP; Tue, 20 Jul 2010 08:02:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Jul 2010 18:02:49 +0300 Message-ID: Subject: Re: [Caml-list] ocaml for embedding From: Eray Ozkural To: Gaspard Bucher Cc: David MENTRE , caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=000325558c9e8cb760048bd2faff X-Spam: no; 0.00; ocaml:01 eray:01 ozkural:01 eray:01 ozkural:01 jocaml:01 low-level:01 speedup:01 speedup:01 high-level:01 bilkent:01 jocaml:01 low-level:01 high-level:01 bilkent:01 --000325558c9e8cb760048bd2faff Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 3:36 AM, Eray Ozkural wrote: > On Mon, Jul 12, 2010 at 4:19 PM, Gaspard Bucher wrote: > >> Just a final question on the topic: has JoCaml anything to do with >> this concurrency (shared memory) question ? > > > It seems to me that it can be implemented for a shared memory system. Why > not? But it's been designed with distributed memory in mind. So, I suppose > writing to shared memory could be slow. It'd be sort of like implementing > synchronization on top of a message passing system. Although I can see that > reading is OK. > On second thought it's not so clear how reads could be efficient. I'd assumed that somehow messages could be sent without making a separate copy of the data, so in principle we could perform the reads just as fast. Interesting question, though, thanks Gaspard. Now I realized it's not so clear and I apologize for that mistake, because that would be only valid for immutable data structures. And I suppose with immutable data structures you get only part of the advantages of shared memory, right? What good is a parallel RAM if it doesn't support concurrent writes? So, I think, no matter what kind of abstract concurrency primitives you provide, you'd still need proper shared memory + threads for the low-level programmer. Or as I said, you can also get speedup using MPI, but usually that's not the best speedup you are going to get because a) you can't avoid copying huge messages across processes b) mpi implementation may have too much penalty for finer-grain code, i.e. latency will become significant. I think MPI or these high-level concurrent processes would be good on shared memory if the problem is embarrasingly parallel. But as we all know only a small minority of problems turn out to be that easy to solve in parallel! At any rate, I'm sure we'll have it one day, I'm keeping my fingers crossed :) Best, -- 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 --000325558c9e8cb760048bd2faff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 20, 2010 at 3:36 AM, Eray Ozkural <examachine@gmail.com> wrote:=
On Mon, Jul 12, 2010 at 4:19 PM, Gaspard Bucher <gaspard@t= eti.ch> wrote:
=A0Just a final question on the topic: has JoCaml anything to do with
this concurrency (shared memory) question ?<= /blockquote>

It seems to me that it can be implemented for a = shared memory system. Why not? But it's been designed with distributed = memory in mind. So, I suppose writing to shared memory could be slow. It= 9;d be sort of like implementing synchronization on top of a message passin= g system. Although I can see that reading is OK.

On second thought it's= not so clear how reads could be efficient. I'd assumed that somehow me= ssages could be sent without making a separate copy of the data, so in prin= ciple we could perform the reads just as fast. Interesting question, though= , thanks Gaspard. Now I realized it's not so clear and I apologize for = that mistake, because that would be only valid for immutable data structure= s. And I suppose with immutable data structures you get only part of the ad= vantages of shared memory, right? What good is a parallel RAM=A0if it doesn= 't=A0support concurrent writes?

So, I think, no matter what kind of abstract concurrency primitives you= provide, you'd still need proper shared memory + threads for the low-l= evel programmer. Or as I said, you can also get speedup using MPI, but usua= lly that's not the best speedup you are going to get because a) you can= 't avoid copying huge messages across processes=A0b) mpi implementation= may have too much penalty for finer-grain code, i.e. latency will become s= ignificant. I think MPI or these high-level concurrent processes would be g= ood on shared memory if the problem is embarrasingly parallel. But as we al= l know only a small minority of problems turn out to be that easy to solve = in parallel!

At any rate, I'm sure we'll have it one day, I'm keeping my= fingers crossed :)

Best,

--
Eray Ozkural, PhD candidate.= =A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosoph= y
http://myspace.com/arizanesil= http://myspace.com/malfunct --000325558c9e8cb760048bd2faff--