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?

Answer 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.

Answer 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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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)

Windows 64-bit defaults to using SSE2 for floating point which seems to speed up simple operations and slows down complex (sin,cos etc) operations.

(*) 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.

Answer 9

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.

Answer 10

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.

Answer 11

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.)

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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

Answer 18

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.

Answer 19

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.