Author—Microsoft Windows Server 2003 Administrator’s Companion (MS Press, 2003)
This paper describes the limitations of the existing 32-bit architecture and the benefits of the x64 architecture running on Microsoft® Windows Server™ 2003 x64 Editions and Microsoft Windows® XP Professional x64 Edition. Areas of benefit of the x64 architecture are described, including memory address space, performance, security, and compatibility.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Microsoft, Visual Studio, Windows Server 2003, and Windows XP Professional x64 Edition are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
Contributors and Acknowledgements 1
Related Links 12
Contributors and Acknowledgements
Clyde Rodriguez, Microsoft
Brad Waters, Microsoft
John Borozan, Microsoft
Jay Kenny, Microsoft
Brian Marr, Microsoft
Samer Arafeh, Microsoft
Forrest Foltz, Microsoft
Ron Kuper, Cakewalk
Margaret Lewis, AMD
Jim Fister, Intel
Paul Barr, Intel
Elsa Rosenberg, StudioB
Joan Roberts, StudioB
David Talbot, StudioB
The limitations of 32-bit operating systems in an increasingly complex computing world have become significantly constraining. Microsoft’s first 64-bit server operating system—Windows Server 2003 for Itanium-based systems—was designed to remove these constraints for the most demanding database and line-of-business (LOB) applications. The limitations of 32-bit architecture are felt across diverse workloads, increasing the need to bring 64-bit computing to the mainstream.
The broad availability of “x64” processors—the latest processors from AMD and Intel that include 64-bit extensions to the x86 instruction set—has driven the move to mainstream 64-bit computing. With the release of Windows Server 2003 x64 Editions and Windows XP Professional x64 Edition, customers now have industry-standard platforms that combine the power of 64-bit processing with the largest base of applications in the industry.
In this paper, we will look at the foundation for pervasive 64-bit computing, including the performance and security advantages that will let customers do more, faster and safer, than previously possible, while maintaining excellent compatibility with existing 32-bit applications to ease the transition. The following are the key benefits of Windows x64 Editions that we will highlight:
Memory—Support for vastly greater physical memory and virtual memory space enables new scenarios not possible before.
Performance—Improvements in memory management, expanded registers, and I/O subsystems provide substantial performance improvements.
Security—New features in x64 processors enable better protection from malicious code.
Compatibility—The unprecedented compatibility of x64 processors with existing 32-bit applications will enable a controlled transition to 64-bit computing.
Availability and Value
Major vendors AMD and Intel offer a broad range of x64 processors, and both OEMs and system builders are shipping x64 systems that range from enthusiast desktop and laptop machines all the way up to 4-way multiprocessor server machines. With the release of the x64 Editions of Windows, 64-bit is ready to become the mainstream of computing.
By the end of 2005, virtually all new server class machines shipping will be 64-bit. Adoption at the general consumer level will be slower, but the majority of new PCs and workstations will be 64-bit by the end of 2006.
General (lot. generalis - umumiy, bosh) - qurolli kuchlardagi harbiy unvon (daraja). Dastlab, 16-a.da Fransiyada joriy qilingan. Rossiyada 17-a.ning 2-yarmidan maʼlum. Oʻzbekiston qurolli kuchlarida G.
The current price of x86 and x64 processor server class machines is essentially identical, making the choice of an x64-capable processor the clear preference, even for those companies that expect to run 32-bit versions of Windows Server.
Enthusiast- and workstation-level machines and processors are also essentially identically priced for both x64 and x86 architectures, making x64 the smart choice for this end of the consumer space. Lower end consumer x86 processors and computers are still significantly cheaper than x64 machines and will continue to be the mainstream choice for the most cost-conscious consumers. As the price differential at this end of the market drops in the next year, we will see significant uptake of x64 even in the broad consumer space.
The most obvious and often mentioned benefit to 64-bit computing is the vastly greater memory addressing space available. Table 1 shows the differences.
General Memory Limits
Total virtual address space (based on a single process)
Virtual address space per 32-bit process
2 GB (3 GB if system
is booted with /3GB switch)
4 GB if compiled with /LARGEADDRESSAWARE (2 GB otherwise)
Table 1. Memory and Address Comparison of 32-Bit and 64-Bit Windows
Moving to a 64-bit architecture changes the amount of virtual memory that can be directly addressed from 4 GB to 16 terabytes (TB). This 16 TB is, like the 4 GB of 32-bit Windows, divided evenly between user mode processes and kernel mode. Native 64-bit applications have 8 TB of available virtual memory address space.
Beyond virtual memory address space, however, is the very real increase in actual physical memory that is supported under the x64 Editions of Windows.
32 Bit Pain Point
The 32-bit versions of Windows use a flat, 32-bit virtual address space, limiting the amount of virtual memory that can be addressed directly to 4 GB (232). By default, this 4 GB is divided into two equal buckets: 2 GB that can be addressed by a process, and 2 GB that is addressable by the operating system and shared across all processes. These buckets can be reconfigured to give 3 GB to an application by using the boot time /3GB switch, thus limiting the operating system to only 1 GB. This requires that an application be compiled to take advantage of the extra space. Squeezing the operating system into only 1 GB is a significant constraint, and this will not be an improvement for all workloads or programs.
It is possible to use additional physical memory in Windows Server 2003 by taking advantage of the Physical Address Extensions (PAEs) of current x86 processors. The use of PAE, however, imposes a significant overhead and requires programmers to use the Address Windows Extensions (AWE) application programming interface (API) to take advantage of the memory. Total physical memory available using PAE is 32 GB for Windows Server 2003, Enterprise Edition, and 64 GB for Windows Server 2003, Datacenter Edition. It is important to note, however, that even using PAE, the total virtual memory address space does not change. It is still limited to 4 GB.
As databases and applications have grown increasingly complex, and even ordinary users have literally gigabytes of digital media on their PCs and access to sophisticated digital content authoring tools, the limitation of 2 GB of virtual memory address space has become a major bottleneck. Using the /3GB switch can help for some scenarios, but it forces the Windows kernel to operate in only 1 GB of virtual address space. This space is shared by the system PTE, page pool, non-paged pool, and system cache. This can be a major limitation as disks get larger because it limits the address space available to the Cache Manager or for video-intensive applications.
Windows x64 Editions can address a full 16 TB of virtual memory by using a flat addressing model. This 16 TB is divided up into equal buckets of 8 TB of virtual address space for applications and 8 TB for the operating system.
Note: The current x64 Editions of Windows actually only use 40 bits for addressing memory, yielding an address space of 240, or 16 TB. The theoretical maximum of a full 64-bits of address space is 264, or 16 exabytes (1.6x1019).
An important consideration in the short term is that even 32-bit applications will benefit from increased virtual memory address space when running in Windows x64 Editions. Applications that are compiled with /LARGEADDRESSAWARE, as would be required to take advantage of the /3GB switch in 32-bit Windows, will automatically be able to address 4 GB of virtual memory without any boot time switches or changes to x64 Windows. Plus, of course, the operating system does not have to share that 4 GB of space, so it is not constrained at all.
The following is an example of a large 32-bit application benefiting from the move to Windows Server 2003 x64 Edition. A multinational ASP.NET website on Microsoft.com was experiencing churning and restarting of the worker process running 32-bit Windows. Average worker process uptimes across the international portion of the application pool were less than an hour, and at peak times often got as low as every 5 minutes, which is clearly unacceptable. By moving the application to Windows Server 2003 x64 Edition, with no other changes to the application, the worker process was able to stay up comfortably for weeks at a time, eliminating the worker process recycling.
A key to the success for the Microsoft group was the ability to run its application in Windows on Windows 64 (WOW64) without any compatibility issues and with no required porting. They were able to simply plug in an x64 server and go.
Another group at Microsoft, using Windows Server 2003 and Microsoft SQL Server™ 2000 to run a large price-modeling application, was able to make a dramatic improvement in a key historical query by moving to x64. The application, which had been running on a dual processor, 32-bit, server was moved to a new 4-way, x64 server with 32 GB of RAM running Windows Server 2003 x64 Edition and a beta x64 version of SQL Server 2005. The historical query, which had taken 8 hours to finish on 32-bit Windows and SQL Server, now finishes in less than 5 minutes. The most important factor affecting the dramatic change was the increase in RAM and virtual memory address space.
An example of a workstation application that demonstrates the advantages of the additional memory and address space in x64 Windows is a customer who uses Computer-Aided Design (CAD) to design and model an engine. The fully rendered 3-D view is nearly 10 GB and takes more than an hour to load, but it can only be effectively worked on in a wire frame view. By moving to Windows XP Professional x64 Edition, the customer is able to load and work on the engine in a fully rendered view and see the results of changes in real-time.
The single biggest performance benefit from the move to 64-bit architecture is the increase in both virtual memory address space and the amount of physical memory that is supported. As detailed in the Windows Server 2003 x64 Editions Deployment Scenarios white paper, the increase in available memory address space and physical memory can make a dramatic improvement in the performance of applications. However, memory address space is only one factor affecting the overall performance of an application, and in many cases is not the limiting factor. Even applications that are not memory-constrained can gain a significant benefit from other efficiencies in the x64 architecture.
A major area of improved efficiency in the x64 architecture is the increased number of registers available. All 32-bit x86 processors are limited to eight 32-bit general-purpose registers, eight floating-point registers, and eight SSE/SSE2 registers. SSE is short for Streaming Single Instruction-Stream, Multiple Data-Stream (SIMD) Extensions, and SSE2 is short for Streaming SIMD Extensions 2.
The x64 architecture uses twice as many general-purpose registers, each a full 64-bits wide, and doubles the number of 128-bit wide SSE/SSE2 registers to 16.
Another performance improvement with the x64 architecture is the gain in overall I/O efficiency and throughput. With support for greater physical memory and memory address space, caches can be substantially larger than in 32-bit Windows, enabling the Windows x64 Editions to fully utilize the improved I/O hardware available, such as PCI Express and PCI-X 266, to improve overall I/O performance. The larger address space allows more I/O to be in progress simultaneously. Even 32-bit applications can benefit from this improvement, especially those that needed to use the /3GB switch. When using the /3GB switch, Windows is forced into a constrained address space, limiting the amount of non-paged pool available. This can cause non-paged pool to be exhausted when there are several I/O requests outstanding.
32-bit Pain Point
Registers are fast, local slots inside a processor in which applications can store values that will be needed shortly. Data stored in registers is available for reuse at full processor speeds and is faster than even cached data in on-chip cache. The x86 architecture, with only eight general-purpose registers, is significantly register-poor as compared to Reduced Instruction Set Computing (RISC) processors. Additionally, the x87 floating-point architecture is stack-oriented: Every floating-point arithmetic instruction requires at least one of the operands to be on top of the stack, leading to significant inefficiencies and relatively poor floating-point performance.
The additional (and wider) general-purpose registers of the x64 architecture allow for significant gains in compiler efficiency and overall application speed. With more registers, there is less need to write out persistent data to memory, only to have to read it back a few instructions later.
Another gain with the additional and wider registers is faster function calls. Up to four arguments can be passed in registers to a function, a big improvement over the x86 approach of pushing and popping arguments onto the stack for every floating-point operation.
When running 32-bit applications, floating-point operations will use the floating point registers and the standard x86 conventions. But when running a native 64-bit application, floating point operations use the SSE2 registers.
Cakewalk's Chief Technical Officer Ron Kuper discovered the benefits of moving to x64 when Cakewalk decided to try a test build of its flagship SONAR 4 Producer Edition, a Digital Audio Workstation (DAW) application on a pre-release version of Windows XP Professional x64 Edition. Using a pre-release version of Microsoft Visual Studio® 2005, Cakewalk created an x64 version of SONAR 4. As Kuper explained, “When we got the initial benchmarking results, we thought there was something wrong. We hadn’t expected to see a significant difference in performance, but we saw from 20-30% performance improvement.” Kuper pointed out that not every test they ran showed a significant performance improvement over the 32-bit version of SONAR. A few were essentially the same, but the vast majority of scenarios did show a dramatic gain.
Kuper went on to point out that Cakewalk really had not done much tweaking of the application at this point to take full advantage of the x64 architecture. But when the company looked at what was happening, it realized that the additional registers of the x64 platform were enabling significantly faster computations. A digital equalizer, for example, uses a processing element known as a biquad. A biquad is small code fragment that manipulates eight numeric values in a series of additions and multiplications, so even a single biquad calculation will use all the available registers of an x86 processor. Because most equalizers use multiple biquads, either for stereo data or additional filtering, data will have to be fetched from and written to RAM, which is a major slowdown. Another advantage of x64 floating-point calculations is that they use SSE/SSE2 registers, which allows the Digital Signal Processing (DSP) code to process stereo streams in parallel.
The one area in which Cakewalk found a significant advantage with the additional memory support in Windows XP Professional x64 Edition was in sampling and loop processing. Because of the additional RAM support, the company was able to load far more loops in RAM, allowing for real-time pitch shifting and time-compression expansion. Users can also load much larger sample sets into RAM for additional performance improvements for projects with large amounts of sampling.
An important new feature in the x64 processor architecture is the Data Execution Protection (DEP) bit that controls which areas of memory can be used to execute code. While AMD and Intel have different names and slightly different implementations for this feature, the result is an enhanced layer of hardware protection against some of the most destructive worms and exploits of the past several years.
A buffer overflow occurs when a data buffer is stuffed with more data than it is designed to handle. (I use buffer overflow as a generic term for exploits that load executable code into areas that are supposed to only contain data, then jump program execution into that code by overloading heaps, stacks, and other memory pools.) For example, if your email client is designed to handle attachments with a maximum of 255-character filenames and you receive a message that has a filename with 256 characters, a buffer overflow can occur. When this happens, adjacent memory space gets overwritten and malicious code can end up being executed with the privileges associated with the original program. The infamous MSBlaster worm was this type of exploit.
Data Execution Protection
Beginning with Windows XP Service Pack 2 (SP2) and continuing with Windows Server 2003 SP1 and Windows XP Professional x64 Edition, Windows uses DEP to prevent malicious code from being able to execute, even when a buffer overrun occurs. Even without a processor that supports DEP in hardware, Windows is able to detect code running from memory locations that it should not.
With the introduction of x64 processors, both AMD and Intel added hardware support for DEP. The processor sets the No Execute bit (for AMD processors) or the Execute Disable bit (for Intel processors) on all entries in the memory address table that are for data only and should not be executed. If code attempts to execute from within an area of memory marked as data only, Windows will raise a status access violation exception and terminate the process.
While DEP is by no means a substitute for a well-designed and implemented anti-virus and anti-malware deployment in any organization, it is an important additional layer of protection that would have prevented the spread of the MSBlaster worm had it been widely implemented at the time.
All 64-bit versions of Windows support the hardware DEP features of the 64-bit processors, enabling users, developers, and administrators the ability to globally or selectively protect against this kind of exploit. By default, DEP is enabled on Windows XP Professional x64 Edition and Windows Server 2003 x64 Editions for essential Windows programs and services only.
The x64 versions of Windows also support Microsoft’s PatchGuard technology that prevents non-Microsoft originated programs from patching the Windows kernel. This technology, available only on Windows x64 Editions, prevents kernel mode drivers from extending or replacing kernel services including system service dispatch tables, the interrupt descriptor table (IDT), and the global descriptor table (GDT). Third-party software is also prevented from allocating kernel stacks or patching any part of the kernel.
The x64 Editions of Windows are essentially feature comparable with the 32-bit versions. They are able to execute both native 64-bit programs and 32-bit programs efficiently and with high performance, bringing an unprecedented level of compatibility to 64-bit computing.
Applications that are written to run natively in x64 Editions of Windows will have full access to the very large virtual memory address space (16 TB) and the up to 1 TB of physical memory supported by Windows Server 2003 x64 Editions and 128 MB of physical memory on Windows XP Professional x64 Edition.
All 32-bit applications run in the WOW64 subsystem, with access to 4 GB of virtual memory address space. WOW64 provides a high-performance, highly compatible, and isolated environment for 32-bit applications.
An important feature of the x64 Editions of Windows is the binary compatibility between the AMD64 and 64-bit Xeon and Pentium processors that support the x64 extensions. Windows uses the same binary whether the underlying processor is an AMD or an Intel processor, and applications written for x64 use a single binary as well.
Windows x64 builds on the existing 32-bit Windows APIs and supports the same coding practices as 32-bit Windows. A 32-bit application can determine whether it is running on WOW64 by calling the IsWow64Process function. A 32-bit application that is compiled with the /LARGEADDRESSAWARE switch will have access to 4 GB of virtual memory address space.
The WOW64 subsystem provides a high-performance 32-bit Windows environment that enables x64 Windows to take full advantage of the more than 10,000 existing 32-bit Windows applications available today. Because of the underlying hardware compatibility of the x64 architecture, 32-bit applications are able to run at full speed in the WOW64 subsystem. Many applications will actually run faster in WOW64 than they would run in 32-bit Windows because of the larger available memory address space and the greater efficiencies of the x64 processor architecture.
WOW64 isolates 32-bit applications from 64-bit applications, but it provides for interoperability and data exchange across the boundary through COM and remote procedure call (RPC) and through transparent cut and paste. WOW64 runs 32-bit applications seamlessly while preventing file and registry collisions between 32-bit and 64-bit versions of an application.
The .NET Framework is supported under WOW64 as a native 32-bit application.
WOW64 supports Windows graphical applications, console applications, and services. It does not support 16-bit applications, with the exception of some 16-bit installers in which it can seamlessly substitute the 32-bit version.
An important WOW64 limitation is that 32-bit applications cannot load 64-bit DLLs and 64-bit applications cannot load 32-bit DLLs. This means that 32-bit ActiveX controls, for example, cannot be run in the 64-bit version of Microsoft Internet Explorer (IE) and that 32-bit DLLs that provide context-sensitive menu extensions to Windows Explorer will not work and will need to be rewritten to run natively in x64. Window XP Professional x64 Edition includes the 32-bit version of IE 6.0 and uses it by default to provide a seamless and transparent experience when browsing the Internet.
Legacy support for older operating systems and applications is not available in 64-bit Windows. This means that 16-bit applications and DOS applications are not supported and will not run in x64 Editions of Windows. The lone exception to this is certain 16-bit installers used by 32-bit applications for which Windows is able to seamlessly substitute the 32-bit version of the installer.
While DOS applications are not supported, 32-bit and 64-bit console applications are supported.
All kernel mode drivers must be 64-bit. No support is available for 32-bit drivers, and applications that depend on a 32-bit kernel mode driver will not run, even in the WOW64 subsystem. Two notable examples of this are Microsoft Exchange Server and POSIX applications that use the Interix subsystem.
Legacy networking protocols such as NetBEUI, Data Link Control (DLC), and AppleTalk are not supported or available for the x64 Editions of Windows.
Windows Server 2003 x64 Editions and Windows XP Professional x64 Edition provide a highly compatible, high-performance, and secure computing experience that takes advantage of the much larger memory address space and improved security and efficiency of the x64 processors shipping from AMD and Intel. The x64 Editions of Windows support 16 TB of virtual memory address space and from 32 GB to 1 TB of physical RAM. The x64 architecture maintains support for the existing x86 registers while increasing the number and size of the available registers to improve the overall efficiency and performance of applications. The improved security built into the x64 architecture, along with the DEP of Windows, provides an additional layer of security against malicious software. The high-performance and compatibility of the WOW64 subsystem eases the transition from 32-bit Windows to 64-bit Windows by enabling high-performance access to the existing base of more than 10,000 32-bit Windows applications during the transition to 64-bit versions. With the release of the x64 Editions of Windows, 64-bit computing is poised to become the mainstream of personal and corporate computing.
See the following resources for further information:
Windows Server 2003 x64 Editions Deployment Scenarios at http://www.microsoft.com/windowsserver2003/64bit/x64/deploy.mspx
The Joy of 64-Bit Fortran at http://www.devx.com/amd/Article/17999
64-bit computing in theory and practice at http://techreport.com/reviews/2005q1/64-bits/index.x?pg=1