Ron Johnson wrote:
> On Mon, 2003-10-06 at 01:43, Shridhar Daithankar wrote:
>>The best performance is by running 32 bit applications on 64 bit kernel/hardware
>>, according to a migration guide by HP. The reasoning is using space optimally
> Does HP have any AMD64 servers?
No. But while migrating from PA1.1 to PA2.0, they have had that pain..:-) And I
just went thr. opteron optimization guide from a link you provided. Basically
same stuff HP was pitching.
And I also configured a system on laclinux.com, just for curiosity. 2x
1.8GHz/4GB/36GBx2 10K RPM SCSI/Adaptec 29320 for $4800/- is damn cheap a system.
HP does not even start below $5K for 64 bit systems.
>>Imagine, if every long in pg is 8byte that would be waste most of the times.
>>However given a native 8 byte integer/float is available, there is no reason to
>>use a 8 byte data type unless required.
>From what I've read, longs are still 32-bit; it's only pointers
> that have upped to 64-bit.
I thought under 64 bits short==2 bytes, int==4 bytes and long==8 bytes. i.e.
this is another architecture/word length where int != long in size.
>>Its about exploiting wide and fast bus of a 64bit machine in a most optimal
>>fashion. I think except for kernel and glibc, nothing else requires 64 bit in
>>general unless application insists on doing it's own caching.
> In PG's case, if the app uses BIGINT a lot, then 64-bit PG should
> be more efficient.
Possibly. Source code availability has a great advantage here. Compile the way
you want.
But still, as long as PG in itself does not use 8 byte data types exclusively, I
would like it to be a 32 bit app. A bigint is 8 byte on a 64 bit machine,
whether or not the app. is 32 bit.
> Besides, in 64-bit mode, the compilers get to use 2x as many GP
> registers, which should increase performance.
Well, if a 32 bit app. is optimised for opteron, compiler will use those
registers anyway..:-) At least on HP, such trick can be done. IMO thats very
handy..
Shridhar
