![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
|
|
![]() |
|
|||
| By Chris Angelini | ||||
LAST MONTH I WORTE ABOUT AN experience with a customer and his new multimedia workstation. Briefly, he wanted a powerhouse, so I helped him build it using a fancy motherboard, a dual-core processor, and 4GB of memory, hitting the limit of what his 32-bit installation of Windows XP could handle. The problem appeared when he first fired up Adobe’s Photoshop. He immediately noticed that more than 2GB of his physical memory wasn’t being recognized. A quick look under the hood at Windows' Device Manager turned up a similar issue: 1GB of memory was missing in action. After instinctively swapping out the modules for some new ones and subsequently spending a couple of hours researching online, it became clear that the problem was actually a combination of things. First, his fourth gigabyte of memory was likely lost to the addressing of peripherals in his machine. Second, the Photoshop difficulties were a result of memory management issues in the software itself, which kept Photoshop from seeing more than 2GB of the physically installed 4GB. Adobe’s own TechNote article explained the scenario as a limitation. We were consequently led to believe it was Adobe at fault for handicapping Photoshop. DIGGING DEEPER I wasn’t comfortable dropping the issue at “sorry for the inconvenience, hopefully you’ll be able to use the other 2GB of RAM sometime in the future.” So I kept digging in the hopes of more concrete answers. Indeed, the memory missing from Windows XP turned out to be an addressing issue. Switching to a different operating system would not have helped either. The technical explanation is easy enough to follow, especially if you remember back to when 16-bit PCs with 1MB of RAM could only really make use of 640KB. Addressing all 4GB of memory would have required a full 32-bits of physical address space. Unfortunately, PCs include more than just memory, so other mapped devices like graphics cards tend to occupy the upper gigabyte or so. As a result, memory gets the bottom 3GB. Anything you install beyond that simply cannot be addressed. If you want to see the problem exacerbated, upsell a pair of GeForce cards with 768MB of memory in a 32-bit environment. Those two boards by themselves will grab 1.5GB of address space before you even drop in a memory module. But not all is doom and gloom. When you adopt a proper 64-bit operating system, which also means selling a compatible processor, chipset, and motherboard BIOS, addressing issues evaporate. You’ll still have the same memory holes in the 3-4GB space. However, with much more room to address, adding extra memory to compensate shouldn’t be a problem when it’s actually needed. As for my customer, it doesn’t look like there’s any way to get that last gig of memory back. The /3GB and /PAE extensions you can add to the boot.ini are useless. Enabling /3GB simply changes the way the 32-bit address space is partitioned, opening up 3GB of user space yet sacrificing kernel memory and performance in the process. PAE, on the other hand, enables 64GB of address space, but it introduces fresh 64-bit compatibility issues. That’s why Microsoft effectively disabled the setting in Windows XP Service Pack 2. One of the few ways to actually recover that extra memory would be to buy a motherboard with a BIOS feature called memory hole remapping, which moves those pesky void zones higher into 64-bit address space. Of course, that’s going to require a 64-bit hardware infrastructure, at the very least. Do careful research before pursuing the idea of remapping, since the feature isn’t supported by every board. Many boards that top out at 4GB have remapping; platforms with 8GB are also safe. The other hope would be a memory hoisting, a motherboard feature that leaves the holes in place and remaps the memory itself up above the 4GB ceiling. Lesson learned: When it comes to selling 32-bit operating environments, it’s really best to stick with 2GB to 3GB of installed system memory. But don’t worry—the issue of Windows’ missing memory will work itself out as 64-bit becomes more pervasive. THE WAY TO MANAGE MEMORY The second problem, which was Photoshop’s inability to see more than 1.7GB of the machine’s supposed 3GB, bore no relation to the first. Adobe’s documentation simply stated that Photoshop was limited to 2GB of memory and couldn’t use anything beyond that. As it turns out, every application run under 32-bit Windows is subject to that same rule. I spent some time speaking with Dr. Michael Schuette, vice president of technology development at OCZ Technology, hoping to better understand who was to blame and why. “Windows Memory Management,” Dr. Schuette explained, “is done by division between signed and unsigned memory addresses, so instead of having two to the thirty-second power memory addresses, you have two times two to the thirty-first addresses. One side is going to be minus and the other side plus. Everything on the plus side is going to be kernel memory and cannot be accessed by any user. Everything on the minus side is user memory. But the boundary between those two—because we’re using virtual addressing—is floating. So even with 2GB of physical memory you can still have 2GB of user memory. If you go to 4GB of physical memory, though, you’re still limited to 2GB of user memory. Out of those 2GB, that’s where all of the applications have to play, regardless of whether it is Photoshop or any other application.” Technically, Photoshop should have 2GB of space in which to work on my customer’s system. But because of the way Photoshop allocates memory, it has to leave some for the operating system and other applications. Hence the 1.7GB of usable memory. Adobe does suggest the /3GB boot.ini switch as a means to give the program access to more memory. However, in a machine with 4GB of physical memory (only 3GB of which is being addressed), you’re cutting out the kernel space used by the operating system, and thereby sacrificing general system performance in favor of the application. As I mentioned in this column last month, Photoshop is a 32-bit application and will be until Adobe can justify the wholesale transition to 64-bit. That means a large enough install base of 64-bit hardware and software to do away with the 32-bit version completely, so it may take a while. In the meantime, Adobe’s apps have no problem running on a 64-bit foundation. A 64-bit environment frees your customer from the 2GB limit on user memory. If he has 4GB of memory installed, all 4GB can be purposed as user memory, completely sidestepping the 2GB ceiling. Adobe defines exactly what happens from there with another TechNote bulletin. In 64-bit workstations with more than 4GB of memory, 3GB is used for image data. Everything from 3GB to 3.7GB can be used for plug-ins. Above 4GB, memory is used by the operating system as a cache for scratch disk information. MIX IN A FEW CORES Now, here’s where things get a little trickier. The question recently came up about how memory is managed in machines with multiple cores. Specifically, in talks with Adobe about its new After Effects CS3 Professional, it came up that the software could now take advantage of many gigabytes of memory on a 64-bit platform. The idea has some legs, since we were talking about workstations with two processors, each with two or four execution cores. If you’re running under a 64-bit operating system, how does that machine determine what to do with installed RAM? I again went fishing, and OCZ’s Dr. Schuette was able to provide some answers. “The memory subsystem is defined on the CPU level, not on the chipset level. Every CPU out there consists of essentially two parts. One is the classic CPU as we know it and the other part is what’s called the memory management unit, which creates the virtual memory system. The chipset only translates the information into physical row and column addresses. If you have two, four, or eight CPUs in there, then each has its own memory management system, so each CPU can take a piece of the physical memory, depending on the OS you’re running.” In other words, it’s technically possible for multiple processing cores to address different chunks of physical memory. Of course, the underlying hardware infrastructure has to be 64-bit in order to rise above the 4GB cap, as does the OS, but there’s no reason it shouldn’t work. Properly optimized, Adobe’s 32-bit applications can scale well in systems with lots of memory and multi-core CPUs. That’d certainly be a solid reason to encourage customers down the 64-bit infrastructure path. GRIDIRON ADDS GRANULARITY So 32-bit apps like Photoshop are limited to using 2GB of user memory on 32-bit operating systems. Fair enough. Those same 32-bit applications can address up to 4GB on machines running 64-bit operating systems, per Dr. Schuette’s explanation. Now we’re talking. But you have a customer asking for a workstation running a 64-bit copy of Windows Vista and Adobe After Effects with 16GB of memory. Why? Apparently, his friend read that it’s possible to get After Effects to put all of that RAM to use crunching away on a render job. Believe it or not, there’s some actual truth to this idea provided you install After Effects with GridIron Software’s Nucleo Pro 2.0, a workflow plug-in that introduces unique functionality to the software. If you’re not familiar with Nucleo, the add-on’s first iteration surfaced back in 2005 and took over rendering using background processes. The plug-in was all about performance, since it leveraged all of a machine’s resources into finishing jobs as quickly as possible. In doing so, there wasn’t any processing power left over, so you had to walk away from the box until Nucleo had rendered its job. Nucleo Pro 2.0 is better designed for threaded boxes because it pushes the render processes to a lower priority, letting you return to After Effects and continue working. “We’re basically an umbrella controller application embedded within After Effects,” says Ben Piercey, senior director of product management at GridIron Software. “When After Effects launches, we produce all of the background instances of the application that run. We control them. So whenever you click a button to render or preview, we intercept that command and force it down the processes that we manage. That’s how we maximize CPU and RAM utilization. If there are four cores, we spawn four processes. Each of those processes can get to its maximum RAM limits.” On a quad-core machine, Nucleo runs four instances of After Effects in the background, each one maxing out available memory. In a 64-bit box running Vista 64-bit and a 32-bit copy of After Effects, that’s up to 4GB per core. A workstation with 16GB of memory and a quad-core Xeon 3200, for example, will put all 16GB to use. NAVIGATING THE MINEFIELD Right now, GridIron’s technology is unique. The way Nucleo Pro 2.0 handles memory and CPU cores is patented by the company. However, according to GridIron’s Ben Piercy, there’s nothing keeping other developers from using multi-core CPUs to take advantage of copious memory in a 64-bit architecture, or even in 32-bit software like After Effects. The key lies in building solid 64-bit platforms today, even when your customers are still running a handful of legacy 32-bit applications. The reseller’s challenge then becomes getting around the sporadic disconnects keeping 64-bit technology from becoming more mainstream, such as missing drivers and incompatibilities with older software. Our own editors are fighting 32-bit apps that won’t run under 64-bit Vista. Just imagine the potential headaches on an engineering or CAD platform. In the months prior, I outlined some of the pitfalls to jumping onboard the 64-bit bandwagon. I’m not saying those problems have all been solved. However, draw a parallel between 16-bit DOS and 32-bit Windows 2000. As more software is optimized for multi-core processors and huge banks of memory, you’ll be spending less time wondering why Photoshop can’t see more than 1.7GB and instead upselling the idea of background rendering on powerhouse workstations. |
||||
Copyright © 2007 RAM Magazine. All rights reserved.
Do not duplicate or redistribute in any form. |
||||