| This post was kindly contributed by The SAS Dummy - go there to comment and to read the full post. |
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 open data using 32-bit data providers (often used from File->Open->OLE DB or ODBC).
- You cannot send e-mail content as “one-off” messages from within SAS Enterprise Guide (uses MAPI, which is 32-bit)
- You cannot import data using 32-bit providers (includes Microsoft Access, plus legacy formats such as dBase).
- 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.
| This post was kindly contributed by The SAS Dummy - go there to comment and to read the full post. |