Myths about 64-bit computing on Windows

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.

POP QUIZ: What's the largest integer that SAS can store in 8 bytes with exact representation?

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.

tags: 64-bit, SAS for Windows

8 Comments

  1. Anne
    Posted January 10, 2013 at 6:12 pm | Permalink

    Are you required to load SAS 64 bit on a Windows 64 bit machine (windows 8, in this case)? Or can you use SAS 32 bit?

    • Chris Hemedinger Chris Hemedinger
      Posted January 10, 2013 at 6:17 pm | Permalink

      64-bit SAS requires 64-bit Windows. But 32-bit SAS can run on 32-bit Windows OR 64-bit Windows. If you have SAS programs that rely on import/export from Excel, or you have established FORMAT libraries that you share, the 32-bit version might offer you better compatibility. See more information in this post.

      Note that SAS currently supports Windows 8 for only a few products.

      • Anne
        Posted January 10, 2013 at 6:51 pm | Permalink

        I have noted that SAS does not support Windows 8. Do you know if they have any plans to do so in the near future?

        By not support, does that mean not to expect SAS to work on Windows 8, or that SAS won't help you if there are problems?

        • Chris Hemedinger Chris Hemedinger
          Posted January 11, 2013 at 10:09 am | Permalink

          Yes, there are plans to support Windows 8. Currently a sticking point is in some of the 3rd party components that SAS 9.3 relies on, including Java 6, which are not yet "certified" for Windows 8.

  2. Rodrigo
    Posted August 29, 2013 at 10:31 am | Permalink

    My home desktop is 64 bits but my laptop is 32 bits. Is there a huge difference between the SAS 32 bits version and the 64 one? I know that I cannot run the SAS 64 bits version into my laptop (32 bits), but if you consider the SAS 64 bits version is actually much better than the 32 bits one, I would just use the program on my desktop. If there is no a big difference, I will get the SAS 32 version that allows me to use it in both computers. What do you recommend? Thanks!

    • Chris Hemedinger Chris Hemedinger
      Posted August 29, 2013 at 10:40 am | Permalink

      I think if you don't have huge data or programs that require lots of memory, then the 32-bit version is fine.

      However, note that currently SAS 9.4 (the most recent version of SAS) has only a 64-bit version, and not a 32-bit version. A 32-bit release is under consideration right now, but in the meantime you can use the x86 (32-bit) version of SAS 9.3 for Windows on a 32-bit or 64-bit OS.

  3. Paul Taube
    Posted October 7, 2014 at 12:07 pm | Permalink

    My experience with several versions of 64 bit SAS, including the latest 9.4, is that 32 bit SAS on 64 Windows runs much faster than 64 bit SAS for large data, I/O and CPU bound processes running many child processes. 64 bit SAS has some real performance issues under those circumstances, regardless of the optimizations used.

    • Chris Hemedinger Chris Hemedinger
      Posted October 7, 2014 at 4:21 pm | Permalink

      Paul,

      Have you looked at the series of articles by Margaret Crevar on the SAS Users blog? There are plenty of resources in there about tuning performance on different systems.

      As always, performance results depends on the work activities as well as the architecture. Sounds like you've done a study of the type of workload that seems to be slower; I'd suggest working with SAS Tech Support and provide as many specifics as you can to get the best guidance.

One Trackback

  1. [...] Myths about 64-bit computing on Windows Are 64-bit client applications twice as good as 32-bit applications? How do I export from SAS to Excel files: Let me count the ways Should you care about 64-bit applications? tags: 64-bit, excel Bookmark on Delicious Digg this post Recommend on Facebook Share on FriendFeed Share on Linkedin share via Reddit Share with Stumblers Tweet about it Share on xing Print for later Tell a friend « The makeup of SAS Global Forum [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <p> <pre lang="" line="" escaped=""> <q cite=""> <strike> <strong>