X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 91BC8D79DE for ; Wed, 24 Aug 2005 17:03:49 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 85114-06 for ; Wed, 24 Aug 2005 20:03:47 +0000 (GMT) Received: from boutiquenumerique.com (boutiquenumerique.com [82.67.9.10]) by svr1.postgresql.org (Postfix) with ESMTP id 0EBB4D79CD for ; Wed, 24 Aug 2005 17:03:45 -0300 (ADT) Received: (qmail 1694 invoked from network); 24 Aug 2005 22:04:08 +0200 Received: from unknown (HELO localhost) (boutiquenumerique-lists@192.168.0.4) by boutiquenumerique.com with SMTP; 24 Aug 2005 22:04:08 +0200 Date: Wed, 24 Aug 2005 22:03:43 +0200 To: stange@rentec.com, mark@mark.mielke.cc Subject: Re: Caching by Postgres Cc: "Donald Courtney" , "William Yu" , pgsql-performance@postgresql.org References: <20050823171045.12112.qmail@web51309.mail.yahoo.com> <20050823124323.710a9dd3.frank@wiles.org> <430B6DE3.6040109@sun.com> <430C7448.7030103@sun.com> <20050824173055.GA11788@mark.mielke.cc> <430CC0AD.5040400@rentec.com> From: PFC Organization: =?iso-8859-15?Q?La_Boutique_Num=E9rique?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <430CC0AD.5040400@rentec.com> User-Agent: Opera M2/8.0 (Linux, build 1095) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] X-Spam-Level: X-Archive-Number: 200508/405 X-Sequence-Number: 14152 > At least on Sparc processors, v8 and newer, any double precision math > (including longs) is performed with a single instruction, just like for > a 32 bit datum. Loads and stores of 8 byte datums are also handled via > a single instruction. The urban myth that 64bit math is > different/better on a 64 bit processor is just that; yes, some lower > end processors would emulate/trap those instructions but that an > implementation detail, not architecture. I believe that this is all > true for other RISC processors as well. > > The 64bit API on UltraSparcs does bring along some extra FP registers > IIRC. It's very different on x86. 64-bit x86 like the Opteron has more registers, which are very scarce on the base x86 (8 I think). This alone is very important. There are other factors as well. > Solaris, at least, provided support for far more than 4GB of physical > memory on 32 bit kernels. A newer 64 bit kernel might be more > efficient, but that's just because the time was taken to support large > page sizes and more efficient data structures. It's nothing intrinsic > to a 32 vs 64 bit kernel. Well, on a large working set, a processor which can directly address more than 4GB of memory will be a lot faster than one which can't, and has to play with the MMU and paging units !