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=1.0 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, SPF_NEUTRAL 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 D4390BB84 for ; Tue, 15 Jul 2008 18:01:04 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMCAGBmfEhDWxLCbmdsb2JhbACBWpBeNpw+ X-IronPort-AV: E=Sophos;i="4.30,367,1212357600"; d="scan'208";a="15130922" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail1-smtp-roc.national.inria.fr with ESMTP; 15 Jul 2008 18:01:04 +0200 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id B7BF31056D8 for ; Tue, 15 Jul 2008 12:01:03 -0400 (EDT) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: thousands of CPU cores Date: Tue, 15 Jul 2008 12:01:02 -0400 User-Agent: KMail/1.9.9 References: <200807110950.52327.jon@ffconsultancy.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807151201.03134.ober.14@osu.edu> X-Spam: no; 0.00; bandel:01 in-berlin:01 trivial:01 cheers:01 wrote:01 wrote:01 oliver:01 oliver:01 caml-list:01 stories:95 bits:05 osu:07 space:07 split:08 thousands:91 On Friday 11 July 2008, Sylvain Le Gall wrote: > 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... Re-mapping stuff into and out of virtual memory space is relatively trivial and doesn't require multiple processes. Multiple processes only give you the advantage of having all this memory mapped at once, split across processes though. So it may or may not be an actual improvement, depending on the application... Cheers, Kuba