Michael Stapleton wrote:
While we are talking about 32 | 64 bit processes;
Which one is better?
Faster?
More efficient?
Initially, assuming a 32 verses 64 bit build doesn't change any
algorithms...
On x86, a 64 bit build of the same program will typically run ~50%
faster if it's CPU-bound, because more registers are available for the
compiler/optimizer to use. There's a wide variance depending what the
program does (I have an example which gets much better than 50% gain).
If it's not CPU-bound (and most things aren't), it makes no difference.
However, if the larger pointers and data items push the 64 bit program's
working set size over what fits in the CPU cache whereas the 32 bit
version does fit in the cache, then you can in theory see the 32 bit
version winning.
On sparc, a 64 bit build of the same program does not benefit from any
more registers like on x86, but it does pay the price for a larger
working set size, and I typically see a 10-14% performance reduction for
a CPU-bound program which has been just rebuilt 64bit.
However, if you can use the 64 bit address space to change the
algorithms used by your app, such as mmaping files rather than doing
loads of lseek/read/write ops, then you may see additional gains from
this, and on sparc that will often more than cancel out the reduction in
CPU performance by some way.
I wouldn't personally bother changing anything much which is shipped
with the OS (very rarely is the performance of things in /usr/bin an
issue). However, I would suggest taking these factors into account when
building the key applications your system is going to run, if you are
CPU-bound.
--
Andrew
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
