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 23645D730C for ; Wed, 24 Aug 2005 21:30:44 -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 49604-02 for ; Thu, 25 Aug 2005 00:30:38 +0000 (GMT) Received: from mail.envyfinancial.com (unknown [206.248.142.186]) by svr1.postgresql.org (Postfix) with ESMTP id 3E831D7300 for ; Wed, 24 Aug 2005 21:30:37 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envyfinancial.com (Postfix) with ESMTP id 1BCCF1B6AA for ; Wed, 24 Aug 2005 20:21:06 -0400 (EDT) Received: from mail.envyfinancial.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18249-04 for ; Wed, 24 Aug 2005 20:21:05 -0400 (EDT) Received: by mail.envyfinancial.com (Postfix, from userid 500) id C58761B8F0; Wed, 24 Aug 2005 20:21:05 -0400 (EDT) Date: Wed, 24 Aug 2005 20:21:05 -0400 From: mark@mark.mielke.cc To: pgsql-performance@postgresql.org Subject: Re: Caching by Postgres Message-ID: <20050825002105.GB18300@mark.mielke.cc> 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> <20050824193441.GA13772@mark.mielke.cc> <20050824210909.GN8667@mathom.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050824210909.GN8667@mathom.us> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new at mail.envyfinancial.com X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.214 required=5 tests=[AWL=0.036, NO_REAL_NAME=0.178] X-Spam-Level: X-Archive-Number: 200508/413 X-Sequence-Number: 14160 On Wed, Aug 24, 2005 at 05:09:09PM -0400, Michael Stone wrote: > On Wed, Aug 24, 2005 at 03:34:41PM -0400, mark@mark.mielke.cc wrote: > >It isn't an urban myth that 64-bit math on a 64-bit processor is > >faster, at least if done using registers. It definately is faster. > >It may be an urban myth, though, that most applications perform > >a sufficient amount of 64-bit arithmetic to warrant the upgrade. > The mjor problem is that the definition of "64bit processor" is fuzzy. > The major slowdown of "64bitness" is the necessity of carting around > 64 bit pointers. It's not, however, necessary to do 64bit pointers to > get 64bit registers & fast 64 bit ops. E.g., sgi has "n32" & "n64" abi's > which can access exactly the same instruction set & registers, the > difference between them is the size of pointers and whether a "long" is > the same as a "long long". Any discussion of "64 bit processors" is > doomed from the start because people tend to start making implementation > assumptions on top of an already vague concept. Current & future > discussions are tinged by the fact that amd64 *doubles* the number > of registers in 64 bit mode, potentially providing a major speedup--but > one that doesn't really have anything to do with being "64bit". > Pretty much any discussion of 64 bit mode really needs to be a > discussion of a particular abi on a particular processor; talking about > "64 bit processors" abstractly is a waste of time. Agree. :-) As this very thread has shown! Hehe... There is no way the manufacturers would release two machines, side by side that could easily show that the 64-bit version is slower for regular application loads. They added these other things specifically to mask this... :-) Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/