Porting Chains: 64-bit Intel® Xeon® Processor to Intel® Itanium® Processor

by Alan Zeichick


Introduction

Read the tale of two migrations: vertically to the Intel® Xeon® processor with Intel® Extended Memory 64 Technology, then horizontally to Intel® Itanium® microarchitecture.

Have you ever wondered why you should migrate to 64-bit-and if so which one? The question can be daunting, particularly when it comes to understanding the pros and cons of Intel's two 64-bit platforms, the Intel® Xeon® processor with Intel® Extended Memory 64 Technology (Intel® EM64T) and the Intel® Itanium® Processor. In this article, I will try to make the differences and migration path clear.

A plan for migrating and upgrading servers from 32-bit platforms to 64 bits might be summarized in two sentences:

  • Migrate vertically from 32-bit x86 up to 64-bit Intel Xeon processors today.
  • Migrate horizontally from those 64-bit Intel Xeon processors over to the Intel Itanium processors tomorrow.

 

Intel EM64T is an extension to the classic 32-bit x86 architecture that provides a bigger address space, new 64-bit and 128-bit math instructions, and new registers to the popular Intel Xeon processor.

While the Intel EM64T brings the capabilities of 64-bit computing to widely deployed hardware, including low-cost, high-performance servers from many top-tier manufacturers (like Dell, HP and IBM), the architecture doesn't have quite the same scalability as purpose-designed 64-bit processors like the Itanium processor series. And thus, a migration from 32-bit Intel Xeon processors to 64-bit Intel Xeon processors could be considered a stepping stone to the Itanium 2 processor series.

It's a stepping stone-but a very important one. To put it simply, the task of migrating Linux* or Windows* applications from today's 32-bit x86 world directly to the 64-bit Itanium processor would be quite difficult to handle in one step, at least for many developers; changing "bitness" and processor architectures all at the same time can be daunting.

By contrast, the migration upward from 32-bit to 64-bit Intel Xeon processors is relatively straightforward, as we'll see below. Further, although any particular application must be either 32-bit or 64-bit in nature, a 64-bit Intel Xeon server with EM64T with a 64-bit operating system, can run both 32-bit and 64-bit apps at full speed without emulation.

Likewise, once all code has been ported to 64 bits, the "sideways" move from the 64-bit Intel Xeon processor to the Itanium processor is also relatively easy for those applications that would benefit from the extra scalability.


64-bit Intel® Xeon® Processor or the Intel® Itanium® Processor

Despite the fact that they are both 64-bit processors, the Intel Itanium processor and 64-bit Intel Xeon processor are quite different processors, with two different sets of performance characteristics. While it goes beyond this article's scope to explore all the technological specifications of these processors in depth, the following table might help to frame the discussion. (Note that "today" refers to the second quarter of 2005.)

Feature 64-bit Intel Xeon Processor Itanium Processor
Virtual Address Space 64-bit (very big) 64-bit (very big)
Physical Address Space 40-bit (big) 50-bit (bigger)
Multiprocessing Generally limited to 8 CPUs Hundreds of CPUs
Branch prediction Very Good Excellent
Parallelism within a Thread No Yes
Memory latency Very Good Excellent
Caches Big Huge
Memory bandwidth Very Good Excellent
Integer Performance Very Good Excellent
Floating Point Performance Very Good Excellent
Number of Native Apps Few (today), many (soon) Many (today)
Number of Cores 1 or 2 (today) more (soon) 1 (today) more (soon)
Number of Dev Tools Few (today), many (soon) Fewer than Xeon
System Manufacturers Few (today), many (soon) Fewer than Xeon
General Price Point Affordable Expensive
Runs 32-bit x86 Instructions At Full Speed (faster) In Emulation (slower)
Porting from 32-bit x86 Easier Harder

 

As you can see, the widely available Intel Xeon processor family tips the scale for affordability and ease of porting and also in scalability through the use of multiple cores. By contrast, Itanium microarchitecture is designed for higher performance, and offers vastly greater scalability for truly high-end data center operations, particular for massive multiprocessing and huge amounts of physical memory. The Itanium processor also has a higher degree of reliability and memory management infrastructure built in.

Under most circumstances, it makes sense to begin porting (or migrating) 32-bit data center applications to the 64-bit EM64T extensions as soon as it is feasible. Many applications, particularly those which can use more than 2GB of memory, will benefit from the increased performance. With the appropriate optimizing compiler, nearly all applications can be made more efficient through use of the extra registers that the extensions provide. When one is doing such a port, it makes sense to do that port with the Itanium in mind, since some applications will further benefit from that migration in the future. (For more information, see Why Migrate to the Intel Itanium-based Platform in the Enterprise?.)

Let's examine the process of porting from 32-bit Intel Xeon to 64-bit Intel Xeon processors. We'll then look at how to move those ported Intel Xeon processor-based applications to the Itanium processor microarchitecture.


Porting from 32-bit Intel Xeon to 64-bit Intel Xeon

One could devise a two-dimensional matrix that shows the porting options. On the x-axis would be operating systems, most commonly Linux and Windows. On the y-axis would be language, including native languages such as Fortran and C/C++ and managed languages like Visual Basic*, C# and Java*. Each box in that matrix requires specific planning. Porting a C++ application on Linux is, in many ways, quite different than porting a C# application running on Windows under the .NET Framework.

Even so, there are common factors that determine the scope and complexity of the project. For example, there's the requirement for a comparable operating system and runtime environment on the target system, as well as support for libraries or other dependencies; these may have to be licensed or built, adding to the cost and timeline for the porting process. As part of the scoping process, the source code will have to be reviewed (either manually or wit h a migration automation tool) to determine what changes will be required, and the complexity and cost of making those changes.

Before any migration can begin, the appropriate tooling, including integrated development environments (IDEs), software development kits (SDKs), compilers and test/QA tools must be acquired, and developers trained on them. Once the project has been sufficiently scoped, and the tools acquired, then the porting process begins. In many ways, the process is linear: The changes to the source code must be made, again either manually or with a migration tool-often by both, with the migration tool doing the "heavy lifting," and then letting a human-led code review handle the tricky parts.

Some of the trickiest challenges in porting native applications-such as those written in C/C++-is handling pointers. In a 32-bit environment, pointers are often hard-coded to treat them as a 32-bit ints or longs. In a 64-bit environment, pointers become 64-bit values. But in 64-bit Windows, ints and longs remain 32 bits in size; in 64-bit Linux, ints stay 32 bits but longs become 64 bits. Fortunately, all 64-bit environments define new polymorphic data types for pointers-and these data types should be used for user-defined functions, instead of hard-coding to ints or longs. Still, rooting out all the 32-bit pointers can be time-consuming and if any are missed, errors might be introduced.

Another complex area regards data sizes, beyond the pointers. Take those 32-bit longs which become 64-bit values under 64-bit Linux; any algorithm that depends on them "rolling over" at 2^32, or which masks values using logical operations, won't work properly. The "bitness" of implicit and explicit data conversions, alignment and padding, memory allocations, socket APIs and device communication can also be problematic. (For more information, see Porting on Intel Extended Memory 64 Technology Platforms.)

Applications that run in a managed runtime will be significantly easier to port. By design, runtime environments like a Java Virtual Machine* (JVM*) or the .NET Common Language Runtime* are "bitless"-a J2SE or Visual Basic application should run without any alterations if you go from 32-bit to 64-bit Windows. But while the managed code itself might not have "bitness" problems, there are still other dependencies that must be addressed, even in Java and .NET. Native libraries and components that work with the managed application may need to be upgraded or replaced with 64-bit equivalents. Database drivers may have to change, as well.

Once the changes have been made and verified through source code review and unit tests, the new challenge is to successfully build the new application. This can be trickier than it seems because in non-trivial cases, the compile and link dependencies will be entirely new. Once you have a successful build that completes with an executable, then the process becomes more familiar: functional testing, performance tuning and finally, deployment. Again, don't underestimate the time required for tuning. The 64-bit versions of Linux and Windows represent new op erating systems and new hardware architectures. Real-time profilers, like the Intel® VTune™ Performance Analyzer, can help identify the hot spots, but ultimately, humans must sign off on the performance of the application and the entire system prior to ultimate deployment.

After the 32-to-64-bit EM64T transition is complete, it becomes time to consider a horizontal port of your most business-critical applications to the 64-bit Itanium processor. As you will see, the porting process is much simpler, because the heavy lifting has already been done.


Porting from 64-bit Intel Xeon processors to 64-bit Itanium processors

If the port from 32-bit Intel Xeon to 64-bit Intel Xeon processors has been done correctly-such as by using polymorphic data types for pointers-then the resulting source code should be inherently more portable than the original 32-bit code. The result should be a situation where it's relatively fast and inexpensive to migrate the code to the same operating system (Linux to Linux, Windows to Windows) running on a different 64-bit processor.

If developers know that the port to Itanium microarchitecture is a possibility, they can ensure that it will be relatively effortless by verifying that there are no Intel Xeon processor-specific dependencies in the 64-bit Intel Xeon application's environment. For example, perhaps the move from 32-bits to 64-bit required a new set of JBDC* or ODBC* database drivers. By verifying that the driver manufacturer offers versions for both Intel Xeon processors and Itanium processors-and that they use similar or identical APIs-that porting work only needs to be performed once.

In fact, if the original 64-bit port was well documented, even the requirement for a fresh code review may not be necessary. The porting process could focus on those few areas where Itanium microarchitecture is different than the 64-bit Intel Xeon processor, such as applications that take advantage of specific extension-set extensions or new registers on the Intel Xeon processor.

A possible trouble spot will be routines written entirely in assembly code, or C/C++ apps with inline assembly. Those may require complete rewriting when moving from the Intel Xeon processor to the entire different instruction set used on the Itanium processor.

Extensive testing and tuning stages may be required for applications ported to the Itanium processor. The chip's performance characteristics are very different from the Intel Xeon processor; the Itanium processor is especially vulnerable to performance hits when data is not aligned properly. The Itanium processor also has much larger and faster caches than the Intel Xeon processor series; this can be a tremendous advantage, but will definitely affect the execution profile.

Therefore, all porting projects for the Itanium processor should budget sufficient time for tuning, particularly for memory and cache utilization. You should also test Itanium processor-based applications on systems with many processors and with extremely large amounts of memory-situations that simply don't occur on Intel Xeonprocessor-based systems. (For more information, see Performance Tuning for the Intel Itanium Architecture, and Cache Coherency in Itanium Processor Software.)

Ultimately, however, the port should be far quicker, and require fewer staff and costs, than the original migration from 32-bit to 64-bit Intel Xeon processor.


The Journey Is The Reward

The vertical migration from 32-bit to 64-bit Intel Xeon processors makes sense immediately. Sixty-four bit servers are readily available, as are the mainstream Linux and Windows operating systems. Many ported to 64-bit for Intel EM64T will immediately benefit from the additional registers, new instructions and larger address space. Also, application ecosystems can be migrated piecemeal, because 32-bit and 64-bit applications can coexist on the same Intel Xeon processor-based server-with no performance penalty for running legacy 32-bit code.

When the time is right, those migrated applications will be well positioned for a second migration, this time horizontally to the Itanium microarchitecture. This port, which makes sense for the most critical applications that need the utmost in processor performance, multiprocessing and large memory scalability, will be relatively easy to perform, assuming that the original 32-to-64-bit port was done correctly and with such a future migration in mind.


About the Author

A former mainframe software developer and systems analyst, Alan Zeichick is principal analyst at Camden Associates, an independent technology research firm focusing on networking, storage, and software development.


For more complete information about compiler optimizations, see our Optimization Notice.
Tags: