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.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 3F509BBB7 for ; Fri, 11 Jul 2008 11:29:14 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPPEdkjAXQIn/2dsb2JhbACwTg X-IronPort-AV: E=Sophos;i="4.30,344,1212357600"; d="scan'208";a="14996823" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Jul 2008 11:29:14 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m6B9T8IS022464 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 11 Jul 2008 11:29:13 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnECAPPEdkhQW+UCgWdsb2JhbACSLgEBECAEnWo X-IronPort-AV: E=Sophos;i="4.30,344,1212357600"; d="scan'208";a="13026433" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 11 Jul 2008 11:29:13 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KHEwA-0002aU-NX for caml-list@inria.fr; Fri, 11 Jul 2008 09:29:10 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jul 2008 09:29:10 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jul 2008 09:29:10 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: thousands of CPU cores Date: Fri, 11 Jul 2008 09:29:02 +0000 (UTC) Message-ID: References: <1215732802.48769c4277e80@webmail.in-berlin.de> <200807110950.52327.jon@ffconsultancy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/pre0.9.9-102 (Linux) Sender: news X-Miltered: at concorde with ID 487727E4.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 bandel:01 in-berlin:01 parallelism:01 runtime:01 wrote:01 wrote:01 oliver:01 oliver:01 data:02 bugs:03 bugs:03 threaded:03 stories:95 correctly:04 On 11-07-2008, Jon Harrop wrote: > On Friday 11 July 2008 07:26:44 Sylvain Le Gall wrote: >> On 10-07-2008, Oliver Bandel wrote: > > However, any serious power users will already be on 64-bit where these limits > have been relegated to quaint stories your grandpa will tell you. > As you cannot ignore people running on Windows, you cannot ignore people running on older hardware. If you plan to program a big DB that will use more than 3GB on 32 bits hardware, you should take care of this memory limit and consider splitting your application into several process... The "process" approach to parallelism: - is basic but should fit to most OS around - require work to split application correctly, wrt to require communication bandwidth - cannot take advantage of shared memory (well you CAN share memory, but it is not as easy as in thread/single process) - increase safety by really separating data I mean, you can get really good performance with threaded app BUT you have many drawbacks that create weird behavior/undetectable runtime bugs. Process approach is portable and limit possible bugs to communication... Regards, Sylvain Le Gall