A recent article by Tony Smith from The Register titled “Mac OS X 10.3 Panther will not be a 64-bit OS” caused a good deal of confusion with many people, including me. It is also caused a heated argument here on OSNews. The basic point of the article is that Mac OS 10.2.7 and 10.3 are not “true” 64-bit OSes, but the article does not clearly explain what a “true” 64-bit OS is. This had led to a lot of claims that the article is false or misinformed, rather than just unclear, which is certainly is.
It turns out that Smith’s article on The Register is more or less correct. More and more evidence is out there that applications on Mac OS 10.2.7 and 10.3 cannot address more than 4GB of RAM, which is the limit imposed by 32-bit operating systems. The basic evidence is from a post on Apple’s darwin-development list by Apple employee (or email account holder at least) Godfrey van der Linden. Van der Linden writes:
“Yes the kernel’s virtual address space will remain 32bit for the medium term but self-evidently we can address >32bit of physical memory from the kernel.”
So the kernel in current (10.2.x) and future (10.2.7 and 10.3 Panther) versions of Mac OS X will only support a virtual address space of 2^32 bytes = 4GB of memory. No one really cares how much memory the OS internals use, the key question is can real life applications break the 4GB barrier? One non-Apple poster on the darwin-development list, Shawn Erickson, speculates:
“Outside of that I believe the user mode libraries/frameworks will remain 32 bit and hence most processes/applications must remain 32 bit (if you are careful of what you use I see no reason you could not use 64 bit addressing in certain tasks). I have not seen anything yet that implies that new 64 bit addressing versions of the systems libraries and framework will be provided in Panther (I bet they will be recompiled to use 64 bit native math, etc. just not addressing). ”
Whenever you compile even the simplest application on an OS, you must link to libraries of some sort. While there are technical details yet to be revealed by Apple, if there are no 64-bit libraries on Mac OS X, the OS does not support 64-bit applications, in all practicality.
An anonymous poster on a Slashdot thread (OK, not the most relibable of sources) confirms this:
“Your code could use 64-bit addresses after being recompiled. But there is only one set of mmap(), etc… traps on the system at the moment (both 10.2.7 and Panther), and they only supports 32bit addresses. So, there is no way to put anything above 4GB in your address space to back those 64-bit addresses.”
Finally, The Ego on the same Slashdot thread says:
“An OS could be called “64bits OS” because it offers a 64bits ABI to userland applications compiled in “64bit mode”. My understanding is that this will _not_ be the case for Panther, all code will be compiled with the traditional ILP32 ABI.”
What does this mean? First, an individual application (or process) on current (10.2.x) and future (10.2.7 and 10.3 Panther) versions of Mac OS X can only address 4GB (2^32 bytes) of memory. So Panther does not change the status quo. As someone who writes Fortran programs that use lots of memory (but is not a computer scientist), MY personal definition of a 64-bit OS is one in which an individual application can use up to 2^64 bytes (17 billion GB) of virtual memory. OSes such as Solaris and 64-bit versions of Linux and Windows meet my test. Mac OS X, in what van der Linden calls the “medium term” (at least the next major release cycle, Panther), does not meet my test.
The other part of van der Linden’s post says that the kernel can support more than 2^32 bytes=4GB of physical memory. So, yes, the 8GB of memory that Apple claims the high end G5 model supports will indeed work. It is just that, from what I gather, no one application can grab all of it at once. Instead, each application can use only 4GB (the virtual address space limit which has not changed under Panther).
If this sounds suspiciously like 32-bit Windows, you are correct. The Windows NT kernel (found in Windows NT 4, 2000, XP and 2003) supports more than 4GB of physical RAM, but each process has only a virtual address space of 4GB, although the practical limits are much lower, as I will explain in a minute. For commercial market segmentation reasons this >4GB of physical RAM feature appears only in the 32-bit versions of Windows 2003 Enterprise and Datacenter Editions. Also for market segmentation reasons, hardware support for this feature is found only in the Intel Xeon chips, and not the nearly identical Pentium 4s. The 32-bit x86 Linux kernel also has support for the Xeon’s memory addressing abilities. Somewhat humorously, Red Hat is playing a similar segmentation game by charging extra for the more than 4GB of physical RAM feature.
As a side note, if you care, an Apple developer’s guide for the G5s says that they support 2GB DIMMs, so the high end G5 can really use 16GB of physical RAM, if you have the money. As a further side note, Motorola’s documentation for its recent G4 processors suggest that they can support 64GB of physical RAM, so Apple did not technologically have to wait until IBM’s release of the PowerPC 970s to support more than 2 or 4GB of RAM in PowerMacs and XServes. It’s not clear that Apple will support any of the 64-bit defining features of the PowerPC 970/G5, unless you are a cryptographer who cares about integer arithmetic with larger numbers.
Let’s go into some more detail about what the actual memory capabilities of Mac OS 10.2 Jaguar are. From some experimentation with C and Fortran codes, I have found that individual applications on 10.2 can address close to 4GB of virtual memory, even if the machine has much less physical RAM, as all currently shipping Macs do. The catch here is that only 2.25GB of this RAM is contiguous. So a simply written C or Fortran program cannot address more than 2.25GB of memory. The remaining 1.75GB of memory is not contiguous either. The problem here is that various shared libraries are loaded into memory at fixed locations in the 4GB of virtual address space, which splits up the available memory for the user.
How do 32-bit Windows and Linux compare? Windows by default allocates 2GB of RAM to each process. The other 2GB of RAM in the 4GB of virtual address space is reserved for the OS. In Enterprise Edition, there is a flag you can set to change the allocation to a more fair 3GB application/1GB OS breakdown. On top of this 2GB memory limit, 32-bit Windows allocates shared libraries in a poorly planned random manner, so the 2GB of address space is split up into chunks, and actual programs may only be able to access 1.5-1.7GB of contiguous memory.
32-bit Linux splits its 4GB of virtual address space per application into 3GB for the application and 1GB for the OS. However, of the 3GB for the application, only 2GB are contiguous, so again, simple C and Fortran programs (and many real life applications) can only use 2GB.
Apparently Microsoft has some hack so software vendors can use more than 2GB of RAM in Windows, and The Register article that started this discussion article alludes to the fact that Apple has added a similar hack to Panther. But these hacks are only practical for big money software companies such as Oracle and Adobe, and the performance of the hacks is often less than going to a true 64-bit application on a true 64-bit OS such as Solaris, AIX, HP-UX, Irix, zSeries, Tru64 and the 64-bit versions of Linux, Windows and the BSDs.
Why might someone want to use more than 4GB of virtual memory? First, some scientific problems require that much memory. Fair enough. Second, people editing video or other large multimedia files might want to put the entire file into memory, to work on all at once rather than only one piece at a time, which reduces loading from the disk. Third, databases are really big and getting bigger, and putting more of your data in memory speeds up access. Fourth, even more people with very little physical memory, 64-bit virtual memory can be a big help. Remember those annoying shared libraries that take memory away from the user? In a 17 billion GB address space, there is presumably plenty of room to stash those shared libraries so that they never cramp the space taken up by your actual data.
A good way to conclude this discussion is to summarize Apple’s market position with regards to memory handling. Mac OS X is not a 64-bit OS, by my definition emphasizing the ability of applications to use 64-bits of memory. Therefore, Apple is behind almost all commerical UNIXs, 64-bit versions of Linux for many platforms including Intel’s Itanium and AMD’s Opteron/Athlon64, and 64-bit versions of Windows for Itanium and Opteron (the latter is to be released in early 2004 to OEMs only, rumors say).
However, as far as 32-bit OSes go, Mac OS X is actually somewhat ahead in the memory game. The virtual address space available to an application is close to 4GB, which is more than the 2GB Windows provides and the 3GB Linux provides. And the Mac’s contiguous address space of 2.25GB exceeds the 1.5-1.7GB on Windows and the 2GB for Linux. Furthermore, Apple will not require you to shell out big money for some “Advanced Server” version of its OS if you want to install more
than 4GB of physical memory in your machine, which is what Microsoft and Red Hat want you to do.
The downside of Apple’s support of more than 4GB of physiscal RAM is that there is less need for it on a Mac. Most Macs are used by one (professional) user at a time, and this user is typically going only to use one big application at a time. Unless this user opens up two massive applications, he won’t need more than 4GB of RAM, and he cannot use more than 4GB of RAM in one application because he is not running a true 64-bit OS.
On the other hand, Windows servers often run Terminal Services, which, while expensive, lets multiple users remotely log onto a GUI session and run multiple applications. If each user opens a big application, that extra memory can become handy quickly. Apple does not offer a Terminal Services solution, instead letting you log on remotely via ssh or telnet to a command line or X-Windows environment, where you are pretty much limited to using ported open source programs.
If you want a 64-bit OS on the desktop, use the appropriate versions of Windows or Linux on an Itanium or AMD64 (Opteron, Athlon64) machine. I would suggest AMD64 because it’s fully backwards compatible with existing 32-bit software for the appropriate OS, althogh Intel is trying hard to improve x86 emulation on the Itanium. Near-future versions of the Mac OS can run on a 64-bit processor from IBM, but will not themselves support 64-bit applications.
Update: A similar article, at eWeek.
About the Author:
A sometimes Fortran programmer who uses Mac OS X on his desktop machine and Solaris to run his codes.