From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id B6C0DBBAF for ; Sat, 26 Dec 2009 18:09:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBADfSNUvRVd2tkWdsb2JhbACbIz8BAQEBCQsKBxMDtwmEMwSBfg X-IronPort-AV: E=Sophos;i="4.47,456,1257116400"; d="scan'208";a="39355352" Received: from mail-qy0-f173.google.com ([209.85.221.173]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Dec 2009 18:09:02 +0100 Received: by qyk3 with SMTP id 3so3970997qyk.1 for ; Sat, 26 Dec 2009 09:09:01 -0800 (PST) Received: by 10.224.101.144 with SMTP id c16mr6821405qao.12.1261847341355; Sat, 26 Dec 2009 09:09:01 -0800 (PST) Received: from ?192.168.1.113? (24-241-22-95.dhcp.oxfr.ma.charter.com [24.241.22.95]) by mx.google.com with ESMTPS id 22sm8994736qyk.14.2009.12.26.09.08.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Dec 2009 09:08:58 -0800 (PST) Cc: Jon Harrop , caml-list@yquem.inria.fr Message-Id: <4FB6FE05-5C90-490C-8AE3-8E0E21CFF676@ezabel.com> From: orbitz@ezabel.com To: Gerd Stolpmann In-Reply-To: <1261357694.6545.89.camel@flake.lan.gerd-stolpmann.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [Caml-list] Re: OCaml is broken Date: Sat, 26 Dec 2009 12:08:52 -0500 References: <794713.82307.qm@web111510.mail.gq1.yahoo.com> <200912202114.42669.jon@ffconsultancy.com> <1261357694.6545.89.camel@flake.lan.gerd-stolpmann.de> X-Mailer: Apple Mail (2.936) X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 ocaml:01 model:01 20,:98 appliance:98 appliance:98 biological:98 threads:01 threads:01 wrote:01 homogeneous:01 heap:01 caml-list:01 On Dec 20, 2009, at 8:08 PM, Gerd Stolpmann wrote: >> The following web page describes a commercial machine sold by Azul >> Systems >> that has up to 16 54-core CPUs (=864 cores) and 768 GB of memory in >> a flat >> SMP configuration: >> >> http://www.azulsystems.com/products/compute_appliance.htm >> >> As you can see, a GC with shared memory can already scale across >> dozens of >> cores and memory access is no more heterogeneous than it was 20 >> years ago. >> Also, note that homogeneous memory access is a red herring in this >> context >> because it does not undermine the utility of a shared heap on a >> multicore. > > The benchmarks they mention can all easily be parallelized - that > stuff > you can also do with multi-processing. The interesting thing would > be an > inherent parallel algorithm where the same memory region is accessed > by > multiple threads. Or at least a numeric program (your examples seem to > be mostly from that area). I'm not sure if it is relevant here, but it should be noted that a lot of the performance gains Azul gets is because they have built their own chips that do a lot of tricks for you under the hood. Last I used an Azul Appliance, they perform quite poorly if you are hitting the same memory often from multiple threads (the machine I used was about 4x slower than an equivalent Intel machine for a single core). If the Azul tricks make it into desktop processors, that would likely be pretty great. Also, for what it's worth, lots of cores have actually been less performant in the type of computing I currently do. We want less cores and more physical boxes, making multiple processes running single threads a better solution for us. We tend to become memory IO bound by multiple cores (the bus cannot keep up with us). We are processing lots of biological data. For the record we are not using Ocaml for our project, just an observation of what model works well for us.