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.
23 Comments
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
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.
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?
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.
Pingback: The top gotchas when moving to 64-bit SAS for Windows - The SAS Dummy
Pingback: Should you care about 64-bit applications? - The SAS Dummy
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.
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.
Pingback: My favorite SAS tips and tools from 2012 - The SAS Dummy
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
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.
Pingback: Transitioning to 64-bit SAS on Windows—some resources - SAS Users
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"?
Tanja, if you're noticing a performance degradation in 64-bit SAS compared to 32-bit SAS, you should peruse the guidance offered by Margaret Crevar in her series of blog posts for SAS admins and performance tuning. The FULLSTIMER option can be helpful in determining what's going on.
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:
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.
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.
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.
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...
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.
Chris,
question for you. Our administrators did not do sufficient research when standing up our SAS Enterprise Guide 7.1 client connecting to SAS 9.4 7.1 box. They installed EG 7.1 64 bit as a client, but we have 32 bit Microsoft office and so now the 2 are not compatible. Can we go back to EG 7.1 32 bit and what would be the impacts of doing so?
Yes, you can install the 32-bit version -- instead of or in addition to the 64-bit version. As long as you're using the same version level of EG, there are no bad impacts. You can share project files and all is good.
You say this ... "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."
And I say "How?" ... we use response files for silent SAS installations, and there is no 'Bitness' option for the Addin response file, so basically it defaults to what bitness EG is installed, which is a huge problem for us using 64-bit Office.
If there is an option we can add to the response files to force a 64-bit install of the addin over a 32-bit EG then I'm all ears ....
I hope you're already working with SAS tech support on this. The MS Add-In installs are ultimately MSIs, which should provide one version for 64-bit and one for 32-bit. It might take a little bit of unrolling of the SAS install package to get there. SAS Tech Support should be able to help.