From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3KLj001007869 for ; Wed, 20 Apr 2011 23:45:00 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BAM5Sr01KfVIqkGdsb2JhbACEUKBuCBQBAQEBCQkNBxQEIYhvoniKOIJhAQWOJQEEgSmDTnqYKDo X-IronPort-AV: E=Sophos;i="4.64,247,1301868000"; d="scan'208";a="106357959" Received: from mail-ww0-f42.google.com ([74.125.82.42]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Apr 2011 23:44:55 +0200 Received: by wwk4 with SMTP id 4so5025668wwk.3 for ; Wed, 20 Apr 2011 14:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=+ZkwCc2B7SLXmRKm/VvQn3twh1ayXuFWDvkddNeZ+tk=; b=tOrJOS/y6XniK7AB3Xk44NwKvrsN5EbuZ2T5sIgUvEerRKpZrqr/VDIfIQ890xgO+b ZxghEBuOWtAEGMuV/aS8Awvaks5QP4Z3hDeNtmMouAoqMIUt94b4mPBkOiXKDz58sDy4 Ax/XJuRTSTX0jeU63dcHB3OKi6JASwUjUa7ds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:organization :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; b=O//nrHgiAD8xN962it2vA58NkG9NzaEdfRH3gZzInQdxKY4l+vLvtva4TBf9r4oAd/ GYjpKqi/mlktzFy1vQIPQ3QuKaLuieM9rBZw3UfCorzqQ7o/NXSRqW53TVkzbG+9uNmf Mi3pZ13BGJ+hrdCWpwjViRgMqhYmLnknQHrMI= Received: by 10.227.207.7 with SMTP id fw7mr3053416wbb.137.1303335895170; Wed, 20 Apr 2011 14:44:55 -0700 (PDT) Received: from WinEight ([80.229.123.248]) by mx.google.com with ESMTPS id x1sm818639wbh.2.2011.04.20.14.44.53 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 14:44:54 -0700 (PDT) From: Jon Harrop To: "'Gerd Stolpmann'" Cc: References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> <4D8C73C8.6020801@inescporto.pt> <1301055903.8429.314.camel@thinkpad> <341494683.237537.1301057887481.JavaMail.root@zmbs4.inria.fr> <4D8C944A.9060601@inria.fr> <4D8CB859.9040709@inescporto.pt> <4D8CDDCC.4010000@ens-lyon.org> <4D8CEAA4.2030403@inescporto.pt> <1301084818.8429.435.camel@thinkpad> In-Reply-To: <1301084818.8429.435.camel@thinkpad> Date: Wed, 20 Apr 2011 22:44:38 +0100 Organization: Flying Frog Consultancy Message-ID: <02ac01cbffa4$2721b130$75651390$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFhMASujb2QG2h3N2h7/lJjoQ23OAIYQRkZAge6bucBi7oV8gIGVE8/AmcCvngCudDnUAFa0vZTARTLcbACmiZk1ZStxExg Content-Language: en-gb Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3KLj001007869 X-Validation-by: jon@ffconsultancy.com Subject: RE: [Caml-list] Efficient OCaml multicore -- roadmap? Gerd wrote: > When you implement a message passing API for a high level language, the way > to go is to provide message buffers in memory. When a thread delivers a > message it just writes to the buffer. The real message, however, is sent by the > hardware under the hood, and must be delivered until the reading thread > synchronizes. The point is here, IMHO, that you exploit the features of the > hardware the most when you do it in a way the hardware can deal best with. > Thus a program written against the message passing API will finally be faster > than one that uncritically assumes a uniform memory, and modifies memory in- > place, and will finally suffer from cache line bouncing. I think we should work through a concrete example like the one Hugo gave using message passing and the other approaches to multicore parallelism. The following F# function "f" takes "tree" and creates "n" derivative data structures by applying "g" to it and then applies "h" to it in order to perform the "subsequent processing": # let f tree n g h = Array.Parallel.init n (fun i -> h(g i tree)) val f : 'a -> int -> (int -> 'a -> 'b) -> ('b -> 'c) -> 'c array For example, take the set {2,4,6,8} and add each of 0..9 and then count the number of elements: # f (set[2;4;6;8]) 10 Set.add Set.count;; - : int array = [|5; 5; 4; 5; 4; 5; 4; 5; 4; 5|] Try to solve the same problem using explicit message passing. > For current standard server hardware there are usually not enough CPUs to get a > big effect. But in a few years it will be very important (as it is for current > supercomputers), maybe even for standard 128 core laptops in 2015 (just > guessing). This needs quantifying. Dual core desktops became available with AMD's Athlon 64 X2 in 2005. Six years later, the widest multicore desktop Dell sells has only 6 cores and the widest server has only 12 cores (per CPU). If the trend continues, we'll barely have 18-core desktops by 2015 much less 128-core laptops. Cheers, Jon.