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?

  • 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. – ctrl-alt-delor Sep 13 '12 at 22:04

19 Answers 19


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.

  • 8
    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 – Breakthrough Jan 13 '10 at 12:25
  • 8
    They are applications that don't work on a 64 bit windows: 16 bit applications / those that use 32 bit or unsigned kernel-mode drivers. That's a lot for a software addict like me... – fluxtendu Feb 26 '10 at 19:21
  • 1
    @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. – Mark Booth May 4 '10 at 13:14
  • 6
    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/… – Hello71 Aug 25 '10 at 14:37
  • 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? – Django Reinhardt Feb 15 '11 at 13:14

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.

  • 1
    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. – tzot Sep 25 '08 at 14:06
  • 2
    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 – bk1e Sep 26 '08 at 4:02
  • Upvote for Arstechnica for their explanation. – Avihu Turzion Aug 5 '09 at 7:29
  • 2
    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. – Izzy Jul 2 '12 at 14:58
  • 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. :) – Jet Sep 26 '13 at 16:40

The biggest impact that people will notice at the moment is that a 32bit PC can only address a maximum of 4GB of memory. When you take off memory allocated for other uses by the operating system your PC will probably only show around 3.25GB of usable memory. Move over to 64bit and this limit disappears.

If your doing serious developement then this could be very important. Try running several virtual machines and you soon run out of memory. Servers are more likely to need the extra memory and so you will find that 64bit usage is far greater on servers than desktops. Moore's law ensures that we will have ever more memory on machines and so at some point desktops will also switch over to 64bit as the standard.

For a much more detailed description of the processor differences check out this excellent article from ArsTechnica.

  • 7
    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 – Tall Jeff Sep 25 '08 at 12:38
  • 1
    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. – Phil Wright Sep 25 '08 at 12:41
  • 2
    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. – Tall Jeff Sep 25 '08 at 12:47
  • 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. – Jason Z Sep 25 '08 at 13:40
  • 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. – Izzy Jul 2 '12 at 15:04

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.

  • 2
    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. – ctrl-alt-delor Sep 13 '12 at 21:53
  • 3
    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. – Peter Cordes Jul 15 '15 at 16:26

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.

  • 4
    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. – Mr Fooz Oct 17 '09 at 17:40
  • Ah, I was clearly mistaken, thanks for clearing that up :) – Phoshi Oct 17 '09 at 18:03
  • No problem. -1 --> +1 – Mr Fooz Oct 17 '09 at 18:26
  • 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. – ChrisInEdmonton Oct 30 '09 at 12:49
  • 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. – Phoshi Oct 30 '09 at 13:21

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.

  • 4
    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 Nov 25 '08 at 21:16
  • @David: You're absolutely right. Unfortunately, there's a ton of code out there that does exactly that. – j_random_hacker May 25 '09 at 10:38

A 32 Bit process has a virtual addresses space of 4 GB; this might be too little for some apps. A 64 Bit app has a virtually unlimited address space (of course it is limited, but you will most likely not hit this limit).

On OSX there are other advantages. See the following article, why having the kernel run in 64 Bit address space (regardless if your app runs 64 or 32) or having your app run in 64 Bit address space (while the kernel is still 32 Bit) leads to much better performance. To summarize: If either one is 64 Bit (kernel or app, or both of course), the TLB ("translation lookaside buffer") doesn't have to be flushed whenever you switch from kernel to use space and back (which will speed up RAM access).

Also you have performance gains when working with "long long int" variables (64 Bit variables like uint64_t). A 32 Bit CPU can add/divide/subtract/multiply two 64 Bit values, but not in a single hardware operation. Instead it needs to split this operation into two (or more) 32 Bit operations. So an app that works a lot with 64 Bit numbers will have a speed gain of being able to do 64 Bit math directly in hardware.

Last but not least the x86-64 architecture offers more registers than the classic x86 architectures. Working with registers is much faster than working with RAM and the more registers the CPU has, the less often it needs to swap register values to RAM and back to registers.

To find out if your CPU can run in 64 Bit mode, you can look at various sysctl variables. E.g. open a terminal and type

sysctl machdep.cpu.extfeatures

If it lists EM64T, your CPU supports 64 Bit address space according to x86-64 standard. You can also look for

sysctl hw.optional.x86_64

If it says 1 (true/enabled), your CPU supports the x86-64 Bit mode, if it says 0 (false/disabled), it does not. If the setting is not found at all, consider it being false.

Note: You can also fetch sysctl variables from within a native C app, no need to use the command line tool. See

man 3 sysctl
  • error: "machdep.cpu.extfeatures" is an unknown key – alamar May 29 '09 at 12:55
  • I guess it isn't called EM64T, also, if you aren't unfortunate enough to have intel. – alamar May 29 '09 at 12:56

Note that addressspace can be used for more than (real) memory. One can also memory map large files, which can improve performance in more odd access patterns because the more powerful and efficient block-level VM level caching kicks in. It is also safer to allocate large memory blocks on 64-bit since the heapmanager is less likely to encounter address-space fragmentation that won't allow it to allocate a big block.

Some of the things said in this thread (like the doubling of # registers) only apply to x86-> x86_64, not to 64-bit in general. Just like the fact that under x86_64 one guaranteed has SSE2, 686 opcodes and a cheap way to do PIC. These features are strictly not about 64-bit, but about cutting legacy and remedying known x86 limitations

Moreover quite often people point to doubling of registers as the cause of the speedup, while it is more likely the default SSE2 use that does the trick (accelerating memcpy and similar functions). If you enable the same set for x86 the difference is way smaller. (*) (***)

Also keep in mind that there is often an initial penalty involved because the average data structure will increase simply because the size of a pointer is larger. This has also cache effects, but is more significantly noticable in the fact that the average memcpy() (or whatever the equivalent for memory copy is in your language) will take longer. This is only in the magnitude of a few percent btw, but the speedups named above are also in that magnitude.

Usually alignment overhead is also bigger on 64-bit architectures(records previously 32-bit only often become a mix of 32-bit and 64-bit values), blowing up structures even more.

Overall, my simple tests indicate they will roughly cancel each other out, if drivers and runtime libraries have fully adapted, giving no significant speed difference for the average app. However some apps can suddenly get faster (e.g. when depending on AES) or slower (crucial datastructure is constantly moved around/scanned/walked and contains a lot of pointers). The tests were on Windows though, and so the PIC optimalisation was not benchmarked.

Note that most JIT-VM languages (Java, .NET) use a significantly more pointers on average (internally) than e.g. C++. Probably their memory use increases more than for the average program, but I don't dare to equate that directly to slowing effects (since these are really complex and funky beast and often hard to predict without measuring)

(*) a little known fact is that the number of SSE registers also doubles in 64-bit mode

(**) Dr Dobbs had a nice article about it a few years ago.


Besides the obvious memoryspace issues that most people are mentioning here, I think it is worth looking at the notion of "broadword computing" that Knuth (among others) has been speaking about lately. There are a lot of efficiencies to be gained through bit manipulation, and bitwise operations on a 64-bit word go a lot further than on a 32-bit word. In short, you can do more operations in registers without having to hit memory, and from a performance perspective, that's a pretty huge win.

Take a look at Volume 4, pre-Fascicle 1A for some examples of the cool tricks I am talking about.


Aside from the ability to address more memory x86_64 also have more registers allowing the compiler to generate more efficient code. The performance improvement will usually be fairly small though.

The x86_64 architecture is backwards compatible with x86. It's possible to run unmodified 32-bit operating systems. It's also possible to run unmodified 32-bit software from a 64-bit OS. That will require all the usual 32-bit libraries though. They may need to be installed separately.

  • 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 Jul 15 '15 at 16:22

This thread is too long already, but ...

Most of the replies focus on the fact that you have a larger, 64-bit address space, so you can address more memory. For about 99% of all applications, this is totally irrelevant. Large whoop.

The real reason 64-bit is good is not that the registers are bigger, but there are twice as many of them! That means that the compiler can keep more of your values in register instead of spilling them to memory and loading them back in a few instructions later. If and when an optimizing compiler is unrolling your loops for you, it can unroll them roughly twice as much, which can really help performance.

Also, the subroutine caller/callee conventions for 64-bit have been defined to keep most of the passed parameters in registers instead of the caller pushing them onto the stack and the callee poping them off.

So a "typical" C/C++ application will get about a 10% or 15% performance improvement just by recompiling for 64-bit. (Assuming some portion of the app was compute bound. Of course, this is not guarenteed; All computers wait a the same speed. Your Mileage May Vary.)

  • 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. – David Thornley May 1 '09 at 21:45
  • 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%. – Die in Sente May 1 '09 at 22:38
  • 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). – j_random_hacker May 26 '09 at 16:41
  • @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" – Die in Sente May 27 '09 at 20:54
  • My experience is that this is way less, and is offset by the fact that the avg memblock to be moved is larger. – Marco van de Voort May 29 '09 at 12:40

With a 32-bit machine you only have 4,294,967,295 bytes of memory to address. With a 64-bit machine you have 1.84467441 × 10^19 bytes of memory.

Wikipedia says this

64-bit processors calculate particular tasks (such as factorials of large figures) twice as fast as working in 32-bit environments (given example is derived from comparison between 32-bit and 64-bit Windows Calculator; noticeable for factorial of say 100 000). This gives a general feeling of theoretical possibilities of 64-bit optimized applications.

While 64-bit architectures indisputably make working with large data sets in applications such as digital video, scientific computing, and large databases easier, there has been considerable debate as to whether they or their 32-bit compatibility modes will be faster than comparably-priced 32-bit systems for other tasks. In x86-64 architecture (AMD64), the majority of the 32-bit operating systems and applications are able to run smoothly on the 64-bit hardware.

Sun's 64-bit Java virtual machines are slower to start up than their 32-bit virtual machines because Sun has only implemented the "server" JIT compiler (C2) for 64-bit platforms.[9] The "client" JIT compiler (C1), which produces less efficient code but compiles much faster, is unavailable on 64-bit platforms.

It should be noted that speed is not the only factor to consider in a comparison of 32-bit and 64-bit processors. Applications such as multi-tasking, stress testing, and clustering (for high-performance computing), HPC, may be more suited to a 64-bit architecture given the correct deployment. 64-bit clusters have been widely deployed in large organizations such as IBM, HP and Microsoft, for this reason.

  • 2
    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. – Nick Johnson Sep 25 '08 at 12:25
  • 1
    Agreed. In theory, the address space is 2^64. In practice, CPU manufacturers are using smaller values...like 2^40 or 2^48. – Stu Thompson Sep 25 '08 at 12:34

Apart from the already mentioned advantages here are some more regarding security:

  • x86_64 cpus do have the no-execute bit in their page tables. I.e. this can prevent secruity exploits cause by buffer overruns. 32-bit x86 cpus do only support this feature in the PAE mode.
  • Bigger address space allows for better address space layout randomization (ASLR) which makes exploitation of buffer overruns harder.
  • x86_64 cpus feature position-independent code i.e. data access relative to the instruction pointer register (RIP).

Another advantage that comes to mind is that the amount of virtual contiguous memory allocated with vmalloc() in the Linux kernel can be larger in 64 bit mode.


Quotation from Microsoft.com:

In the following table, the increased maximum resources of computers that are based on 64-bit versions of Windows and the 64-bit Intel processor are compared with existing 32-bit resource maximums.


  • 2
    Interesting, but worth noting that some 32-bit versions of Windows allow for more PHYSICAL memory. See for example, en.wikipedia.org/wiki/… – ChrisInEdmonton Oct 30 '09 at 12:51
  • @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 – phuclv Jun 5 '14 at 8:34

Kristof and Poshi have stated the main technical differences between 32 and 64 bit OS' the user experience is usually much different than theory. The 64 bit consumer versions of Windows to date (XP and Vista) have large gaping holes in their driver support. I have had many printers, scanners, and other external devices flat out not work with the 64 bit versions that work fine with 32 bit versions. These are devices that had 64 bit drivers and they still would not work. At this point I would recommend you stay away from anything consumer based that is 64 bit from Microsoft until you hear about how Windows 7 handles this, from real end-users, not just the uber-geeks who currently have access to it. Give it 6 months at least and see what people are experiencing. Personally I will be installing the 32 bit flavor of Windows 7 as my 64 bit versions of Vista is an expensive paper weight that I stopped using eons ago and went back to XP 32 bit.

  • 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. – RomanSt Oct 17 '09 at 16:04
  • 1
    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. – Kevin K Oct 20 '09 at 20:28
  • 1
    Typically if you buy a computer with a 64-bit OS, everything will work. I'd be careful before trying to update an older computer, or if I had an older printer, or if I liked to upgrade on my own. – David Thornley Oct 30 '09 at 14:02
  • 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. – Joey Dec 23 '10 at 17:07

Some game-playing programs use a bit-board representation. Chess, checkers and othello for example have an 8x8 board, ie 64 squares, so having at least 64 bits in a machine word significantly helps performance.

I remember reading about a chess program whose 64-bit build was almost twice as fast as the 32-bit version.


The term 32-bit and 64-bit refers to the way a computer processor (also called a CPU), handles information. 64-bit versions of Windows handles large amounts of random access memory (RAM) more effectively than 32-bit systems.

speed may be different in my opinion


Another point to this in regards to Microsoft Windows is that for many years there has been the Win32 API which is intended for 32-bit operating systems and isn't optimized for 64 bit compiling. When I write some DLLs for my applications, I generally compile in Win32 which isn't the 64 bit version of things. Prior to Vista, there haven't been many successful 64 bit versions of Windows I believe as where I work my new machine has 4 GB of RAM but I'm still using 32-bit Windows XP Pro as it is a known stable O/S relative to XP64 or Vista.

I think you may want to also look back on when there was the shift from 16-bit to 32-bit for some more details on why the shift may be a big deal for some folks. The mission-critical applications that a company may run on a desktop, e.g. small accounting packages, may not run on a 64-bit operating system and thus there is the need to keep a legacy machine around, virtual or real.

Changing the size of an address can have some big ramifications and repercussions.


For most practical purposes you probably won't notice a difference.

You must have a 64-bit CPU (most CPUs in the last few years) to install a 64-bit operating system.

There are a few advantages to a 64-bit operating system:

  • It will allow you to run more than 4GB of RAM (the maximum number you can address in a 32-bit OS is 2^32 = 4GB)
  • It is helpful for working with large data sets (e.g. in Excel) and certain computationally intensive tasks (e.g. Photoshop and big files)
  • You can only run a 64-bit program on a 64-bit OS, but you can run a 32-bit program on both (keep in mind a lot of programs come as both, so there aren't too many 64-bit only programs).

Under most scenarios, 64-bit programs use a bit more memory, but for a personal computer, this is typically not noticed.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.