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=0.0 required=5.0 tests=none 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 0B897BBAF for ; Fri, 11 Jul 2008 15:45:18 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogGAAcAd0jUnw6FZWdsb2JhbACCOI9vEgIeA50B X-IronPort-AV: E=Sophos;i="4.30,345,1212357600"; d="scan'208";a="27239119" Received: from pih-relay06.plus.net ([212.159.14.133]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 11 Jul 2008 15:45:17 +0200 Received: from [90.192.139.241] (helo=beast.local) by pih-relay06.plus.net with esmtpa (Exim) id 1KHIw0-0007h9-6b for caml-list@yquem.inria.fr; Fri, 11 Jul 2008 14:45:16 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] thousands of CPU cores Date: Fri, 11 Jul 2008 14:43:53 +0100 User-Agent: KMail/1.9.9 References: <1215781305.28798.19.camel@flake.lan.gerd-stolpmann.de> In-Reply-To: <1215781305.28798.19.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807111443.53853.jon@ffconsultancy.com> X-Plusnet-Relay: c89b896b9cf47e01011185a980c0b549 X-Spam: no; 0.00; gerd:01 stolpmann:01 generations:01 parallelism:01 fpls:01 intel's:01 ocaml:01 quicker:98 revolution:98 revolution:98 frog:98 wrote:01 caml-list:01 gcs:01 tail:01 On Friday 11 July 2008 14:01:45 Gerd Stolpmann wrote: > In the past, it was very important for hardware vendors that existing > software runs quicker on new CPU generations. This is no longer true for > multicore. So unless there is a software revolution that makes it simple > to exploit multicore, we won't see 1024-cores for the masses. That revolution happened several years ago when everyone migrated to the JVM and CLR and their concurrent GCs made it easy to exploit multicores. Ironically, given the hype surrounding functional programming for parallelism, all open source FPLs were left behind. On Linux, even the future prospects are bleak: no tail calls on the JVM, prohibitively difficult to implement an efficient concurrent GC yourself and Mono is going nowhere. > Well, there is a another option for the chip industry. Instead of > keeping the die at some size and packing more and more cores on it, they > can also sell smaller chips for less. Basically, this alternate path > already exists (e.g. Intel's Atom). Of course, this makes this industry > more boring, and they would turn into more normal industrial component > suppliers. Other factors are certainly playing an increasingly important role. ARM cores are now outselling Intel and AMD thanks to an exploding embedded market. ARM CPUs found their way into ultramobiles and are now moving up into laptops. Microsoft are supporting ARM-based Windows and .NET. However, even ARM recently went multicore and their GHz quadcore Cortex-A8 with integrated nVidia graphics is going into mobile phones. By the end of this year, OCaml will not even be able to tap the power of my mobile phone... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e