On Mon, Jun 12, 2006 at 05:19:46PM -0600, David Boreham wrote:
> What they are saying is strictly true : 64-bit pointers tend to increase
> the working set size
> of an application vs. 32-bit pointers. This means that any caches will
> have somewhat lower
> hit ratio. Also the bytes/s between the CPU and memory will be higher
> due to moving those larger pointers.
While bytes/s will go up what really matters is words/s, where a word is
the size of a memory transfer to the CPU. Taking a simplistic view, 8
bit CPUs move data into the CPU one byte at a time; 16 bit CPUs, 2
bytes; 32 bit, 4 bytes, and 64 bit, 8 bytes. The reality is a bit more
complicated, but I'm 99.9% certain that you won't see a modern 64 bit CPU
tranfering data in less than 64 bit increments.
> However, an application that needs to work on > around 2G of data will
> in the end be
> much faster 64-bit due to reduced I/O (it can keep more of the data in
> memory).
There's not an automatic correlation between word size and address
space, just look at the 8088, so this depends entirely on the CPU.
> I worked on porting a large database application from 32-bit to 64-bit. One
> of our customers required us to retain the 32-bit version because of
> this phenomenon.
>
> In measurements I conducted on that application, the performance
> difference wasn't
> great (10% or so), but it was measurable. This was with Sun Sparc hardware.
> It is possible that more modern CPU designs have more efficient 64-bit
> implementation than 32-bit, so the opposite might be seen too.
>
> Whether or not PG would show the same thing I can't say for sure.
> Probably it would though.
It's going to depend entirely on the CPU and the compiler. I can say
that in the 32 vs 64 bit benchmarking I've done using dbt2, I wasn't
able to find a difference at all on Sunfire Opteron machines.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461