From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 4B933BBAF for ; Sat, 17 Jul 2010 19:53:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQDAFOLQUzRVdY0kGdsb2JhbACfGFAIFQEBAQEJCQwHEQMfrxWCEIUTLohUAQEDBYUgBIN7hFw X-IronPort-AV: E=Sophos;i="4.55,219,1278280800"; d="scan'208";a="63963416" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Jul 2010 19:53:36 +0200 Received: by bwz14 with SMTP id 14so2156396bwz.39 for ; Sat, 17 Jul 2010 10:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=kFBv6ltAUVb8i7fkifmcgK5uHfkNaEe9cK27aQupOpw=; b=McejH/RKWxluClQJyMnCEdWzAYmLo6rnB5fWdsNz14g7vwz2fw9NwxPyODD5hHqDYt MiPh37qJu8xfd+/i4t0KNq7bIPiXujKOnEC+x5upoa73Q82y34yZhBBDGC3AetKgOjrs fbyiyQadYhSpQjO7tgkQuUDyZPrkLBAuXa2z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=NGmgEzuFtb5TSKESIgAnr9ELl9Oft+tpm7kD53B9SjhjisAw8voIGGcDVVitGTScFJ IiUqO3dUj4Ok12ywy/22LlM26RBtVL7VV37dmdSRybVzvyNnJLwE4+PCuiZVeHnDhyWM o3/cLAsuQjQhu4aE11s5M2b+yNIZSSBSZAdJU= Received: by 10.204.126.161 with SMTP id c33mr2116027bks.108.1279389216223; Sat, 17 Jul 2010 10:53:36 -0700 (PDT) Received: from [86.108.242.244] ([86.108.242.244]) by mx.google.com with ESMTPS id 24sm16822770bkr.19.2010.07.17.10.53.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 10:53:35 -0700 (PDT) References: <87sk3mcaeq.fsf@frosties.localdomain> <87zkxsfvsg.fsf@frosties.localdomain> <87hbk0vzut.fsf@frosties.localdomain> <87630fbmvb.fsf@frosties.localdomain> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: Cc: Goswin von Brederlow , "caml-list@yquem.inria.fr" X-Mailer: iPhone Mail (8A293) From: Eray Ozkural Subject: Re: [Caml-list] Smart ways to implement worker threads Date: Sat, 17 Jul 2010 20:53:20 +0300 To: Rich Neswold X-Spam: no; 0.00; eray:01 ozkural:01 event-driven:01 openmp:01 compiler:01 camlp:01 openmp:01 ocaml:01 parallelism:01 parallelism:01 ocaml:01 wishlist:01 cheers:01 eray:01 threads:01 It does encourage me to take a shot at using the Event module. One of the advantages of object orientation was that event-driven programmin= g and concurrent processes would/could fit well. Yet years later event driven programming exists mostly as the main loop of G= UI libraries and implemented in cumbersome imperative languages.=20 It has been suggested that traditional synchronization primitives are defici= ent. Like with message passing libraries it's too easy to write incorrect co= de with them (since they assume all programmers must be naive enough to stil= l code in C.). I think it's so much easier to make a buggy implementation in= posix threads that I advise against (having to) use it in any language. In my experience with shared memory programming I found it a better option t= o write code in openmp. Charm++ like spawn directives aren't too bad either a= nd they fit functional languages.=20 I suppose with some compiler help we could have such parallelization; maybe j= ust some camlp4 macros are enough. After all, it's not a bad idea to isolate= synchronization in the program and I bet it can be done in a safe way. What= would be needed to adapt the openmp idea to ocaml? Assuming we have proper m= ulticore support (lock-free parallel garbage collector, real threads etc.) Considering that architectural details cannot be so easily ignored on a mult= icore architecture I wonder how to do this best. Perhaps some way to specify= fine-grain parallelism would be more flexible (like fine-grain kernels in c= uda) I think architectural details would be important for parallel code opti= mizations. We had used a thread/critical region based intermediate program representati= on for C but I think we could do better with functional languages, towards a= fully implicit parallel PL. Of course there are various existing approaches to implementing explicit par= allelism on top of ocaml. I wonder if the INRIA team would consider adapting= those to a shared memory architecture. Short of the high technology we need= (implicit parallelism) we can be satisfied with cool functional and archite= cture agnostic parallelism primitives. So my wishlist is: 1) low level shared memory programming primitives and lang support 2) high level parallel programming facility that is completely independent o= f target architecture 3) implicit parallelism that uses an automatic parallelization approach Cheers, Eray