Re: Server recommendations

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