Talking around the real problem—can’t make use of my RAM

2006-12-25 • SEND FEEDBACK |
Related: Apple, Apple macOS, Mac Pro, memory, Photoshop

Scott Byer’s blog at blogs.adobe.com is a case of more is less in the discussion of 64-bit applications. He starts out with the outlandish claim that “applications don’t allocate RAM”—which is both true and false (depending on how strictly you define “RAM” and “allocate”). See sidebar.

His statement obfuscates the discussion, while talking around the real issue with Photoshop’s performance—the sluggish swapping of image pixels, history, etc to and from the hard disk for lack of adequate virtual memory (backed by real physical memory).

Today, a 32-bit Photoshop can’t allocate more than 3GB of virtual memory, even if there is 16GB of physical memory installed! So you spend $5000 on 16GB of Mac Pro memory, and Photoshop uses a paltry 3GB—now that’s a bummer. As a practical matter, Mac OS X 10.4 makes it very difficult to write a 64-bit Photoshop, but Mac OS X 10.5 might change that with the availability of all the 64-bit libraries required to produce a 64-bit application (32-bit libraries will still exist). I haven’t followed “Leopard” closely enough to understand if Apple will finally put this problem to rest.

Mac OS X 10.4 is already 64 bits in key low-level areas—otherwise it would have no way of using the 16GB or RAM a Mac Pro or PowerMac can physically accept—it uses physical memory not allocated to applications or other system use for disk caching.

Photoshop CS2 and CS3 exhibit the sluggish disk-swapping behavior today whenever opening a large file with numerous layers, large enough history, etc—all while another 3-4GB of my 8GB memory sits idle (except for its marginal value for disk caching). If one were to stuff 16GB of memory into a Mac Pro, and if there were a 64-bit Photoshop, it could allocate 14 GB or so of virtual memory, most or all of which Mac OS X could readily assign to real physical memory—goodbye disk/memory swapping.

A true 64-bit Photoshop (one having a 64-bit address space) could allocate virtual (aka “pretend”) memory sufficient for any conceivable image that could be stored on a hard disk. Coupling that with sufficient physical memory “backing” the virtual memory, performance-robbing memory<=>disk<=>memory swapping would be eliminated, or at least minimized to an insignificant amount.

Byer’s “lack of any sort of other performance win” argument is specious—the performance gain of keeping the image and associated information in virtual memory (backed by real physical memory) for real-time response is huge compared to having to swap to disk. Any Photoshop user who has experienced Photoshop disk swapping knows this to be true to an extreme—try editing a 1GB image with only 512MB of memory in the system.

To say otherwise is just an excuse—all the yack about how pointers are now 64 bits instead of 32 bits, 64 bit math, etc is a distraction. The real issue is that the code base is probably like most code bases—full of latent correctness bugs that don’t manifest themselves only because pointers and other scalar quantities happen to remain 32 bits. Recompile as a 64-bit application, and all those latent correctness bugs suddenly appear; code that worked fails when 32-bit pointers now occupy 64 bits, data structures suddenly are a different size, optimized loops that made assumptions about sizes now fail, plugins and their APIs break, etc.

So yes, it is a real challenge to move to a 64-bit application. Adobe would have to support multiple combinations of Intel/PowerPC at 32/64 bit. But Adobe could also keep the PowerPC and Intel version at 32 bits for Mac OS X 10.4, and move to 64 bits only for Intel and Mac OS X 10.5. I think that is an acceptable compromise, and it’s 3 builds versus 2 today. The bugs exposed by building a 64-bit version are still bugs, even if they don’t manifest themselves in a 32-bit version, and fixing them will make for a superior code base in the long run. And a thorough test suite, a requirement for releasing any quality software application, should make short work of testing 95% of Photoshop functionality for each version.

The justification for all this is that there is a tiny 64-bit user base—zero for Mac OS X 10.4 and very little for Windows. But with Mac OS X 10.5 expected to ship about the same time as Photoshop CS3, the justification seems a little stretched—the high-end Mac OS X user base is likely to switch over rapidly to 10.5, and any Photoshop user whose time is money will quickly switch if promised a big speedup for huge files—witness the frustration in many online forums. Still, Byer makes a solid point for the next 9 months or so, but by fall of 2007, there are likely to be millions of Mac OS X 10.5 users out there.

  As a professional software developer with 23 years experience, I have more than a little expertise in this area. It’s true that applications don’t have direct control or direct access to real physical memory. That has been true since 1980 or so in some operating systems, even when machines had less than 1MB of physical memory (VMS and BSD Unix for example). But it’s also true that they make system calls to allocate more virtual memory, which, if there is enough to go around, works out to allocating more physical RAM to that application.
   Furthermore, it is only the action of “allocating memory” (eg malloc()) on the part of applications (or drivers and the like) that ultimately causes the operating system to go through its own machinations of assigning some amount of physical memory for the requested amount of virtual memory (this assignment varies continually, as the physical memory is shared among applications).
   The details are unimportant, but suffice it to say that I can write an application which uses less than a megabyte of memory, or one that allocates as much as 3.6GB on Mac OS X (using suitably-sized chunks). The impact on other applications is real, and is caused by the application “allocating memory”, or rather requesting virtual memory that ultimately results in the allocation of some amount of physical memory by the operating system, up to and possibly as much as the entire amount of virtual memory. In fact, Mac OS X offers system calls to lock down that memory to real physical memory, making it unavailable for sharing with other applications (DiskTester does this for its disk speed testing).