32-bit vs. 64-bit systems

Question

What are the differences between 32-bit and 64-bit systems?

If you have used both of them, what kind of sharp differences have you experienced?

Would it be a problem to use 32-bit programs on 64-bit systems in some cases?

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.

Solution 3

Nothing is free: although 64-bit applications can access more memory than 32-bit applications, the downside is that they need more memory. All those pointers that used to need 4 bytes, now they need 8. For example, the default requirement in Emacs is 60% more memory when it's built for a 64-bit architecture. This extra footprint hurts performance at every level of the memory hierarchy: bigger executables take longer to load from disk, bigger working sets cause more paging and bigger objects mean fewer fit in the processor caches. If you think about a CPU with a 16K L1 cache, a 32-bit application can work with 4096 pointers before it misses and goes to the L2 cache but a 64-bit application has to reach for the L2 cache after just 2048 pointers.

On x64 this is mitigated by the other architectural improvements like more registers, but on PowerPC if your application can't use >4G it's likely to run faster on "ppc" than "ppc64". Even on Intel there are workloads that run faster on x86, and few run more than a 5% faster on x64 than x86.

Solution 4

A 64-bit OS can use more RAM. That's about it, in practice. 64-bit Vista/7 use fancier safety features for where they place vital components in RAM, but that's not really 'noticable' as such.

From ChrisInEdmonton:

A 32-bit operating system on an ix86 system with PAE can address up to 64 GB of RAM. A 64-bit operating system on x86-64 can access up to 256 TB of virtual address space, though this may be raised in subsequent processors, up to 16 EB. Note that some operating systems limit the address space further, and most motherboards will have additional restrictions.

Solution 5

Not sure I can answer all your questions without writing a whole essay (there's always Google...), but you don't need to design your apps differently for 64bit. I guess what is being referred to is that you have to be mindful of things like pointer sizes are no longer the same size as ints. And you have a whole load of potential problems with inbuilt assumptions on certain types of data being four bytes long that may no longer be true.

This is likely to trip up all kinds of things in your application - everything from saving/loading from file, iterating through data, data alignment, all the way to bitwise operations on data. If you have an existing codebase you are trying to port, or work on both, it is likely you will have a lot of little niggles to work through.

I think this is an implementation issue, rather than a design one. I.e. I think the "design" of say, a photo editing package will be the same whatever the wordsize. We write code that compiles to both 32bit and 64bit versions, and the design certainly does not differ between the two - it's the same codebase.

The fundamental "big deal" on 64bit is that you gain access to a much larger memory address space than 32bit. This means that you can really chuck in more than 4Gb of memory into your computer and actually have it make a difference.

I'm sure other answers will go into the details and benefits more than I.

In terms of detecting the difference then programatically you just check for the size of a pointer (e.g. sizeof (void*)). The answer of 4 means its 32 bits, and 8 means you are running in a 64bit environment.

View more solutions

Comments

[Admin]

There are many confusions here, and else where on the web, between physical addressing (access to ram) PEA affects this, mother board affects this, and logical addressing (virtual memory per process). On a 32 bit os the virtual memory is limited to 4GB minus what the kernel reserves. It is independent of RAM you could have 0.1MB or 8GB RAM and you would have exactly 4GB of virtual memory (but some reserved by kernel). PEA can be used to have more RAM, but is not a perfect answer as the kernel CAN NOT access it all.

[Admin]

Physical address bus length is independent of whether it's a 32 or 64-bit processor. Some 32-bit processors have address buses larger than 32 bits, and no 64-bit processor has a 64-bit address bus.

[Stu Thompson]

Agreed. In theory, the address space is 2^64. In practice, CPU manufacturers are using smaller values...like 2^40 or 2^48.

[Admin]

The 32-bit platform and the 4GB limitation is somewhat of a misnomer and is (was) mainly an operating system architectural choice/design limit. Really, the 4GB from 32-bits is really on a limit in an process VA space. The physical address supports 36-bits on Intel 32-bit CPU's

[Admin]

You make a good point which is certainly true. But the impact in the real world of PC users is that there machine is not going to use the full 4GB that they paid for. My Dad had this issue and is still confused that the 4GB he paid for cannot be fully used.

[Admin]

Appreciate your point, but just trying to drive the notion that the fix is not in the processor or going to 64-bits, it is just a matter of a slightly improved OS design. This is addressed, for example, on the enterprise versions of Windows even back in 32-bit versions. It allows for 64GB of RAM.

[Admin]

Technically, the limit doesn't disappear. It moves further out to where it is impractical/impossible to install that much RAM on a machine any time in the next decade or so.

[tzot]

Um. IA64 runs x86 commands. It doesn't do SSE extensions, though. There is hardware dedicated on Itanium for running x86 instructions; it's an emulator, but in hardware.

[bk1e]

A few years ago, Raymond Chen posted about the 2000 thread "limit", and it's more or less an urban legend: blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx

[David Thornley]

If you write programs that casually assume that certain pointer types are the same size as certain integral types, ur doin it rong. This has been true for a long time.

[David Thornley]

While the instruction set is better for x64 than x86, that will typically be unimportant. 64-bit code can be slower than 32-bit, also, because the instructions can get bigger, so fewer of them fit in the cache. (Unrolling loops, BTW, is a very questionable technique nowadays, since it will increase the number of cache misses.) Where I work, we need 64 bits for increased memory addressing.

[Admin]

David, The x64 and x86 instruction sets are almost identical, except for the operand size and some register prefixes. With IA64, aka Itanium aka Itanic, 64-bit codes would typically be 3x the x86 codes, and stress the instruction cache exactly as you say. That was a big factor in why that architecture failed miserably. But with x86 aka AMD64 aka EM64T, that code growth is typically only 10-20%.

[Robert]

@David: You're absolutely right. Unfortunately, there's a ton of code out there that does exactly that.

[Admin]

Although x64 makes more registers addressable, I'm not sure by how much it actually increases the number of physical registers available -- all recent x86 processors have many (> 100) "shadow" registers, and use "register renaming" + speculative execution to allow independent code paths to execute in parallel to a degree. In effect, if n independent code paths are executing, n times as many registers are available (until all shadow registers run out).

[Admin]

@j_random_hacker. You are absolutely right that those tricks are going on underneath the architecture. But no matter how many shadow registers are available, if the program needs to work with more than 8 data items and only 8 registers are exposed in the instruction set, the compiler must generate the store/reload instructions. So yes, X64 really does make twice as many registers "available"

[Marco van de Voort]

My experience is that this is way less, and is offset by the fact that the avg memblock to be moved is larger.

[kali]

error: "machdep.cpu.extfeatures" is an unknown key

[kali]

I guess it isn't called EM64T, also, if you aren't unfortunate enough to have intel.

[Avihu Turzion]

Upvote for Arstechnica for their explanation.

[RomanSt]

There may be fewer drivers but it's not really quite as bad as this makes it sound. I've been running 64 bits since 2007 and never had any difficulties. Having said that, I don't have any obscure or ancient devices connected.

[Mr Fooz]

For an OS, 32-bit versus 64-bit ONLY refers to the size of pointers (what your first paragraph correctly discusses). -1: Some OSes choose to lock the default integer size to the pointer size, but neither Windows nor Linux do so. Integer math precision is unchanged. NO widely-used OS changes the floating point precision (what the second paragraph claims). "float" or "single" is 32-bits, "double" is 64-bits, regardless of whether the OS uses 32-bit or 64-bit pointers.

[UNK]

Ah, I was clearly mistaken, thanks for clearing that up :)

[Kevin K]

My most recent one with Vista 64 bit was a brand new HP multi function printer just last month on a 2 month old Dell system. Both Dell and HP gave up, and my customer paid me to put on XP Pro and get rid of Vista. Nothing obscure about either unit.

[ChrisInEdmonton]

May be worth editing your answer to state how much RAM can be accessed. A 32-bit operating system on an ix86 system with PAE can address up to 64 GB of RAM. A 64-bit operating system on x86-64 can access up to 256 TB of virtual address space, though this may be raised in subsequent processors, up to 16 EB. Note that some operating systems limit the address space further, and most motherboards will have additional restrictions.

[UNK]

I wanted to keep it simple, as the numbers are mostly high enough to be irrelevant at the moment, but it can't hurt to stick them in now.

[David Thornley]

Thing is, a 32-bit operating system can't address more than 4 GB at a time, and this usually works out to 2-3G per application. This means that it might be good for several applications at 1-1.5G each, but have problems with one larger one.

[UNK]

IIRC a 32bit architecture can only give an application 2GB, PAE and so increase this but it's working around a limitation of the architecture, so I tend to not mention it. The point is a good one, though, but I feel it falls under "use more RAM", as once you're getting past 3GB you're probably going to head 64bit before long.

[Breakthrough]

Very good answer. Especially because you noted that there is not actually a 4gb RAM limit, but process memory usage limit. Just for your information, I think you should take a look at this link: unawave.de/windows-7-tipps/32-bit-ram-barrier.html?lang=EN

[Mark Booth]

@flextendu, given the performance requirements of those old programs, you could almost certainly run them in a virtual machine. With VMware player, Virtual PC and Virtual Box out there, there is no reason not to try out one of them, if you have a spere 32bit Windows license. If you don't want to mess with that, they will probably work under "Windows XP Mode" too.

[JJ_Australia]

BTW, 32-bit applications will not use more than 2 GiB of RAM unless a specific flag is enabled in their manifest. Source: blogs.technet.com/b/markrussinovich/archive/2008/11/17/…

[Joey]

Hardware that wants to brandish the Works with Windows or Certified for use with Windows logos must offer 64-bit drivers. Maybe look for that next time. But indeed, sometimes vendors don't bother for consumer hardware as most consumers will likely still be on 32 bit.

[Django Reinhardt]

Yes, I'm sure Hello71 has hit on something pretty important that's not covered here: Most 32-bit apps will never directly take advantage of the extra RAM. I think this is worth mentioning, no?

[Dan Is Fiddling By Firelight]

@Breakthough you should warn people before linking to sites with NSFW advertising.

[Rich Homolka]

Good explanation. 32 bit Linux has the ability to have individual apps have their own (nearly) 4gm memory space. I don't think Windows allows this.

[Izzy]

RAM limit of 4GB is not quite true (it rather is an artificial limit put on home users Windows systems), check PAE. With most up-to-date hardware, a Linux PAE kernel (which is what is used by default for 32bit) can address more than 4GB just fine. Same applies to FreeBSD and NetBSD.

[Admin]

See my remark on PAE above: the 4GB limit is not true for the entire system -- but only applies to single processes (no process can access 4GB and up itself -- but the entire system, i.e. all processes together, can with PAE enabled). So unless one has applications which profit from being able to access 4GB and up (such as video editors/converters with big video files) and 8GB+ installed, it shouldn't make much difference whether using 32bit or 64bit.

[ctrl-alt-delor]

This answer suggests that PowerPC64 is not as good as x86-64. The truth is that powerpc64 did not improve powerpc, as powerpc was not broken.

[ganesh]

Almost, but not quite. A 32bit architecture can do more than 2GB per application. The windows 32 bit implementation however uses the high bit for its own internal stuff. That leaves 31 bits for the application ( 2³¹ is 2GiB ).

[Jet]

32bit systems can't use more than 4GB (1st punct) because of that "addresses" (3rd punct).Because the highest 32bit number is 4.294.967.296 (=4GB). So your 1st and 3rd puncts are the SAME. You can remove the 3rd punct. :)

[phuclv]

@ChrisInEdmonton the system does support more than 4GB or memory but the address for each process is still limit to 2GB (3GB with large address aware). So even if your system has lots of memory, it still doesn't help programs which are memory extensive, and the performance still lags behind 64-bit version. Also, it has much smaller address range for ASLR and memory mapped file

[Michael]

x64 and IA64 are not "The 2 big types of 64-bit architectures". Especially not IA64, not by a longshot. Sun Microsystem's UltraSparc and IBM's Power architectures have gone 64 bit well before any of Intel or AMD ones, and they are still prominent as server CPU families (on Oracle and IBM machines respectively). As for IA64, it was stillborn because nobody is able to produce decent EPIC compilers, although HP tried to use Itanium for a while with a very limited success.

[Peter Cordes]

More registers, and a redesigned ABI (passing function args in register) is usually a 10 to 15% speedup, which is pretty decent. There's now an x32 Linux ABI with 32bit pointers, but using amd64 long mode, and args-in-registers calling conventions. So you have all the speed benefits of amd64, but without the overhead of needing 64bits for every pointer. It's good for everything that doesn't need > 4GB of (virtual) memory.

[Peter Cordes]

Linux now has an x32 ABI, with all the speed benefits of x86-64 (more registers, redesigned ABI), but with 32bit pointers. +1 for pointing out that the benefits of 64bit mode aren't from the actual width increase, but from the chance to drop a lot of the baggage that was holding the architecture back. 64bit regs have value for some applications, but 64bit pointer space is less often needed.

[jiggunjer]

It might also be worthwhile mentioning what the bit-value refers to. I've heard arguments saying it is the GP register size, the addressing bus, or the data bus size.

[Mr Fooz]

@jiggunjer good idea. Added a new section.

[Banderi]

Just a pedantic remark so that people don't blindly use the formula without checking: 1/0.x does not equate to 1+(100-x)% -- e.g. 4/0.75 is not 5 (aka 4+25%) but 5.333; 60/0.95 is ~63.1579, whereas 60+5% is exactly 63.

[Mr Fooz]

@Banderi good point. I don't recall whether the real numbers were 60 vs 65 or 60 vs 63, so I've updated the post to assume the worst (65) while having the math follow more standard naming conventions.

[Jeach]

When some say that 64-bit systems can process data more quickly, I don't get that. From what I understand, if you are in a 32-bit system, the processor will still load memory pages (into cache) with the full width of its data bus. Considering that memory I/O is what can slow down an application, wouldn't 32-bit systems be a little faster? Especially apps which are I/O intensive and not compute intensive (extra registers don't help much).

[Mr Fooz]

@Jeach Yes there are some cases where 32-bit processes can be faster on Intel than 64-bit processes. If your application doesn't exploit the extra registers, is doing a lot of pointer chasing that uses most of the cache, and/or is streaming through tons of machine code, then a 32-bit process can be faster. For a wide class of applications though, the extra registers overcome the downside of doubling the size of pointers. As is common advice, benchmark your application if you think it'd be better as 32-bit.