As with any computer technology decision, the focus should be placed first and foremost on the application an enterprise intends to run.
If an application is a high-priority, mission-critical one that must be operational 100% of the time -- such as a run-the-business transaction-processing application -- then that app dictates what the
So, the starting point in deciding whether to deploy 64-bit Windows should be to examine the characteristics of that primary application.
What types of apps should be run on 64-bit platforms?
64-bit computing is all about placing a lot more data in memory than 32-bit systems can handle. Placing more data in memory -- rather than having to read it from disk -- results in fewer input/output read/writes to disk subsystems, which are significantly slower than direct access to memory. It also makes data access and processing more efficient. Further, placing more data in memory also reduces database management overhead.
Applications that reap the most benefit by moving to 64-bit environments are those that involve a lot of data handling. Think of it this way: if a whole database can be placed into memory and processed without having to be read from or written to disk, then great processing efficiencies result. At the top of the list of applications that benefit from 64-bit computing are data-intensive applications such as decision support, high-performance computing applications such as drug discovery, mechanical computer-aided engineering (MCAE) and electronic design automation (EDA). Also, several business applications, such as enterprise resource planning (ERP), customer relationship management (CRM) and supply chain management (SCM) often use very large databases -- and are strong candidates for 64-bit platforms.
Contrasting 32-bit and 64-bit computing
In the 32-bit world, up to 4 GB of data can be placed in memory. With 64-bit systems, the amount of data that can be placed into main memory -- "very large memory," or VLM -- can reach into the exabyte range. Figure 1 compares 32-bit and 64-bit memory capacity characteristics as well as describes some of the application areas best suited for each architecture.
When should an enterprise adopt 64-bit Windows platforms?
Again, the answer to this question begins with application analysis. The world of applications consists of two types: packaged and custom.
Packaged -- From a packaged application perspective, there are still relatively few applications that can be found on 64-bit Windows compared to the application bases that can be found on Unix systems such as IBM's 64-bit POWER-based pSeries and Sun Microsystems' UltraSPARC-based platforms. By some estimates, there are between 600 and 1,000 64-bit packaged Windows applications that run on Intel's Itanium-class 64-bit processors. Compare that to the 15,000 64-bit applications that run on the pSeries and the 12,000 that run on UltraSPARC servers. So, if the packaged application you desire runs on 64-bit Windows, and if your application can benefit from exploiting data in very large memory, an enterprise should consider adopting Windows 64-bit platforms.
Custom -- From the perspective of custom applications -- those written by an enterprise to meet specific, unique requirements such as drug discovery or complex financial derivations -- the answer to the question is: "Why not now?" 64-bit versions of Windows for Intel Itanium and AMD Opteron exist today, and hundreds of custom applications have already been written that use these architectures. A word of caution though: Make sure that the device drivers have been written to support the storage and network devices that your enterprise plans to use before purchasing 64-bit Windows.
Both AMD and Intel offer 32-/64-bit combo processors, which are those capable of running both 32-bit and 64-bit application workloads. In addition, Intel's Itanium 64-bit processor -- a microprocessor designed specifically to handle 64-bit workloads -- has 32-bit extensions that allow 32-bit applications to be run in and execution layer within the Itanium environment.
So, which architectures/products should an enterprise adopt when moving to 64-bit processing? For those enterprises that still need to run numerous 32-bit applications, but have some applications that would benefit from 64-bit power, AMD Opteron microprocessors or Intel's new Xeon microprocessors -- code-named "Nocona" -- make excellent choices. AMD's Opteron has an integrated memory controller to help manage memory and increase performance, and its "HyperTransport" fabric switches help move data quickly between memory and I/O subsystems. Meanwhile, Intel's Nocona Xeons have implemented faster switching with PCI express and offer access to very large memory configurations. However, the official release data for a Windows operating environment that supports combo environments has slipped to mid-2005.
Intel's Itanium-class 64-bit microprocessor was built to compete with RISC-based microprocessors from IBM and Sun -- 32-bit computing was an afterthought. But due to customer demand to handle legacy applications, Intel last year released a 32-bit extension layer for Itanium. Although an enterprise can run 32-bit applications on Itanium, initial feedback on the 32-bit extension layer is that it does not exploit Itanium's performance, meaning that users who move 32-bit applications from a Xeon-class processor to an Itanium-class processor should expect little in the way of performance gain.
The answer to the question about when to adopt 64-bit Windows is highly dependent on the application workload. If an enterprise has 32-bit applications that are constantly running out of memory -- or that would benefit from having access to large amounts of data stored directly in closely resident memory -- 64-bit computing should be considered.
As for when to move to Windows on 64-bit systems, consider:
64-bit Windows is ready to run custom applications today. If you want to run packaged applications, check to be sure that your packaged application runs on 64-bit Windows environments before purchasing a 64-bit Windows platform. Also, be sure that native device drivers have been written for unique storage or network devices that your organization uses.