Are 64-bit client applications twice as good as 32-bit applications?

In September 2010, I questioned whether you should care about native 64-bit client applications (or the lack thereof). At the time, SAS did not have a 64-bit version of SAS Enterprise Guide or SAS Add-In for Microsoft Office. A skeptical reader might assume that I was just trying to make excuses for a gap in our offering.

With the 5.1 releases, SAS Enterprise Guide and the SAS Add-In for Microsoft Office now offer native 64-bit versions (in addition to the traditional 32-bit versions). Recently a customer wrote to me and asked: now that we have these versions to offer, have I revised my thinking on this topic?

My answer: No, I have not. Except in a few unusual circumstances, the 64-bit versions do not offer much advantage. Moreover, these versions can be the cause of some compatibility headaches.

I know that "64-bit version" is a checkbox item for end users and IT departments as they deploy applications on new machines with 64-bit versions of Windows. In some cases it's automatic: if there is a 64-bit version, they'll deploy it. But I would argue that the decision requires more forethought. For affirmation of this opinion, I look to Microsoft's own guidance about the 64-bit version of Microsoft Office 2010. (It's not yet the recommended option for most people.)

Considerations for SAS Enterprise Guide

Remember, the 32-bit version of SAS Enterprise Guide works great on 64-bit Windows. You can use it to access a 64-bit version of SAS, and it's the SAS process that does the heavy lifting. Using the 32-bit version of SAS Enterprise Guide does not limit your ability to access large data or to use SAS for any memory-intensive processing.

The only benefit that a 64-bit version of SAS Enterprise Guide might offer is the ability to run really big projects and process flows. That's because project files and ODS results are loaded into the SAS Enterprise Guide process space. (That's SEGUIDE.EXE if you're keeping track in Windows Task Manager.) But those projects would have to be really big, with big results, to consume an amount of memory beyond what you can address with 32-bits. Big projects tend to be more difficult to maintain, so you might consider reorganizing them to make your life easier.

On the other hand, because the 64-bit version of SAS Enterprise Guide cannot interoperate with 32-bit components in-process, you might find a few features missing. In practice, these are a few of the limits:

  • You cannot directly open data using 32-bit data providers (often used from File->Open->OLE DB or ODBC).
  • You cannot use SAS Enterprise Guide to import data using 32-bit providers (includes Microsoft Exchange, Microsoft Access, plus legacy formats such as dBase). (Note that this is different than PROC IMPORT, which depends on the bitness of SAS, not of SAS Enterprise Guide.)
  • You cannot view certain results "embedded" directly within the application, such as PDF or RTF, as these use 32-bit viewers.

Finally, if you simply cannot decide, you can install both versions of SAS Enterprise Guide 5.1: 32- and 64-bit. To do so, you must run through the installation process twice, once for each version.

Considerations for SAS Add-In for Microsoft Office

Because it's an add-in to Microsoft Office, this decision is easier. It all depends on which way you decided to go after considering this guidance from Microsoft.

If you have the 64-bit version of Office, you need a 64-bit SAS add-in. And if you have the 32-bit version of Office, you need the 32-bit SAS add-in. And even though there is some overlap with SAS Enterprise Guide, your decision for one application doesn't affect the other. For example, on a single machine you can have the 32-bit version of SAS Enterprise Guide and a 64-bit version of MS Office with the 64-bit SAS Add-In for Microsoft Office.

More than doubled: implications of 32-bit versus 64-bit

The architecture differences of x86 versus x64, and their respective operating systems and applications, are the source of much confusion among SAS customers and among consumers in general.

There isn't a clear-cut, right-or-wrong answer. Which architecture you choose for a particular application depends on many factors. And your decision will have implications, most likely related to how your application deals with legacy processes that use a different architecture. At SAS Global Forum this year, I'll be presenting a short "Super Demo" talk about some of these issues. As I assemble my notes on this topic, I'll be posting more of them here on the blog.

I'm also interested in hearing from you. What have your struggles been like around this topic? Have you found a 64-bit version of an application (SAS or not) that helped you to get beyond a limitation? Let me know by leaving a comment.

tags: 64-bit, SAS Add-In for Microsoft Office, SAS Enterprise Guide


  1. Posted April 4, 2012 at 11:13 am | Permalink

    Good article Chris.

    I recently sold a machine on eBay to someone (consumer) who asked whether the machine was 32 or 64 bit O/S. Well, it had 32 bit Vista on it but had a 64 bit capable chip. However, I told him it didn't matter hardly at all to consumers since they are not crossing these thresholds right now. Half of my machines are 64-bit O/S, half are 32-bit.

    When do you need it? Doing hash tables in Base SAS and needing large PCs/workstations that can address loads of RAM. Microsoft Office 64 causes incompatibility issues with certain add-ins (WinZip Courier, for example). Drivers are a major issue for some older devices.

    RAM is the biggest issue IMO. PCI-e SSDs can overcome it somewhat in 32-bit world but few people have that kind of need (or money).


    • Chris Hemedinger Chris Hemedinger
      Posted April 4, 2012 at 3:39 pm | Permalink

      Thanks for the comment, Alan.

      I think the 64-bit OS is pretty much a standard now on new PCs. With 64-bit architecture and more RAM, your PC can do more for you: run more apps at once, host VM environments, etc. But only specialized applications are designed to really leverage the "elbow-room" of a 64-bit process. From SAS, that includes 64-bit JMP and 64-bit SAS for Windows. Client apps such as web browsers, Office applications, and SAS Enterprise Guide don't usually need that capacity at the process level.

      64-bit apps *are* the future on the desktop, and SAS is correct to offer these 64-bit versions for those customers who need them. But we're not yet to the point where everybody needs them.

  2. Alain
    Posted April 25, 2012 at 9:46 am | Permalink

    Dear Chris,
    I am wondering if there is not a case that you have to install a SAS Enterprise Guide 64-bit: if you call R through SAS/IML from SAS Enterprise Guide and your R is 64-bit. What do you think?

    • Chris Hemedinger Chris Hemedinger
      Posted April 25, 2012 at 9:49 am | Permalink

      Nope! SAS/IML runs in the SAS session, which can be 64-bit even when using the 32-bit EG. So the SAS server probably needs to match R in this case, but EG, as an out-of-process client, does not need to match.

  3. Brian
    Posted September 12, 2012 at 9:25 am | Permalink

    Windows, windows, windoze... Microsoft, microsft, msftft... When are you going to create a Mac OS X option with easy deployment to iOS apps?

    This should be relatively simple if you have a semi-talented programmer to convert the source. I honestly don't understand how a company like SAS could just ignore a market of this size. Have you any idea how many Macs there are out there? It's not the 90's anymore, no matter how much your programmers are stuck in 90's technology that Microsoft is still offering.

    Or, just sit back and do nothing. Companies like Qualtrics and SPSS will be happy to take your business away.

    • Chris Hemedinger Chris Hemedinger
      Posted September 13, 2012 at 10:21 am | Permalink


      SAS has a major offering for the Mac: JMP (which began life as a Mac-only product, but now is very popular on Windows as well). From JMP you can access SAS running on another server, which might be Windows, Linux, or others.

      Also, SAS has several iOS apps to integrate with its business intelligence and visual analytics suite. See this YouTube video to learn more about it.

  4. Mohannad Sayed
    Posted October 24, 2013 at 2:56 am | Permalink

    Dear Sir,

    I have downloaded sas 9.3 in a 32 bit machine and now i want to install it in a 64 bit machine. What should be the consequences and modifications needed..pls guide

    • Chris Hemedinger Chris Hemedinger
      Posted October 24, 2013 at 9:33 am | Permalink


      You can install the 32-bit version of SAS on your 64-bit version of Windows. SAS will operate exactly the same, as a 32-bit process, on the 64-bit environment. While it won't be able to take advantage of 64-bit processing and additional potential memory use, you won't have any of the compatibility problems that can occur when moving from a 32-bit to a 64-bit version of SAS.

  5. Tanja
    Posted March 4, 2015 at 1:48 pm | Permalink

    Thanks for this article. I have experienced some of these issues using 64-bit SAS. For reference, what do you consider "really big data" and what do you consider "big results"?

4 Trackbacks

  1. [...] the 64-bit version of Microsoft Office (and thus using the 64-bit data providers). That works, but it might introduce other incompatibilities with how you use your Microsoft Office applications. Microsoft recommends the 64-bit version of Office in only a few circumstances; consider the [...]

  2. [...] often ask for a 64-bit version of SAS Enterprise Guide. And I know that we will offer it, someday. But it isn't as urgent as some might think, since it's the SAS process that performs all of the [...]

  3. [...] Are 64-bit client applications twice as good as 32-bit applications? [...]

  4. […] Are 64-bit client applications twice as good as 32-bit applications? […]

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>