When bigger isn't betterSo for most part going 64-bit won't make much of a difference unless you're doing grahpics and video work, encoding or encrypting, or doing a lot of compression. However in some cases, especially on older 64-bit CPUs, running a 64-bit operating system can actually impact performance.
As structures on a 64-bit system are 64-bits wide, they take up more memory. Data, addresses, pointers and the rest are all larger and so code size can be, and often is, bigger as well. One reason for this is that 64-bit compilers align data on 64-bit boundaries, and structures that are less than 64-bits (such as a 32-bit integer) are 'padded' when they are aligned. A 64-bit version of a program is often larger than the 32-bit version of the same.
This may not mean much on disk in this age of 1TB drives, but when that code goes into memory on your average 2GB machine, it starts to add up. By way of a quick test you can grab a Linux distribution LiveCD in both 32-bit and 64-bit varieties and load them up on a PC then check their memory usage. Using the latest Ubuntu 8.10 LiveCD for example, after letting the boot settle for two minutes the memory usage on the 64-bit version is 129M more than the 32-bit one, for the exact same software, and before loading any applications. It's a small but not insignificant hit for a 2GB machine, and more than one tenth of the available memory on a 1GB machine. Additionally, larger code means less efficient use of a CPU's L1 and L2 caches, causing more cache misses and slowing processing down.
For this reason older CPUs, and especially 1GB systems, are better off sticking with a 32-bit operating system, even if the CPU is 64-bit capable.
Finally, although it's less of an issue now, the transition to 64-bit software takes time and while there are 64-bit versions of just about everything under Linux (because the same source can be easily re-compiled for 64-bit systems) the same is not true for Windows, where the vast majority of software is still 32-bit only - and always will be for the authors of programs who don't release source code and don't update their programs. It's entirely possible right now to disable 32-bit support and run a pure 64-bit system under Linux, but if Microsoft released a 64-bit only version of Windows it would be suicide.
The futureUnlike the jump from 32-bit we can (presumably) assume a bigger address space won't be the main advantage of 128-bit CPUs when they arrive. That said, they could already be of use today with multimedia extensions using 128-bits, key sizes for cryptography often being 128-bits long, and IPv6 addresses stored in 128-bits too. Manipulation of these data structures would be faster on a 128-bit CPU.
That said, they would of course increase the address space as well - to sizes so large they are hard to comprehend: 128-bit processors would allow for 274,877,906,944 yottabytes of memory (That's 302,231,454,903,657,293,676,544 terabytes. Yes, that's a lot of pr0n.)
The reign of the 16-bit machines lasted around nine years, and 32-bit around 18 years. Conceivably, we might expect 64-bit to last us another 36 odd years at least. And that sounds like a lot, and then you remember how fast technology moves in the realm of computing, for which 36 years is all but an eon. We can barely predict how the landscape will look five years from now, so we'll just put it on the books that 128-bit CPUs will be out there in time, but when is anybody's guess.
Issue: 133 | February, 2012