Memory has always been a problem with computing systems. Take the original Macintosh, which was shipped with only 128 KB of RAM. Around that time, Apple chairman Steve Jobs was quoted as saying that "developers would just have to learn to program tightly." Naturally, it was only eight months later when Apple produced the Fat Mac, a version running with a full 512 KB of RAM. The rest is history.
Computers have always needed access to a lot of memory. In fact, memory has been touted as the single most significant limitation for application operation. We're a long way from the kilobytes of memory in the original Macintoshes and IBM PCs, but even when computers are running with true 32-bit processor architectures and the corresponding operating systems, it's still possible to run into memory bottlenecks. That's because the 32-bit processor is designed to address no more than 4 GB of RAM (see Figure 1).
In default configurations, the base 4 GB of a 32-bit system is divided into two sections. The first 2 GB is reserved for kernel processes. This space is allocated to the core operating system. The second 2 GB of RAM is assigned to application virtual memory. This is the space where applications can execute. Stopgap measures can change these configurations. For example, if you assign the /3GB switch to the boot process, then the Kernel Process space will be reduced to 1 GB, leaving 3 GB reserved for applications.
You can also use the Physical Address Extension or /PAE switch at startup. This changes the memory management space from 32 to 36 bits, and allows the OS to swap application memory into the Address Windowing Extensions. This provides more physical memory to the system beyond the base 4 GB. However, when applications need to execute code, they must be swapped back into the base 2 GB of application virtual memory (see Figure 2). This means that even if a system "sees" more than 4 GB of RAM, applications are still bottlenecked by having to fit into the base 2 GB to execute.
The only way to move beyond these limitations and access more memory while still executing the same application code is through x64 processor architectures. Unlike the Itanium architecture provided by Intel, the x64 architecture is simply an extension of the x86 or 32-bit architecture all of us have come to know and love. By default, x64 processor architectures can address more memory -- much more memory. The maximum amount of physical memory that will be accessible to your applications depends on the operating system you choose to run. Table 1 outlines the various memory limits available based on the version of Windows you run on your x64 machine.
Windows x64 editions memory support
|Windows version||Physical memory support|
|Windows XP Professional x64||128 GB|
|Windows Server 2003 Standard x64 Edition||32 GB|
|Windows Server 2003 Enterprise x64 Edition||2 TB|
|Windows Server 2003 Datacenter x64 Edition||2 TB|
|Windows Vista Home Basic x64||8 GB|
|Windows Vista Home Premium x64||16 GB|
|Windows Vista Business, Enterprise or Ultimate x64||128+ GB|
|Windows Server 2008 Web or Standard x64 Edition||32 GB|
|Windows Server 2008 Enterprise x64 Edition||2 TB|
|Windows Server 2008 Datacenter x64 Edition||2 TB|
For example, if you are running the x64 Web or Standard Editions of Windows Server 2008, your systems will be able to access up to 32 GB of physical RAM. If you are running the x64 Enterprise or Datacenter Editions, your systems will be able to access up to 2 TB of RAM. That is significantly more than what is available on a 32-bit system. In addition, each OS can access more than 16 TB of virtual memory. Of course, no one has a server configuration that is available with support for 2 TB of RAM or a workstation configuration with access to 128 GB -- but they can't be that far away.
For Windows Server 2003 systems to access the full RAM capabilities of the x64 platform, they must be running Service Pack 2 or later. In addition, Microsoft claims that the x64 versions of Vista Ultimate, Enterprise or Business editions can ultimately access more than 128 GB of RAM. However, according to the Microsoft Developer Network website, applications will only have access to 128 GB even if more can be found on the system hardware.
One thing is for sure though: Each and every Windows OS based on x64 code can access more memory by default than any x86 or 32-bit OS. Accessing this much RAM means applications can now fully execute as intended. Microsoft's Windows Server operating systems can assign a full 8 TB of virtual memory to any application. In addition, applications don't have to be written in native x64 code to take advantage of this change.
Even 32-bit applications will see a performance gain when running on an x64 OS because, for the first time in their history, those applications can gain access to a full 4 GB of RAM without having to share the base memory blocks with the OS. No more switches are required and application performance improves in every single instance. But the application must be able to support the /LARGEADDRESSAWARE option within its code to profit from the full 4 GB of RAM.
If you want to remove the single most constricting bottleneck from your systems, then look to x64 operating systems. Few vendors (if any) now sell x86 processors, and all organizations who own them should be running x64 operating systems on x64 hardware, even though the x86 OS is compatible. Best of all, you don't even need to change your applications to access this feature. Every x86 application is x64 compatible by default. If you need speed, then move up to x64. You'll never go back. Developers will also be thankful that they don't need to program "tight" -- no matter what Steve Jobs says.
ABOUT THE AUTHOR
Danielle Ruest and Nelson Ruest are IT professionals specializing in systems administration, migration planning, software management and architecture design. Danielle is Microsoft MVP in Virtualization and Nelson is Microsoft MVP in Windows Server. They are authors of multiple books, including the free Definitive Guide to Vista Migration for Realtime Publishers and Windows Server 2008: The Complete Reference for McGraw-Hill Osborne. For more tips, write to them at email@example.com.
This was first published in May 2008