Re: Caching by Postgres

From: Alan Stange <stange(at)rentec(dot)com>
To: mark(at)mark(dot)mielke(dot)cc
Cc: Donald Courtney <Donald(dot)Courtney(at)Sun(dot)COM>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Caching by Postgres
Date: 2005-08-24 21:09:04
Message-ID: 430CE1F0.3080205@rentec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

mark(at)mark(dot)mielke(dot)cc wrote:
> 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.
>
The older 32bit RISC processors do have 64 bit registers, ALUs and
datapaths, and they are marketed toward high end scientific computing,
and you're claiming that such a processor is slower than one which has
the addition of 64 bit pointers added to it?

As an example, an UltraSparc running a 32 bit kernel+application will
have the same double precision floating point performance as one
running a 64bit kernel+application (except for the additional FP
registers in the 64bit API). For a function like daxpy, it's the exact
same hardware running the exact same instructions! So why do you think
the performance would be different?

I believe the IBM Power processors also upped everything to double
precision internally because of some details of the "multiply-add fused"
instructions. It's been a few years since I taught H&P to CS
undergrads, but I'm fairly sure the details are all the same for MIPS
processors as well.

-- Alan

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Stone 2005-08-24 21:09:09 Re: Caching by Postgres
Previous Message Jim C. Nasby 2005-08-24 20:57:44 Re: Read/Write block sizes