Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
64-Bit Computing
As the complexity and functionality of applications increase, their data sets and address space requirements increase as well. Many applications (databases, web caches, simulation and modeling software, and the like) run more effectively if they are not subject to the 4-gigabyte address space limitation imposed by a 32-bit architecture.
The ability to support larger amounts of primary memory allows the 64-bit architecture to afford performance benefits to a broad class of applications, including the following:
A greater proportion of a database can be held in primary memory.
Larger CAD/CAE models and simulations can fit in primary memory.
Larger scientific computing problems can fit in primary memory.
Web caches hold more data in memory, reducing latency.
The following are also compelling reasons for creating 64-bit applications:
To improve performance by performing several computations on 64-bit integer quantities, using the wider data paths of a 64-bit processor
To improve efficiency with arithmetic and logical operations on 64-bit quantities
To enable operations to use full-register widths, the full-register set, and new instructions
To improve efficiency with the improved parameter passing of 64-bit quantities
Not all applications are well suited to a 64-bit data model. If your application does not use or require any of the features listed above, it should probably be left as a 32-bit application. 32-bit applications usually run without problem in a 64-bit environment. 64-bit applications are usually larger in size. Additionally, the use of longer pointers in the 64-bit version could degrade performance because of cache misses. Doubling the size of pointers means that the cache cannot hold as many entries as om the 32-bit version of the application.
Understanding Differences Between 32-Bit and 64-Bit Data Models
Like Tru64, the Solaris OS supports the LP64 data model. In this convention, longs and pointers are 64 bits in length (hence the acronym LP64) and an integer is 32 bits in length. This is in contrast to the data model used in 32-bit environments, referred to as an ILP32, in which integers, longs, and pointers are all 32 bits in length (hence the acronym ILP32). The following table highlights the differences between these two models:
TABLE 0-1 Differences Between 32-Bit and 64-Bit Data Models
|
C Data Type |
ILP32 |
LP64 |
|
char |
8 |
unchanged |
|
short |
16 |
unchanged |
|
int |
32 |
unchanged |
|
long |
32 |
64 |
|
long long |
64 |
unchanged |
|
pointer |
32 |
64 |
|
enum |
32 |
unchanged |
|
float |
32 |
unchanged |
|
double |
64 |
unchanged |
|
long double |
128 |
unchanged |
Most of the problems associated with migrating an application to 64 bits arise from the following differences:
Long values (long) are 64 bits in length, not 32.
Pointers are 64 bits in length, not 32.
Integers (int) are not the same size as longs and pointers in a 64-bit environment.
Many of these size issues can be mitigated if the developer uses derived types. These definitions and others can be found in /usr/include/sys/types.h and /usr/include/sys/inttypes.h in both the Solaris and Tru64 environments. A derived type can specify the size of the attribute (for example, int32_t) or its intended use (for example, blksize_t), a capability that increases program clarity. The derived types themselves are safe for both ILP32 and LP64 environments, making them 32-bit and 64-bit safe.
All releases of the Solaris OS after and including the Solaris 7 OE support both 32-bit and 64-bit data models. Under most circumstances, binaries that were created under the 32-bit environment can be run in the 64-bit environment.
Using Large Files to Overcome 32-Bit Limitations
DEC was one of the first computer manufacturers to understand the limitations of a 32-bit environment as it related to file size. In the past, under a 32-bit environment, files could not exceed 2 gigabytes in length. Files are typically accessed relative to a pointer that points to a location within the file. Programmers can move this pointer by specifying an offset, but this offset is a signed quantity because the pointer can be moved forward and backward within the file. Consequently, the maximum offset that could be specified was 31 bits, limiting the file size to less than 2 gigabytes (2**31 = 2 gigabytes).
Vendors created a "large file" option that allows the offset variable to be a long quantity. This enables the file to grow well beyond the 2 or 4 gigabyte limit, because the offset variable used to move the pointer is much larger (2**63). This technology can be found in many legacy applications but is not necessary in a 64-bit computing environment like Solaris or Tru64.