Re: 64-bit vs 32-bit performance ... backwards?

On Jun 12, 2006, at 3:28 PM, Anthony Presley wrote:

> Hi all!
>
> I had an interesting discussion today w/ an Enterprise DB developer
> and
> sales person, and was told, twice, that the 64-bit linux version of
> Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
> is SIGNIFICANTLY SLOWER than the 32-bit version.  Since the guys of
> EDB
> are PostgreSQL ..... has anyone seen that the 64-bit is slower than
> the
> 32-bit version?
>
> I was told that the added 32-bits puts a "strain" and extra "overhead"
> on the processor / etc.... which actually slows down the pointers and
> necessary back-end "stuff" on the database.
>
> I'm curious if anyone can back this up .... or debunk it.  It's about
> the polar opposite of everything I've heard from every other database
> vendor for the past several years, and would be quite an eye-opener
> for
> me.
>
> Anyone?

It's unsurprising for code written with 64 bit pointers ("64 bit
code") to be a little
slower than 32 bit code. The code and data structures are bigger,
more has to
be copied from main memory, fewer cache hits, all those bad things.

On CPUs with a uniform instructions set in both 32 and 64 bit modes
you're
only likely to see improved performance in 64 bit mode if your code can
take advantage of the larger address space (postgresql doesn't).

Some x86-esque architectures provide a somewhat different instruction
set in their 64 bit mode, with more programmer visible registers. The
increase in performance they can offer (with the right compiler) can
offset
the reduction due to pointer bloat, in some cases.

Empirically... postgresql built for 64 bits is marginally slower than
that built
for a 32 bit api on sparc. None of my customers have found 64 bit x86
systems to be suitable for production use, yet, so I've not tested on
any
of those architectures.

Cheers,
   Steve