Another exciting development associated with JMP 7 is the release of the 64-bit version of JMP for both the Windows and Linux operating systems. Why is this exciting? Although a 64-bit application such as JMP may not necessarily run faster than its 32-bit counterpart, the amount of data that JMP can analyze is substantially increased. We believe that this will have a significant impact on our users, many of whom continue to place ever greater demands on JMP in terms of the sheer size of the data set they expect JMP to handle.
Unlike the SAS System, JMP must load the entire data set into memory before it can analyze the data. Hence, JMP faces a very fundamental constraint in terms of the size of the data set it can analyze – a constraint imposed by the size of the address space defined by the operating system itself.
In principle, in a 32-bit operating system, you have 2^32 bits with which to form the address of a location in memory where a piece of data may be stored; thus, in theory, when JMP runs on a 32-bit operating system, there are 2^32 “theoretical” addresses at which it could access and/or store data. You might think that this would be more than enough “room” for data, but some of our users, particularly those who are using JMP Genomics, are already experiencing the pain of this limitation. Indeed, some of their data sets are so large that 32-bit JMP cannot load their data at all.
But in a 64-bit operating system, you have 2^64 bits with which to form an address for a memory location. This constitutes a theoretical limit of 16 exabytes; in terms of data set size, this would be roughly two billion rows of data. In other words, 64-bit JMP can load a substantially larger data set into memory than its 32-bit predecessor ever could before. This makes it possible for JMP Genomics to analyze data sets that were beyond the capabilities of 32-bit JMP.
It should be noted that the description above is somewhat of an oversimplification. It is not really true, for example, that an application running on a 32-bit OS can access all 2^32 “theoretical” memory locations. This is because the operating system restricts the range of addresses that an application is allowed to access. Some “theoretical” addresses are “off limits” to all applications; these special addresses are reserved for the operating system itself. A similar qualification applies to a 64-bit OS – not all 2^64 “theoretical” addresses are accessible to an application such as JMP. Nevertheless, when all such qualifications are noted, the fact remains that in practice a 64-bit operating system offers a tremendous amount of extra addressing space when compared to a 32-bit operating system. This in turn means that you can load more data into the 64-bit version of JMP running on a 64-bit operating system than you ever could before running the 32-bit version of JMP on a 32-bit operating system.
About a year ago, Linux Journal published an article, 64-Bit JMP for Linux written by Erin Vang of SAS Institute. (See Linux Journal: Issue 149, Sept. 2006, pp. 82-85.) In that article, I predicted that 64 bit operating systems would increase in popularity and that Linux would begin to gain ground on the desktop as more users adopted the 64 bit Linux OS. However, neither prediction has come true. The migration to 64 bits has been much slower than I anticipated. And the adoption rate of Linux on the desktop has basically flat-lined. As far as Linux is concerned, I believe that users have refrained from migrating to the Linux desktop partly because the applications they’ve come to depend upon still aren’t available – at least, not applications of quality comparable to those found on Windows and the Mac. And I think the same reasoning applies to the slow adoption rate of 64-bit computing. Of course, as long as a user has relatively small data sets to analyze, there is little urgency to move to a 64-bit platform. But even if the size of the user’s data is overwhelming their 32-bit applications, there is little point in adopting a 64-bit operating system if the 64-bit versions of the applications the user needs aren’t there!
Fortunately, those individuals who face the challenge of analyzing increasingly large data sets can now migrate to a 64-bit Windows or Linux operating system and know that at least one powerful application will be there: the 64-bit version of JMP 7.
A Word about the Mac
Unfortunately, although a 64-bit implementation had also been planned for the Macintosh version of JMP 7, our strategy for creating it had been based on the assumption that Apple would provide support for migrating 32-bit Carbon-based applications (such as JMP) to its 64-bit Mac OS X. However, shortly before the release of JMP 7 (and after considerable effort on the part of our Mac development team to port our Carbon-based application to 64-bit Mac OS X), Apple dropped its support for this migration path. Instead, Apple announced that if you want to create a 64-bit application for Mac OS X, your application has to be written to target the Cocoa API. This prevented us from creating a 64-bit version of JMP 7 for the Mac, since targeting Cocoa would have entailed a massive rewrite of the “host” level code within JMP. Given the timing of Apple’s announcement, there simply wasn’t time to convert JMP as required. This is bad news for our Macintosh users, since it means that they won’t be able to take advantage of the benefits that a 64-bit address space has to offer. The only consolation I can offer is that within the JMP 8 development cycle, we plan to completely rewrite the entire Macintosh host layer of JMP in Objective C and to target the Cocoa API, thereby converting JMP into a truly native Cocoa-based application. This will enable us to produce a 64-bit version of JMP for the Mac in time for the release of JMP 8. But for the time being, all I can do is extend my apologies to our Mac users, many of whom have been loyal JMP users for years, some going all the way back to version 1 of JMP for the Mac. Please be patient with us; we will make the 64-bit version of JMP a reality when we release version 8.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.