Date: Wed, 24 Aug 2005 15:34:41 -0400
From: mark@mark.mielke.cc
To: Alan Stange <stange@rentec.com>
Cc: Donald Courtney <Donald.Courtney@Sun.COM>,
	William Yu <wyu@talisys.com>, pgsql-performance@postgresql.org
Subject: Re: Caching by Postgres
Message-ID: <20050824193441.GA13772@mark.mielke.cc>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <430CC0AD.5040400@rentec.com>
User-Agent: Mutt/1.4.2.1i

On Wed, Aug 24, 2005 at 02:47:09PM -0400, Alan Stange wrote:
> 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.

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 benefit may be lost in the noise for an application such as
PostgreSQL. It takes, effectively, infinately longer to access
a disk page, than to increment a 64-bit integer in software.

For the lower end processors that emulate/trap these instructions,
they are being performed in software, along with the overhead of a
trap, and are therefore not a single instruction any more. We are
coming at this from different sides (which is good - perspective is
always good :-) ). From the Intel/AMD side of things, ALL non 64-bit
platforms are 'lower end processors', and don't emulate/trap the
instructions as they didn't exist (at least not yet - who knows what
clever and sufficiently motivated people will do :-) ).

> >If, however, you happen to have a very large amount of physical memory
> >- more memory than is supported by a 32-bit system, but is supported
> >by your 64-bit system, then the operating system should be able to use
> >this additional physical memory to cache file system data pages, which
> >will benefit PostgreSQL if used with tables that are larger than the
> >memory supported by your 32-bit system, and which have queries which
> >require more pages than the memory supported by your 32-bit system to
> >be frequently accessed. If you have a huge database, with many clients
> >accessing the data, this would be a definate yes. With anything less,
> >it is a maybe, or a probably not.
> 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.

Hehe. That's why I was so careful to qualify my statements. :-)

But yeah, I agree. It's a lot of hype, for not much gain (and some
loss, depending on what it is being used for). I only want one because
they're built better, and because I want to play around.

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/