From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 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 5E9C6BBAF for ; Fri, 19 Dec 2008 14:06:16 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.36,249,1228086000"; d="scan'208";a="32883165" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 Dec 2008 14:06:16 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id mBJD6FDC024217 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 19 Dec 2008 14:06:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgBABUrS0nRVdoKimdsb2JhbACTJT4BAQEKCQwHDwWrGliEV4wPAQMBA4MAgkA X-IronPort-AV: E=Sophos;i="4.36,249,1228086000"; d="scan'208";a="21518646" Received: from mail-bw0-f10.google.com ([209.85.218.10]) by mail1-smtp-roc.national.inria.fr with ESMTP; 19 Dec 2008 14:06:15 +0100 Received: by bwz3 with SMTP id 3so2364665bwz.9 for ; Fri, 19 Dec 2008 05:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=R4aR0rpjmNZVDpRZw1JdPTyZVt/bhxdB6st63Zd+sOU=; b=C8TS36f8tcKqCy9M3EyxdUo4jnfBKVDix6taKecJLJPqO1qA4pUCOVTFTOUbVQPbJz KYea6FVgQbvDaNGQg9WhtW0EP7zbLVzEhhqMLL07HV5nRvAZY4wKpS+kf+RvehJqyPPK svfza16VpXy6xOkS7Q/MVPOb/EDgOYG5AaZhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=s0AMoiHxXUIzokH3JJj5uwpKaWL6Y21wnWSZxYO+dJmQ5Bo0CBtEu/8/XJFcTcKo3j YoHol27zTTP1KGQGv0rE7qv+w0JD54DpfR3F4VgKOET4jCriSU9zya8tuMRc65s632r+ RfZM5yBkqJ3iFOV52WoDfut5U1LxyaR1n/lTE= Received: by 10.181.208.15 with SMTP id k15mr1068986bkq.130.1229691880370; Fri, 19 Dec 2008 05:04:40 -0800 (PST) Received: by 10.181.203.8 with HTTP; Fri, 19 Dec 2008 05:04:40 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 14:04:40 +0100 From: "=?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?=" Sender: mikkelfj@gmail.com To: OCaml Subject: More cores MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 9f9f5c53529e582f X-Miltered: at discorde with ID 494B9C47.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mikkel:01 rgensen:01 mikkel:01 ocaml:01 ocaml:01 runtime:01 node:01 compiler:01 mutable:01 cnet:98 subj:98 heap:01 heap:01 primitives:01 native:03 Is it time to start rethinking concurrency in OCaml? I have followed the argumentation of only using one native thread for the OCaml runtime. I can easily see how this can increase performance and simplify implementation. I can also see that spawning new processes makes sense, so you get a local heap for each task. However, as we move forward it seems that we will get more than a few cores on the same computational node according to the following article: Intel says to prepare for 'thousands of cores': http://news.cnet.com/8301-13924_3-9981760-64.html?part=rss&subj=news&tag=2547-1_3-0-20 As I see it, it is not feasible to spawn a new process with a local heap for each core, when the number of cores increases dramatically. I am not sure that a parallel GC is a sufficient solution either due to the high contention on memory, at least unless it provide some additional core affinity features. I believe some level of compiler support is needed in the not so distant future such that enough primitives are available to build powerful multi-core aware libraries. One approach could be micro heaps with core affinity and handle mutable memory specially. Regards, Mikkel