Jump to content

64-bit computing: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Minor grammatical changes. Reword pros and cons section. (This turkey still needs a lot of work.)
Line 1: Line 1:
In [[computing]], a '''64-bit''' component is one in which data are stored in chunks ([[computer word]]s) of sixty-four [[bit]]s (binary digits) each. The term often describes a computer's [[CPU]]: e.g. "The [[Sun UltraSPARC]] is a 64-bit processor". Its external [[data bus]] or [[address bus]] may be narrower (i.e. pass data in chunks of fewer bits), and the term is often used to describe the size of these buses as well. For instance, many current machines with [[32-bit]] processors use 64-bit buses. The term may also refer to the size of an instruction in the computer's [[instruction set]] or to any other item of data. Without further qualification, however, a computer architecture described as "64-bit" generally has [[register]]s that are 64 bits wide and thus directly supports dealing both internally and externally with 64-bit "chunks" of data.
In [[computing]], a '''64-bit''' component is one in which data are stored in chunks ([[computer word]]s) of sixty-four [[bit]]s (binary digits) each. The term often describes a computer's [[CPU]]: e.g. "The [[Sun UltraSPARC]] is a 64-bit processor". Its external [[data bus]] or [[address bus]] may be narrower (i.e. pass data in chunks of fewer bits), and the term is often used to describe the size of these buses as well. For instance, many current machines with [[32-bit]] processors use 64-bit buses. The term may also refer to the size of an instruction in the computer's [[instruction set]] or to any other item of data. Without further qualification, however, a computer architecture described as "64-bit" generally has [[register]]s that are 64 bits wide and thus directly supports dealing both internally and externally with 64-bit "chunks" of data.


Most CPUs are designed so that the contents of a single register can store the address (location) of any datum in the computer's [[virtual memory]]. Therefore, the total number of addresses in the virtual memory &mdash; the total amount of data the computer can keep in its working area &mdash; is determined by the width of these registers. Beginning in the [[1960s]] with the [[IBM]] [[System 360]], then (amongst many others) the [[Digital Equipment Corporation|DEC]] [[VAX]] minicomputer in the [[1970s]], and then with the [[Intel 80386]] in the mid-[[1980s]], a ''de facto'' consensus developed that 32 bits was a convenient register size. A 32-bit register meant that 2<sup>32</sup> addresses, or 4 gigabytes of memory, could be referenced. At the time all of these architectures were settled on, 4 gigabytes of [[RAM]] was so far beyond the typical quantities available in installations that this was considered to be enough "headroom" for addressing. 4-gigabyte addresses were considered an appropriate size to work with for another important reason: 4 billion integers are enough to assign unique references to most physically countable things in applications like [[database]]s.
Most CPUs are designed so that the contents of a single register can store the address (location) of any datum in the computer's [[virtual memory]]. Therefore, the total number of addresses in the virtual memory &mdash; the total amount of data the computer can keep in its working area &mdash; is determined by the width of these registers. Beginning in the [[1960s]] with the [[IBM]] [[System 360]], then (amongst many others) the [[Digital Equipment Corporation|DEC]] [[VAX]] minicomputer in the [[1970s]], and then with the [[Intel 80386]] in the mid-[[1980s]], a ''de facto'' consensus developed that 32 bits was a convenient register size. A 32-bit register meant that 2<sup>32</sup> addresses, or 4 gigabytes of [[RAM]] memory, could be referenced. At the time these architectures were devised, 4 gigabytes of memory was so far beyond the typical quantities available in installations that this was considered to be enough "headroom" for addressing. 4-gigabyte addresses were considered an appropriate size to work with for another important reason: 4 billion integers are enough to assign unique references to most physically countable things in applications like [[database]]s.


However, with the march of time and the continual reductions in the cost of memory (see [[Moore's Law]]), by the early [[1990s]] installations with quantities of RAM approaching 4 gigabytes began to appear, and the use of virtual memory spaces greater than the four gigabyte limit became desirable for handling certain types of problems. In response, a number of companies began releasing new families of chips with 64-bit architectures, initially for [[supercomputer]]s and high-end [[server]] machines. 64-bit computing has gradually drifted down to the personal computer desktop, with [[Apple Computer|Apple Computer]]'s [[PowerMac]] desktop line as of 2003 and its [[iMac]] home computer line as of 2004 both using 64-bit processors (Apple calls it the [[G5]] chip), and [[AMD]]'s x86-64 architecture becoming common in high-end Windows [[IBM PC|PC]]s and Intel adopting the same architecture for their future desktop CPUs.
However, with the march of time and the continual reductions in the cost of memory (see [[Moore's Law]]), by the early [[1990s]] installations with quantities of RAM approaching 4 gigabytes began to appear, and the use of virtual memory spaces greater than the four gigabyte limit became desirable for handling certain types of problems. In response, a number of companies began releasing new families of chips with 64-bit architectures, initially for [[supercomputer]]s and high-end [[server]] machines. 64-bit computing has gradually drifted down to the personal computer desktop, with [[Apple Computer|Apple Computer]]'s [[PowerMac]] desktop line as of 2003 and its [[iMac]] home computer line ([[as of 2004]]) both using 64-bit processors (Apple calls it the [[G5]] chip), and [[AMD]]'s "[[AMD64]]" architecture (and Intel's "[[EM64T]]") becoming common in high-end [[IBM PC|PC]]s.


A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as [[operating system]]s must be modified to take advantage of the new architecture. Other software must also be [[porting|ported]] to use the new capabilities; older software is usually supported through either a ''hardware compatibility mode'' (in which the new processors support an older 32-bit instruction set as well as the new modes), or through software [[emulation]].
A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as [[operating system]]s must be modified to take advantage of the new architecture. Other software must also be [[porting|ported]] to use the new capabilities; older software is usually supported through either a ''hardware compatibility mode'' (in which the new processors support an older 32-bit instruction set as well as the new modes), or through software [[emulation]].
Line 9: Line 9:
While 64-bit architectures indisputably make working with huge data sets in applications such as [[digital video]], scientific computing, and large [[database]]s 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.
While 64-bit architectures indisputably make working with huge data sets in applications such as [[digital video]], scientific computing, and large [[database]]s 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.


Theoretically, some programs could well be faster in 32-bit mode. Instructions for 64-bit computing take up more storage space than the earlier 32-bit ones, so it is possible that some 32-bit programs will fit into the CPU's high-speed [[CPU cache|cache]] while equivalent 64-bit programs will not. However, in applications like scientific computing, the data being processed often fits naturally in 64-bit chunks, and will be faster on a 64-bit architecture because the CPU will be designed to process such information directly rather than requiring the program to perform multiple steps. Such assessments are complicated by the fact that in the process of designing the new 64-bit architectures, the instruction set designers have taken the opportunity to make other changes that address some of the deficiencies in older instruction sets by adding new performance-enhancing facilities (such as the extra register in the x86-64 design).
Theoretically, some programs could well be faster in 32-bit mode. Instructions for 64-bit computing take up more storage space than the earlier 32-bit ones, so it is possible that some 32-bit programs will fit into the CPU's high-speed [[CPU cache|cache]] while equivalent 64-bit programs will not. However, in applications like scientific computing, the data being processed often fits naturally in 64-bit chunks, and will be faster on a 64-bit architecture because the CPU will be designed to process such information directly rather than requiring the program to perform multiple steps. Such assessments are complicated by the fact that in the process of designing the new 64-bit architectures, the instruction set designers have also taken the opportunity to make other changes that address some of the deficiencies in older instruction sets by adding new performance-enhancing facilities (such as the extra registers in the AMD64 design).


== pro/cons ==
==Pros and cons==
A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4GB of memory. This is not entirely true:


*Some operating systems reserve portions of each [[process]]' [[address space]] for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and userland OS components are mapped into each process' address space, leaving only 3GB address space available under Windows XP, even if the computer has 4GB of RAM. This restriction is not present in 64-bit Windows.
An often made mistake is that 64-bit architectures are considered useless till one adds more than 4 GB of memory to a computer. This is not entirely true:
*Many C programs use signed values for buffer sizes, which wrap around if they exceed 2GB in size. (However it is doubtful that such a program would run on 64-bit systems unmodified)

*Memory mapping of files is becoming more dangerous with 32-bit architectures, especially with the introduction of relatively cheap recordable DVD technology. A 4 GB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures. This is an issue, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.
* Some operating systems map parts of the kernel and/or userland OS parts into userland space, effectively reducing the total addressspace available for mapping memory for user programs. (e.g. Windows DLLs and userland OS components. Free usable memory under XP: 3 GB, 2000 (non server): 2GB)
* Many C programs use signed values for buffersizes, which wrap around if they exceed 2GB in size. (However it is doubtful that such a program would run on 64-bit systems unmodified)
* Memory mapping of files is becoming more dangerous with 32-bit architectures, especially with the introduction of relatively cheap recordable DVD technology. A 4 GB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures. This is an issue, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.


The main disadvantage of 64-bit architectures is that relative to 32-bit architectures the same data (due to swollen pointers and possibly other types) occupies slightly more space in memory. This increases the memory requirements of a given process, and can have implications for efficient processor cache utilisation.
The main disadvantage of 64-bit architectures is that relative to 32-bit architectures the same data (due to swollen pointers and possibly other types) occupies slightly more space in memory. This increases the memory requirements of a given process, and can have implications for efficient processor cache utilisation.
Line 23: Line 22:
Maintaining a partial 32-bit datamodel is one way to handle this, and is in general reasonably effective.
Maintaining a partial 32-bit datamodel is one way to handle this, and is in general reasonably effective.


== 64-bit data models ==
==64-bit data models==


Converting application software written in a [[high-level language]] from a 32-bit architecture to a 64-bit architecture varies in difficulty. One common recurring problem is that in the [[C programming language]] and its descendant [[C plus plus programming language|C++]] on 32-bit machines, pointers (variables that store memory addresses), and two built-in "data types" for storing numbers - "int" and "long" - all refer to a 32-bit wide data chunk. Some programs assume that because of this transfering quantities between these data types implies that no information will be lost. In many programming environments on 64-bit machines, however, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an '''LP64''' [[data model]]. Another alternative is the '''ILP64''' data model in which all three data types are 64 bits wide. However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the so-called '''LLP64''' model that maintains compability with 32 bit code, by leaving both int and long as 32-bit, and defining a new 64-bit ''long long'' type
Converting application software written in a [[high-level language]] from a 32-bit architecture to a 64-bit architecture varies in difficulty. One common recurring problem is that in the [[C programming language]] and its descendant [[C plus plus programming language|C++]] on 32-bit machines, pointers (variables that store memory addresses), and two built-in "data types" for storing numbers - "int" and "long" - all refer to a 32-bit wide data chunk. Some programs assume that because of this transfering quantities between these data types implies that no information will be lost. In many programming environments on 64-bit machines, however, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an '''LP64''' [[data model]]. Another alternative is the '''ILP64''' data model in which all three data types are 64 bits wide. However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the so-called '''LLP64''' model that maintains compability with 32 bit code, by leaving both int and long as 32-bit, and defining a new 64-bit ''long long'' type

Revision as of 16:58, 26 September 2004

In computing, a 64-bit component is one in which data are stored in chunks (computer words) of sixty-four bits (binary digits) each. The term often describes a computer's CPU: e.g. "The Sun UltraSPARC is a 64-bit processor". Its external data bus or address bus may be narrower (i.e. pass data in chunks of fewer bits), and the term is often used to describe the size of these buses as well. For instance, many current machines with 32-bit processors use 64-bit buses. The term may also refer to the size of an instruction in the computer's instruction set or to any other item of data. Without further qualification, however, a computer architecture described as "64-bit" generally has registers that are 64 bits wide and thus directly supports dealing both internally and externally with 64-bit "chunks" of data.

Most CPUs are designed so that the contents of a single register can store the address (location) of any datum in the computer's virtual memory. Therefore, the total number of addresses in the virtual memory — the total amount of data the computer can keep in its working area — is determined by the width of these registers. Beginning in the 1960s with the IBM System 360, then (amongst many others) the DEC VAX minicomputer in the 1970s, and then with the Intel 80386 in the mid-1980s, a de facto consensus developed that 32 bits was a convenient register size. A 32-bit register meant that 232 addresses, or 4 gigabytes of RAM memory, could be referenced. At the time these architectures were devised, 4 gigabytes of memory was so far beyond the typical quantities available in installations that this was considered to be enough "headroom" for addressing. 4-gigabyte addresses were considered an appropriate size to work with for another important reason: 4 billion integers are enough to assign unique references to most physically countable things in applications like databases.

However, with the march of time and the continual reductions in the cost of memory (see Moore's Law), by the early 1990s installations with quantities of RAM approaching 4 gigabytes began to appear, and the use of virtual memory spaces greater than the four gigabyte limit became desirable for handling certain types of problems. In response, a number of companies began releasing new families of chips with 64-bit architectures, initially for supercomputers and high-end server machines. 64-bit computing has gradually drifted down to the personal computer desktop, with Apple Computer's PowerMac desktop line as of 2003 and its iMac home computer line (as of 2004) both using 64-bit processors (Apple calls it the G5 chip), and AMD's "AMD64" architecture (and Intel's "EM64T") becoming common in high-end PCs.

A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as operating systems must be modified to take advantage of the new architecture. Other software must also be ported to use the new capabilities; older software is usually supported through either a hardware compatibility mode (in which the new processors support an older 32-bit instruction set as well as the new modes), or through software emulation.

While 64-bit architectures indisputably make working with huge 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.

Theoretically, some programs could well be faster in 32-bit mode. Instructions for 64-bit computing take up more storage space than the earlier 32-bit ones, so it is possible that some 32-bit programs will fit into the CPU's high-speed cache while equivalent 64-bit programs will not. However, in applications like scientific computing, the data being processed often fits naturally in 64-bit chunks, and will be faster on a 64-bit architecture because the CPU will be designed to process such information directly rather than requiring the program to perform multiple steps. Such assessments are complicated by the fact that in the process of designing the new 64-bit architectures, the instruction set designers have also taken the opportunity to make other changes that address some of the deficiencies in older instruction sets by adding new performance-enhancing facilities (such as the extra registers in the AMD64 design).

Pros and cons

A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4GB of memory. This is not entirely true:

  • Some operating systems reserve portions of each process' address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and userland OS components are mapped into each process' address space, leaving only 3GB address space available under Windows XP, even if the computer has 4GB of RAM. This restriction is not present in 64-bit Windows.
  • Many C programs use signed values for buffer sizes, which wrap around if they exceed 2GB in size. (However it is doubtful that such a program would run on 64-bit systems unmodified)
  • Memory mapping of files is becoming more dangerous with 32-bit architectures, especially with the introduction of relatively cheap recordable DVD technology. A 4 GB file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures. This is an issue, as memory mapping remains one of the most efficient disk-to-memory methods, when properly implemented by the OS.

The main disadvantage of 64-bit architectures is that relative to 32-bit architectures the same data (due to swollen pointers and possibly other types) occupies slightly more space in memory. This increases the memory requirements of a given process, and can have implications for efficient processor cache utilisation.

Maintaining a partial 32-bit datamodel is one way to handle this, and is in general reasonably effective.

64-bit data models

Converting application software written in a high-level language from a 32-bit architecture to a 64-bit architecture varies in difficulty. One common recurring problem is that in the C programming language and its descendant C++ on 32-bit machines, pointers (variables that store memory addresses), and two built-in "data types" for storing numbers - "int" and "long" - all refer to a 32-bit wide data chunk. Some programs assume that because of this transfering quantities between these data types implies that no information will be lost. In many programming environments on 64-bit machines, however, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an LP64 data model. Another alternative is the ILP64 data model in which all three data types are 64 bits wide. However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the so-called LLP64 model that maintains compability with 32 bit code, by leaving both int and long as 32-bit, and defining a new 64-bit long long type that is compatible with the pointer attribute.

Note that a programming model is a choice made on a per compiler basis, and several can coexist on the same OS. However typically the programming model chosen by the OS API as primary model dominates.

References

64-bit processor architectures include:

See also:

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.