From: mark@mark.mielke.cc
To: pgsql-performance@postgresql.org
Subject: Re: Caching by Postgres
Date: Wed, 24 Aug 2005 20:21:05 -0400
Message-ID: <20050825002105.GB18300@mark.mielke.cc> (raw)
In-Reply-To: <20050824210909.GN8667@mathom.us>
References: <20050823171045.12112.qmail@web51309.mail.yahoo.com>
<20050823124323.710a9dd3.frank@wiles.org>
<430B6DE3.6040109@sun.com>
<deg68k$16gh$1@news.hub.org>
<430C7448.7030103@sun.com>
<20050824173055.GA11788@mark.mielke.cc>
<430CC0AD.5040400@rentec.com>
<20050824193441.GA13772@mark.mielke.cc>
<20050824210909.GN8667@mathom.us>
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/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark@mark.mielke.cc
Subject: Re: Caching by Postgres
In-Reply-To: <20050825002105.GB18300@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox