From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3KNXNsr011448 for ; Thu, 21 Apr 2011 01:33:23 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BAJNsr01KfVK2kGdsb2JhbACEUKBuCBQBAQEBCQkNBxQEIYhvoy6KOIJhAQWOGgEEgSmDTnqYKDo X-IronPort-AV: E=Sophos;i="4.64,248,1301868000"; d="scan'208";a="81446551" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Apr 2011 01:33:21 +0200 Received: by wyf23 with SMTP id 23so1854989wyf.27 for ; Wed, 20 Apr 2011 16:33:21 -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=e11f/qLWBxZd8r0WLGLKbQYmDAHmdEBhmCQ6Hezc9Yw=; b=p26WdVSA51y7CVb3CU6zOGUagE0/0Gej1ip6Y3TcYxa4QO5iJtwWLA6M2sTdn96Olv 5lA9HRNu6unE38l5S9Amx37gtjOrXV/X8T7mYelC8NHe8iK1S7QOGgfFO/YGCe4t2K88 jiJsQ26R4N+39BSiTKIZtO4EzxWzTmmhC6qz8= 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=hHRFU7Y2v5D5Agnu5Z8dMraHr9wYsyAvXUG2pWxkFtcx7im2HcYPvEC9B8KS1/0lQR QLihwqAaX+jACX/meeowo2NPtOHid1PYzmfRjYBCRIls1m+Thom+zcHzAMTjidj+QZRo 78HD/XiAbq5tDPrPd8pVlPiYyENyj05i3s+LI= Received: by 10.227.61.13 with SMTP id r13mr3157895wbh.52.1303342400719; Wed, 20 Apr 2011 16:33:20 -0700 (PDT) Received: from WinEight ([80.229.123.248]) by mx.google.com with ESMTPS id e13sm848406wbi.57.2011.04.20.16.33.18 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 16:33:19 -0700 (PDT) From: Jon Harrop To: "'Gerd Stolpmann'" Cc: "'Caml List'" 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> <029701cbff90$7a874510$6f95cf30$@ffconsultancy.com> <1303331453.8429.1282.camel@thinkpad> In-Reply-To: <1303331453.8429.1282.camel@thinkpad> Date: Thu, 21 Apr 2011 00:33:04 +0100 Organization: Flying Frog Consultancy Message-ID: <02c801cbffb3$4c88be50$e59a3af0$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFhMASujb2QG2h3N2h7/lJjoQ23OAIYQRkZAge6bucBi7oV8gIGVE8/AmcCvngCudDnUAFa0vZTAUOS6jwBiHf14JS1DxGA Content-Language: en-gb Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3KNXNsr011448 X-Validation-by: jon@ffconsultancy.com Subject: RE: [Caml-list] Efficient OCaml multicore -- roadmap? Gerd wrote: > I wrote: > > Yes. The hardware maintains the illusion of shared memory so the > programmer only need optimize on the basis of an accurate cost model. There is > no need to burden the programmer with message passing and manual memory > management. > > I don't understand this last sentence. Message passing is just an abstract > concept (i.e. an interface) which can e.g. be implemented with a shared buffer > (or the illusion thereof) or other data structure that decouples sender and > receiver processes. Similarly, caches are an abstract concept that can be implemented in different ways. We could also emulate the CPU cache in software and provide an abstract interface for our emulated cache. Does this also seem like a good idea given that the context is multicore parallelism, i.e. performance? > Are you against using the right interfaces when they are > appropriate? As long as the hardware provides shared memory then using shared memory directly is the right interface in the context of multicore parallelism. > We don't want to burden the programmer with too low-level > details, do we? Exactly. In this context, message passing is a low-level implementation detail that can and should be confined to the hardware layer. The programmer should be oblivious to the number of cores and threads and oblivious to the low-level communication going on between them and to the sender and receiver processes you mentioned. They need only be aware of high-level concepts like cache complexity. This makes parallel programming easy and that is why it has become the defacto-standard approach for multicore programming. After all, we could easily write parallel programs using manual message passing between explicit senders and receivers but it is harder and slower and, therefore, completely pointless. I should note that your abstraction is of value in the context of concurrent programming when throughput is irrelevant because it can be used to expose a much simpler "memory model" but that is not relevant to this discussion about multicore parallelism. Cheers, Jon.