Re: Caching by Postgres - Mailing list pgsql-performance

From Alan Stange
Subject Re: Caching by Postgres
Date
Msg-id 430CE1F0.3080205@rentec.com
Whole thread Raw
In response to Re: Caching by Postgres  (mark@mark.mielke.cc)
Responses Re: Caching by Postgres  (mark@mark.mielke.cc)
List pgsql-performance
mark@mark.mielke.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




pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Performance indexing of a simple query
Next
From: Michael Stone
Date:
Subject: Re: Caching by Postgres