64 bit is the next logical step up.
The reason is mainly because the step to double (or half) the number of bits is easy to handle in software and hardware for systems that operate natively in a different size.
32-bit systems where already routinely dealing with 64 bit values internally, before 64-bit CPU's became available.
E.g: A 32-bit system can easily handle a 64-bit number by storing it in 2 32-bit variables/registers.
Dealing with a 48 bit number is awkward: You would need to either user a 32-bit and a 16-bit variable together or only use part of a 32-bit variable or use 3 16-bit variables. None of these solutions for 48-bit is optimal.
In general: Any system that works in X bits can easily handle sizes of (N * X) and (X / N), where N is a power of 2.
So the logic is 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and so on.
Every other size requires more complicated handling in hardware and/or software and is therefor sub-optimal.
So when going for a larger bit-size in hardware architecture it makes sense to use the same progression as it will only take a minor updates to Operation Systems, software and compilers to support the new bit-size.
(This all applies to the native bit-size for CPU registers. When you take about "number of address-lines" that address the RAM chips you may indeed see a smaller number then what is natural for the architecture.
Internally these CPU's use more bits, but not all bits are connected to real address-lines.
E.g: 20 lines on 8088 and 8086 cpu's, 20 lines on 80286 and 36 lines on Pentium II)
Best Answer
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
inttype. That's decided by the particular compiler implementation, and most of the popular compilers choose 32-bitinton 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.