(10-06-2009, 07:06 AM)echosierra Wrote: 32-bit computers are butting up against the address limit, and even with things like PAE strapped on it's only delaying the inevitable. Moving to 64-bit guarantees you won't run out of address space for a very long time, somewhere between '100 years from now' and 'armageddon'.
If memory serves, Intel's memory addressing limit in 64 bit is currently 40 bits, which is "only" 1 Terrabyte, which is almost certainly obtainable in the not-so-distant future. AMD's is 48 bits, which is much closer to the 'armageddon' timeframe.
There's nothing stopping Intel from upping the addressing limit on later CPU models of course, and I'm sure they will long before we actually reach the point of stuffing 1TB of ram into desktop PCs. But yeah, go figure. The whole of x86-64 CPU design is a hack.
By the way, I did learn something new the other day about x64, which helps explain why many applications do experience a nice speedup when built as x64 over x32. Turns out the calling convention ABI (advanced binary interface) for x64 is
very nicely designed, and via utilizing the extra registers it's able to provide pretty significant speedups. Nice things include:
* Improved exception handling model. Approx. 33% less overhead for entering a
try block or setting up the exception handler stackframe in a function that creates unwindable objects (anything with a destructor).
* __fastcall is the "norm", and
all functions by default use four 64-bit registers for passing the first four parameters. So the stack need only be used for the most verbosely parameterized of functions.
* Floats and Doubles are passed via MMX or XMM registers (x86-32 ABI still requires they be passed using the FPU stack, which means an instruction needed to transfer the float/double value to the FPU, and another to push it onto the stack).
Of course most of that has little effect on a PCSX2 recompiler. The recs don't use any C++ objects except at the entry-point (which is only called rarely, when resetting the emu basically), so the exception optimization would be nil. We also use all 2-parameter functions, and the pre-existing __fastcall covers optimizing them to register already. And we use almost no instances of float/double in actual C code, save for the FPU and VU interpreters. So the general rule of thumb regarding PCSX2 compiled to 64 bit still holds: it's just not quite worth the effort (yet).
But! If you're dealing with an application that doesn't rely on a recompiler, then all of those things will typically be nice improvements in the resulting compiled code efficiency.
Edit: and, oh yes, the PCSX2 interpreters would be noticeably faster if compiled in x86-64, but not sure anyone would much care.
And, of course, none of this is really relevant to the topic of switching one's
operating system to 64-bit as the OP inquires. All of these things require applications built natively for x64, and/or .NET/Java apps that are compiled on-the-fly. Running 32 bit apps on 64 bit changes nothing really.