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@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
