32-bit vs. 64-bit systems

Solution 1:

Note: These answers apply to standard x86-based PC CPUs (Intel and AMD) and Windows (as typically configured for end-users). Other 32-bit or 64-bit chips, other OSes, and other OS configurations can have different tradeoffs.

From a technical perspective, a 64-bit OS gives you:

• Allows individual processes to address more than 4 GB of RAM each (in practice, most but not all 32-bit OSes also limit the total usable system RAM to less than 4 GB, not just the per-application maximum).

• All pointers take 8 bytes instead of 4 bytes. The effect on RAM usage is minimal (because you're not likely to have an application filled with gigabytes of pointers), but in the worst theoretical case, this can make the CPU cache be able to hold 1/2 as many pointers (making it be effectively 1/2 the size). For most applications, this is not a huge deal.

• There are many more general-purpose CPU registers in 64-bit mode. Registers are the fastest memory in your entire system. There are only 8 in 32-bit mode and 16 general purpose registers in 64-bit mode. In scientific computing applications I've written, I've seen up to a 30% performance boost by recompiling in 64-bit mode (my application could really use the extra registers).

• Most 32-bit OSes really only let individual applications use 2 GB of RAM, even if you have 4 GB installed. This is because the other 2 GB of address space is reserved for sharing data between applications, with the OS, and for communicating with drivers. Windows and Linux will let you adjust this tradeoff to be 3 GB for applications and 1 GB shared, but this can cause problems for some applications that don't expect the change. I'm also guessing it might cripple a graphics card that has 1 GB of RAM (but I'm not sure). A 64-bit OS can give individual 32-bit applications closer to the full 4 GB to play with.

From a user's perspective:

• Application speed is usually faster for a 64-bit application in a 64-bit OS compared to the 32-bit version of the application on a 32-bit OS, but most users won't see this speed-up. Most applications for normal users don't really take advantage of the extra registers or the benefits are balanced out by bigger pointers filling up the cache.

• If you have any memory hog applications (like photo editors, video processing, scientific computing, etc.), if you have (or can buy) more than 3 GB of RAM, and you can get a 64-bit version of the application, the choice is easy: use the 64-bit OS.

• Some hardware doesn't have 64-bit drivers. Check your motherboard, all plug-in cards, and all USB devices before making the switch. Note that in the early days of Windows Vista, there were lots of problems with drivers. These days things are generally better.

• If you run so many applications at a time that you're running out of RAM (usually you can tell this because your computer starts getting really slow and you hear the hard disk drive crunching), then you'll want a 64-bit OS (and sufficient RAM).

• You can run 32-bit applications (but not drivers) in 64-bit Windows with no problems. The worst slowdown I've measured for a 32-bit application in 64-bit Windows is about 5% (meaning that if it took 60 seconds to do something in 32-bit Windows, it took at most 60*1.05 = 65 seconds with the same 32-bit application in 64-bit Windows).

What 32-bit vs. 64-bit does not imply:

On x86 systems, 32-bit vs. 64-bit directly refers to the size of pointers. That's all.

• It does not refer to the size of the C int type. That's decided by the particular compiler implementation, and most of the popular compilers choose 32-bit int on 64-bit systems.

• It does not directly refer to the size of normal non-pointer registers. However, usage of 64-bit arithmetic registers happens to require that the application and OS be running in 64-bit pointer mode too.

• It does not directly refer to the size of the physical address bus. For example, a system with 64 bit wide cache lines and a maximum of 512GiB of memory only needs 33 bits in its address bus (i.e. log2(512*1024**3) - log2(64) = 33).

• It does not refer to the size of the physical data bus: that's more related to manufacturing costs (number of pins in the CPU socket) and cache line sizes.

Solution 2:

Basically you can do everything to a bigger scale:

1. RAM per OS: RAM limit of 4GB on x86 for the OS (most of the time)
2. RAM per process: RAM limit of 4GB on x86 for processes (always). If you think this is not important, try running a huge MSSQL database intensive application. It will use > 4GB itself if you have it available and run much better.
3. Addresses: Addresses are 64bits instead of 32bits allowing you to have "bigger" programs that use more memory.
4. Handles available to programs: You can create more file handles, processes, ... Example on Windows x64 you can create > 2000 threads per process, but on x86 closer to a few hundred.
5. Wider programs available: From an x64 you can run both x86 and x64 programs. (Example windows: wow64, windows32 on windows64 emulation)
6. Emulation options: From an x64 you can run both x86 and x64 VMs.
7. Faster: Some calculations are faster on a 64-bit CPU
8. Dividing multiple system resources: A lot of RAM memory is very important when you want to run at least one VM which divides up your system resources.
9. Exclusive programs available: Several new programs only support x64. Example Exchange 2007.
10. Future obsolete x86?: Over time more and more 64-bit will be used and more and more x86 will not be used. So vendors will support only 64-bit more and more.

The 2 big types of 64-bit architectures are x64 and IA64 architectures. But x64 is the most popular by far.

x64 can run x86 commands as well as x64 commands. IA64 runs x86 commands as well, but it doesn't do SSE extensions. There is hardware dedicated on Itanium for running x86 instructions; it's an emulator, but in hardware.

As @Phil mentioned you can get a deeper look of how it works here.