Editing 64-bit computing (section)

=== Pros and cons ===
A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4&nbsp;GB of [[random-access memory]].<ref>{{cite web|title=A description of the differences between 32-bit versions of Windows Vista and 64-bit versions of Windows Vista|url=https://support.microsoft.com/kb/946765|access-date=2011-10-14|archive-url=https://web.archive.org/web/20111015085813/https://support.microsoft.com/kb/946765|archive-date=2011-10-15|url-status=dead}}</ref> This is not entirely true:

* Some operating systems and certain hardware configurations limit the physical memory space to 3&nbsp;GB on [[IA-32]] systems, due to much of the 3–4&nbsp;GB region being reserved for hardware addressing; see [[3 GB barrier]]; 64-bit architectures can address far more than 4&nbsp;GB. However, IA-32 processors from the [[Pentium Pro]] onward allow a 36-bit ''physical'' memory address space, using [[Physical Address Extension]] (PAE), which gives a 64&nbsp;GB physical address range, of which up to 62&nbsp;GB may be used by main memory; operating systems that support PAE may not be limited to 4&nbsp;GB of physical memory, even on IA-32 processors. However, drivers and other kernel mode software, more so older versions, may be incompatible with PAE; this has been cited as the reason for 32-bit versions of [[Microsoft Windows]] being limited to 4&nbsp;GB of physical RAM<ref name="markr200807">{{cite web|url=https://blogs.technet.microsoft.com/markrussinovich/2008/07/21/pushing-the-limits-of-windows-physical-memory/|title=Pushing the Limits of Windows: Physical Memory|date=2008-07-21|access-date=2017-03-09|author=Mark Russinovich|archive-url=https://web.archive.org/web/20170407050448/https://blogs.technet.microsoft.com/markrussinovich/2008/07/21/pushing-the-limits-of-windows-physical-memory/|archive-date=2017-04-07|url-status=dead}}</ref> (although the validity of this explanation has been disputed<ref name="geoffchappell.com">{{cite web|first=Geoff|last=Chappell|url=http://www.geoffchappell.com/notes/windows/license/memory.htm|title=Licensed Memory in 32-Bit Windows Vista|work=geoffchappell.com|publisher=[[WP:SPS]]|date=2009-01-27|access-date=9 March 2017}}</ref>).
* Some operating systems reserve portions of [[process (computing)|process]] [[address space]] for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, 32-bit Windows reserves 1 or 2&nbsp;GB (depending on the settings) of the total address space for the kernel, which leaves only 3 or 2&nbsp;GB (respectively) of the address space available for user mode. This limit is much higher on 64-bit operating systems.
* [[Memory-mapped file]]s are becoming more difficult to implement in 32-bit architectures as files of over 4&nbsp;GB become more common; such large files cannot be memory-mapped easily to 32-bit architectures, as only part of the file can be mapped into the address space at a time, and to access such a file by memory mapping, the parts mapped must be swapped into and out of the address space as needed. This is a problem, as memory mapping, if properly implemented by the OS, is one of the most efficient disk-to-memory methods.
* Some 64-bit programs, such as encoders, decoders and encryption software, can benefit greatly from 64-bit registers,{{Citation needed|date=February 2015}} while the performance of other programs, such as 3D graphics-oriented ones, remains unaffected when switching from a 32-bit to a 64-bit environment.{{Citation needed|date=February 2015}}
* Some 64-bit architectures, such as [[x86-64]] and [[AArch64]], support more general-purpose registers than their 32-bit counterparts (although this is not due specifically to the word length). This leads to a significant speed increase for tight loops since the processor does not have to fetch data from the cache or main memory if the data can fit in the available registers.
:Example in [[C (programming language)|C]]:
<syntaxhighlight lang="c">
int a, b, c, d, e;
for (a = 0; a < 100; a++) {
    b = a;
    c = b;
    d = c;
    e = d;
}
</syntaxhighlight>
: This code first creates 5 values: a, b, c, d and e; and then puts them in a loop. During the loop, this code changes the value of b to the value of a, the value of c to the value of b, the value of d to the value of c and the value of e to the value of d. This has the same effect as changing all the values to a.
:If a processor can keep only two or three values or variables in registers, it would need to move some values between memory and registers to be able to process variables d and e also; this is a process that takes many CPU cycles. A processor that can hold all values and variables in registers can loop through them with no need to move data between registers and memory for each iteration. This behavior can easily be compared with virtual memory, although any effects are contingent on the compiler.

The main disadvantage of 64-bit architectures is that, relative to 32-bit architectures, the same data occupies more space in memory (due to longer pointers and possibly other types, and alignment padding). This increases the memory requirements of a given process and can have implications for efficient processor cache use. Maintaining a partial 32-bit model is one way to handle this, and is in general reasonably effective. For example, the [[z/OS]] operating system takes this approach, requiring program code to reside in 31-bit address spaces (the high order bit is not used in address calculation on the underlying hardware platform) while data objects can optionally reside in 64-bit regions. Not all such applications require a large address space or manipulate 64-bit data items, so these applications do not benefit from these features.