When I first joined SAS in 1993, we were gliding into the golden age of 32-bit computing on the PC. Microsoft offered a new extension to Microsoft Windows 3.1 called Win32s, and it allowed 32-bit applications to run on the Windows operating system. SAS Version 6.10 for Windows was one of the early applications to take advantage of this new "platform".
Now 64-bit PCs are the norm, and virtually all new Windows installations use a 64-bit operating system. The 64-bit version of Windows 7 (for example) offers a number of benefits, primarily due to its ability to manage/address a larger amount of system memory. If you have more memory on the system (typical workstation PCs now have 8GB or even 16GB), you can run more processes at the same time. They will run faster because there is less of need to swap information out of memory and onto disk; disk-based I/O is now less of a performance bottleneck.
But for all of the real benefits, some myths about 64-bit computing still persist. I'll attempt to dispel a few of those here.
MYTH: All operations are twice as fast
REALITY: 64-bit architecture does not make your computations faster.
Some people will say that, in theory, it could make computations slower in some cases because the native pointer representation is larger.
WEAK ANALOGY ALERT:
A pointer is an address in memory; think of it like a phone number. In my locale, we recently added a new 3-digit area code to allow for more telephone numbers to be issued. As a result, all residents here must use 10-digit dialing instead of the 7-digit dialing that we're accustomed to. Our phone system has more capacity, but it takes me longer to initiate a phone call.
But in practice you will see things run faster, most likely, because newer 64-bit machines have faster processors with multiple cores, more memory to reduce I/O, and more registers in the CPU to complete operations more efficiently. These are usually paired with faster storage technology and other infrastructure improvements, so you should see faster throughput.
MYTH: My results will be twice as accurate.
REALITY: It's true that you can store larger numbers with more precision in 64 bits than you can in 32 bits.
But even before 64-bit architecture, most programming languages offered intrinsic data types with a 64-bit storage length. This is true in SAS, where the LENGTH of a numeric variable determines its capacity. The default length for a SAS numeric variable is 8 bytes, regardless of platform and bitness. 8 bytes * (8 bits/byte) = 64 bits.
The precision adheres to IEEE standards for such things. If you want all of the excruciating details, check out this blog post about numeric precision in SAS.
MYTH: I'll be able to process twice as much data.
REALITY: Okay, there is some truth to this one. A 64-bit process can address more memory, so memory-intensive operations can benefit from this.
However, not all SAS operations are constrained by system memory. If you run lots of DATA step or SQL, your process might be more dependent on I/O performance. As I said in the lead-in for this post, your shiny new 64-bit system might have better I/O (perhaps even a solid-state drive), but that's not directly related to the 64-bit aspect.
In SAS, some memory-constrained operations such as hash tables and PROC REG will enjoy the additional elbow room. Other I/O-bound operations won't benefit directly, but there are things that you can do to tune your system for better SAS performance.
JMP is a SAS-provided application that can exploit a 64-bit system with lots of memory. SAS Enterprise Guide 5.1 has a 64-bit version that provides some benefit, but with trade offs.
If you move from 32-bit SAS to 64-bit SAS on Windows, you might face a few "gotchas" -- many related to compatibility issues with the legacy of 32-bit system. I'll address some of those issues in a future post, but here's a preview: Excel import/export, SAS catalog formats, location of 32-bit versus 64-bit system utilities, and a separation of content in the Windows registry.