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

15 Comments

  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).

    -Alan

    • 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

      Brian,

      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

      Mohannad,

      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"?

  6. Turner Bond
    Posted March 18, 2015 at 1:36 pm | Permalink

    We recently did some speed testing which included SAS x32 vs x64. These involved basic desktop installations with BASE, GRAPH, STAT, IML, ETS and various Access products. To complicate matters we also upgraded our drives from HDDs to SSDs, our OS from Win7 x32 to x64 and our SAS from 9.2 to 9.4. In order to tease out the impact of various improvements and upgrades, we moved one of our SAS licenses around to 4 different systems during install, in order to see the impact various options had on speed.
    With SAS 9.4 we learned we had to turn off ODS graphics before running any STAT procs or we would suffer a radical reduction in speed. Armed with that information, we developed a standardized test suite which involved thousands of uses of procs surveyselect, and surveymeans, as well as thousands of minor uses of the data step, proc sql and merges. The test suite also involved reading both SAS and Excel data and a few exports to Excel. Below are the four systems we tested and how long different configurations of SAS took on each:
    Systems tested:
    A) x32 i7 HDD: Dell Latitude Laptop with Intel i7-2760QM 2.4ghz CPU and WDC 7500 rpm HDD. Runing Windows 7 32-bit. Bitlocker partition on drive
    B) x64 i7 SSD: Dell Latitude Laptop with Intel i7-2760QM 2.4ghz CPU and Samsung EVO 840 SSD. Running Windows 7 64-bit. Bitlocker partition on drive
    C) i7 -X990 w RAID0: Sager Laptop with Intel i7-x990 3.47ghz CPU and unknown RAID 0 drive configuration. Running Windows 7 64-bit.
    D) AMD FX 8350 SSD: Desktop system with AMD FX 8350 4.0ghz CPU and Samsung PRO 840 SSD. Running Windows 8.1 64-bit.

    Test results:

    System  SAS ver.          Seconds
    A)      9.2 -x32            161
    B)      9.4 -x64             97
    C)      9.4 -x64             82
    C)      9.4 -x32             85
    C)      9.2 -x32            108
    D)      9.4 -x64             84
    

    What we learned:
    x64 SAS runs about 3% faster than x32 (see testing on machine C).
    For our application SAS 9.4 runs about 21% faster than 9.2.
    A $1300 intel CPU running on Win 7 is about 2% faster than a $200 AMD chip running on Win 8.1 with a very fast drive. In this case both hard drives are very fast, but the SSD on the AMD machine proves to be about twice as fast as the RAID0 drive on the Intel machine when tested using copy and paste routines.

    • Chris Hemedinger Chris Hemedinger
      Posted March 18, 2015 at 5:36 pm | Permalink

      Turner, thanks for sharing these! And thank you for ensuring "parity" of options between your 9.2 and 9.4 tests. The ODS Graphics default behavior (and default of HTML output destination) was added in SAS 9.3. It can enrich your results, but producing these additional plots will definitely affect the processing time.

      • Turner Bond
        Posted March 19, 2015 at 3:10 pm | Permalink

        You're welcome. Thanks for your straight talk about x32 vs x64 as well.
        - - -
        Yes. I actually had to rerun the 9.2 tests after tuning the options, because one of the changes knocked a few seconds off the 9.2 times.

  7. Posted April 17, 2015 at 2:38 am | Permalink

    I use the entire Microsoft stack for BI, and I am certain that migrating to the 64-bit versions added power to my capabilities. Moreover, the 64-bit versions of "everything Microsoft" are the future, so why not get on with it. The transition from 32-bit to 64-bit was more painful than I expected, so be sure that you do not trivialize the conversion. My other comment is that the 64-bit versions of the software make RAM much more important than with the 32-bit stack. My advice is to switch now to the 64-bit versions of the Microsoft stack and to upgrade to a minimum of 6 mb RAM (better yet, or as much as you can afford). Hope this helps...

    • Chris Hemedinger Chris Hemedinger
      Posted April 17, 2015 at 8:23 am | Permalink

      Thanks for sharing -- I assume you meant to say "6 GB of RAM" -- but I think that these days 16 GB of RAM is a minimum amount for a desktop system that you use for professional work.

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> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" highlight="">