The Mary Kay Supply Chain standard application platform is shifting to deploy on Dell PowerEdge 1950 servers with Dual Core Intel Xenon 3.0 Ghz processors and 4GB of RAM. The Intel Xenon chipset provides the flexibility of running a true 64-Bit operating system, or a 32-Bit operating system but without the hardware emulation layer as in the Intel Itanium chipset.
While the current standard application server OS image is Windows Server 2003 SP1 x86, we could re-image the box with Windows Server 2003 Sp1 x64 and reap the true benefits of the x64 platform.
Since we have this option available, why aren't we taking advantage of it? I hope to explain this, and at the same time answer the questions that are buzzing around in our department:
Why would anyone target the x64 platform?
Why would anyone NOT target the x64 platform?
64-Bit Platform
Two big advantages of why you would target a 64-Bit platform jump to the forefront immediately: Memory Addressing and Faster CPU Processing.
Memory Addressing
Under a 32-bit platform, special considerations are necessary if an applications memory requirements exceed 2GB. The 64-Bit platform expands the process memory barrier to 16TB. Below is a table from Matt Pietrek's MSDN Magazine article.
| 32-Bit Models | 64-Bit Models | |
|---|---|---|
| Total virtual address space (based on a single process) | 4GB | 16TB |
| Virtual address space per 32-bit process | 2GB (3GB if system is booted with /3GB switch) | 4GB if compiled with /LARGEADDRESSAWARE (2GB otherwise) |
| Virtual address space per 64-bit process | Not applicable | 8TB |
| Paged pool | 470MB | 128GB |
| Non-paged pool | 256MB | 128GB |
| System Page Table Entry (PTE) | 660MB to 900MB | 128GB |
Even, a 32-Bit process running under WOW64 on x64 has access to 4GB of memory!
Faster CPU Processing for Compute Intensive Applications
Scientific, Engineering and Financial, normally considered 'computensive' applications, will see the biggest benefit from improved CPU calculations. However, 32-Bit applications can run faster on 64-Bit hardware, primarily due to the elimination of the front side bus architecture allowing for, at least on AMD x64 platforms. Intel based x64 platforms do not have the hardware integration currently offered by AMD.
.NET Development Considerations
When building applications, be aware of the target platform compiler switch (/platform:MSIL,x64,x86,IA64). MSIL is considered 'Any CPU' and is most likely the target platform of choice. If your application contains p/Invoke, or COM interop, then you may specifically want to target x86 as a requirement, according to your dependency requirements.
There is a 64-Bit version of the .NET 2.0 runtime. This version of the runtime (or greater) will need to be available if a .NET is compiled as /platform:MSIL and it is to be just in time (JIT) compiled into 64-Bit code at runtime on a 64-bit platform.
.NET CLR 1.0/1.1 applications will always run under WOW64 when deployed to a 64-Bit platform as if compiled with the /platform:x86 switch.
Registry Redirector
Maintains two HKEY_LOCAL_MACHINE\Software registry trees for both 32-bit and 64-bit applications. It will also synchronize changes between the two, e.g. file type associations and COM interprocess communication (IPC).
File System Redirector
Handles requests to direct to appropriate file storage locations. Much like the Registry Redirectory, the File System Redirector allows for side by side storage of 64-Bit and 32-Bit application modules. Note the misnomer! On a 64-Bit system, 64-Bit versions of the files will be found at the normal locations.
64-Bit
%SYSTEMROOT%\Windows\System32
%SYSTEMROOT%\Program Files
32-Bit
%SYSTEMROOT%\Windows\SysWOW64
%SYSTEMROOT%\Program Files (x86)
Finally, why would you NOT want to target 64-Bit immediately?
First, while there are 64-Bit versions of the servers we work with daily (BizTalk, Reporting Services), there are still many 'gotchas' you'll encounter when developing under 64-Bit. Mainly around the Registry and File redirectors, but there are likely others in our tool stack which are unknown. These unknowns will cause an unnecessary loss of developer productivity that we can't afford right now.
After our current implementation efforts around the China roll out have firmly stabilized we will re-evaluate our development stack and target platforms.
Second, our application 'profiles', if you will, typically do not require access to greater memory. I say typically, because under normal conditions memory has not been a constraint (e.g. memory bound). The two times, that I can recall, that memory has been an issue has been due to the implementation (e.g. bugs). Once these have been corrected, memory hasn't been an issue.
Once caveat, and an area to keep an eye on, is in our Reporting Services implementation. As our reporting needs grow, its quite possible that deploying Reporting Services onto x64 will allow us to scale up (adding additional memory), without having to scale out (adding additional servers).
Supply Chain Database Platform
Everything to this point has been discussing 64-Bit and Mary Kay's use of it on the application tier. Our strategy for the data tier is different. We are already completely 64-Bit, running on Dell PowerEdge 2950's hardware and Sql Server 2005 x64. Results collected from our database team is that we are seeing significant improvements in performance vs. our Sql 2000 implementation.
Sources
MSDN, The 64-Bit .NET Framework
MSDN Magazine, Matt Pietrek, 64-Bit Primer: Everything You Need to Know to Start Programming x64 Systems
devx.com, WOWing Your 32-Bit Applications with 64-Bit Windows - part 1
devx.com, WOWing Your 32-Bit Applications with 64-Bit Windows - part 2
ADM Advantage, 64-Bit Insider: Alignment in 64-Bit Processors - part 1
Josh Williams, "Adventures in the CLR" blog
