posted by Jeremy T. Fox on Fri 11th Jul 2003 16:55 UTC
"Counting the Bits of a Panther, Part II"
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.

Table of contents
  1. "Counting the Bits of a Panther, Part I"
  2. "Counting the Bits of a Panther, Part II"
e p (0)    152 Comment(s)

Related Articles

posted by Thom Holwerda on Wed 17th Sep 2008 09:15 submitted by Andrew Youll
posted by Thom Holwerda on Mon 15th Sep 2008 22:17
posted by David Adams on Tue 9th Sep 2008 17:49, submitted by pickmeupscotty