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).

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.

Requires Free Membership to View

In this situation, applications have access to more physical memory, but the core OS becomes a bottleneck because it cannot address its full complement of memory.

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.

Figure 2

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.

Windows x64 Resources

Comparison of 32-bit and 64-bit memory architecture for 64-bit versions of XP and Windows Server 2003

Processor and memory capabilities of XP x64 Edition and the x64-based versions of Windows 2003

Windows XP x64 information

Windows Server 2003 x64 information

Windows Vista x64 information

Windows Server 2008 x64 information

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 info@reso-net.com.

This was first published in May 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.