> (This case assumes a 64-bit Ultra-Sparc running on a 64-bit kernel)
> It seems obvious to me that 32-bits applications in general gets very
> noticable decrease in performance compared to if they were 64-bits
It's not obvious to me at all. Where did you get this idea from? Intel by
Quote:> Anyone who knows where to find any document that supports me on this?
Quote:> Or am I wrong? (Any documents that can prove me wrong?)
You are and yes, there are documents. A long time ago, while Digital was a
Unix company and they had a usable web site, it was rather easy to find
whitepapers and other technical documentation about Alpha. I don't know
how to find them now and I only have printouts somewhere.
Anyway, some of them were describing performance measurements on Alphas
with 32-bit and 64-bit code (these two numbers applie to the pointer
size). And, predictably, the code with 64-bit pointers was slower. Why?
Because you still have the same size of CPU cache, but you can put less
data in there. Your memory usage increases as well, so there is a
potential case when your machine would start swapping with 64-bit app, but
wouldn't with 32-bit app.
Measurements done by Digital's engineers showed that performance decrease
was up to 15%. This is the number for Alpha CPU version which they had at
the time. It does not mean that it's the same for modern Alphas and it
does not mean that it has any connection with SPARCs in general and Sun's
implementation in particular. However, the reason for performance loss is
still the same: pointers take more space, so 64-bit apps on SPARCs will
usually be slower than the equivalent 32-bit apps.
The obvious exception is an application which does a lot of 64-bit integer
arithmetic (excluding pointer arithmetic). I don't know many in this camp.
Coming to think about it, I don't know any. The other reason for using a
64-bit application is the address space. If it doesn't fit in 32 bits, then
you need 64-bit pointers.
To continue on Alpha: Digital didn't have installed 32-bit base to
support, so they could choose if they'd ship only 64-bit OS or a dual
32/64-bit one. Since performance decrease wasn't large, they decided to
ship a pure 64-bit OS, in order to avoid maintenance hassle with dual
libraries and binaries. I think it was a good decision. However, if you
really want to, you can use 32-bit pointers on Alphas under Digital
Unix/Tru64 with the native compiler. You'd have to process the system
include files first and then invoke the compiler with -taso option.
There's a man page describing the process, but I forgot it's name.
.-. .-. I will always cherish the initial misconceptions I had
(_ \ / _) about you.