From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thelema314@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id 71087BC57
	for <caml-list@yquem.inria.fr>; Tue, 16 Nov 2010 07:46:40 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8BALO34UxKfVO0k2dsb2JhbACUW416CBUBAQEBCQkKCREDH6ROiWKCGIUFLohZAQEDBYVGBIRahX6DDGY
X-IronPort-AV: E=Sophos;i="4.59,204,1288566000"; 
   d="scan'208";a="65795720"
Received: from mail-pv0-f180.google.com ([74.125.83.180])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Nov 2010 07:46:39 +0100
Received: by pvg7 with SMTP id 7so44204pvg.39
        for <caml-list@yquem.inria.fr>; Mon, 15 Nov 2010 22:46:38 -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
         :user-agent:mime-version:to:subject:references:in-reply-to
         :content-type:content-transfer-encoding;
        bh=sBA8ZV6C5M6ffFKtpghZLk6DdZmDAdN+psvmjIdbe30=;
        b=PJXFO3EwzYUIfh2tZQL6WhMe396zcmhy7hKY5TdnubJTGuKX/7Ufr84ZRMH8T3Gfrz
         v8+y+3tdwT6+cAsAa9u6wMNZsvCmMyEaAdbSvzSSxUG+I7W2T/T7bZl/doSZM129sAGC
         EWXsosDiltMeCFz/zvIfsXgBarrxr9GG+OIHE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=d7lCRsXJXNim5TuyDuDbnWsdo4vdv7r05Vxzi7lZkrARJV3yC4X+xZGVvLvdwwFBU+
         RCaZQ9Qj/eX0x77bUlpvVYP9l6VHGNG4eZH7wvQ8x8wabwy2IlUCRJWt5Lj93eqoQRHr
         YtsPalEZ5AITaozyXsDMFgaCBc0cOL3oA4SYc=
Received: by 10.142.149.26 with SMTP id w26mr424321wfd.217.1289889998505;
        Mon, 15 Nov 2010 22:46:38 -0800 (PST)
Received: from [192.168.2.2] (adsl-71-135-99-49.dsl.pltn13.pacbell.net [71.135.99.49])
        by mx.google.com with ESMTPS id y42sm974416wfd.10.2010.11.15.22.46.36
        (version=SSLv3 cipher=RC4-MD5);
        Mon, 15 Nov 2010 22:46:37 -0800 (PST)
Message-ID: <4CE228CA.3030503@gmail.com>
Date: Mon, 15 Nov 2010 22:46:34 -0800
From: Edgar Friendly <thelema314@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13pre) Gecko/20101111 Shredder/3.1.7pre
MIME-Version: 1.0
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] SMP multithreading
References: <20101115182737.42b8dcae@loki.yggdrasil.draxit.de>
In-Reply-To: <20101115182737.42b8dcae@loki.yggdrasil.draxit.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; speedups:01 ocaml:01 runtime:01 ocaml:01 cheers:01 edgar:98 acb:98 15.:98 1.5:98 wrote:01 caml-list:01 caml-list:01 caml:02 functional:02 wolfgang:02 

On 11/15/2010 09:27 AM, Wolfgang Draxinger wrote:
> Hi,
>
> I've just read
> http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html
> in particular this paragraph:
> | What about hyperthreading?  Well, I believe it's the last convulsive
> | movement of SMP's corpse :-)  We'll see how it goes market-wise.  At
> | any rate, the speedups announced for hyperthreading in the Pentium 4
> | are below a factor of 1.5; probably not enough to offset the overhead
> | of making the OCaml runtime system thread-safe.
>
> This reads just like the "640k ought be enough for everyone". Multicore
> systems are the standard today. Even the cheapest consumer machines
> come with at least two cores. Once can easily get 6 core machines today.
>
> Still thinking SMP was a niche and was dying?
>
> So, what're the developments regarding SMP multithreading OCaml?
>
>
> Cheers
>
> Wolfgang
>
At the risk of feeding a (possibly unintentional) troll, I'd like to 
share some possibly new thoughts on this ever-living topic.

It looks like high-performance computing of the near future will be 
built out of many machines (message passing), each with many cores 
(SMP).  One could use message passing for all communication in such a 
system, but a hybrid approach might be best for this architecture, with 
use of shared memory within each box and message passing between.  Of 
course the best choice depends strongly on the particular task.

In the long run, it'll likely be a combination of a few large, powerful 
cores (Intel-CPU style w/ the capability to run a single thread as fast 
as possible) with many many smaller compute engines (GPGPUs or the like, 
optimized for power and area, closely coupled with memory) that provides 
the highest performance density.

The question of how to program such an architecture seems as if it's 
being answered without the functional community's input. What can we 
contribute?

E.