Why you should be thinking 64 bits instead of 32

Back in the late 1980's, when users of PC-class systems (desktops and servers) were faced with changing from Intel's16-bit 80286-based systems to the company's 32-bit 80386 class of processors, most were eager to make the switch. At the very least, users were anticipating a boost in performance. Many others were looking forward to the advanced multitasking and graphical capabilities of OS/2, which at the time was still a joint effort between Microsoft and IBM.

I remember how excited I was-- as an IT manager in those days--while unboxing my company's first 386-based system. After seeing how fast this IBM Model 80 compiled some 16-bit applications I was developing, and after amassing several volumes of data to back up the decision to change the corporate operating system standard to OS/2, I wrote a memo to the CIO. I said that OS/2 was the OS of the future and that the 386 platform was the architecture to run it on. I recommended that we buy nothing but 32-bit class systems as we prepared for an eventual migration to OS/2. The 32-bit decision was a good one. We'll forget about OS/2.

Next, consider my 64-bit prognostications.

I remember my colleagues and I engaging in some 32-bit crystal-ball analysis that involved the next step-- 64-bit. We knew it was next. We knew it far away. We also had expectations of the breakthrough it would represent when the day finally came. We probably sized it up as the 16-to-32 switch on steroids. We figured it would command the same urge to upgrade.

I guess one out of three predictions ain't bad.

So, here we are in 2003. Sixty-four-bit processors are here and, for the most part, the enthusiasm for switching from 32-bit systems is nothing to write home about. Not only is the demand in the PC world for 32-bit support far outstripping that of 64-bit support, but the roadmap for 32-bit support, particularly from Intel, has far from ended. Intel's current Gallatin family of 32-bit Xeon processors, which clocks in at 2.0 GHz, was introduced only last year. Intel plans to bump Xeon's clock speed to 2.8 GHz later this year and expects to double its level 3 cache size from 2MB to 4MB next year.

In AMD's case, with its Opteron processor, which is capable of running in either an Intel compatible 32-bit mode or an AMD proprietary 64-bit mode, the roadmap has simply merged. AMD's support for 32-bit computing is far from over.

As we face what looks to be a protracted transition from old to new, I've started to wonder: Where are the cross-over points? At what point does going the 64-bit route, based on a total cost of ownership or performance basis (or both), become equal to or better than going the 32-bit route? I have no doubt that the day will come when all 32-bit systems have been decommissioned, and 64-bit architectures will prevail, as will rumors and roadmaps of the 128-bit generation. You will migrate. It's just a question of when.

With various 64-bit architectures underway, it's a question you should be asking yourself each time you prepare to invest in another 32-bit system-- particularly the multiprocessing flavors of servers.

Instead of making another prediction, I decided to ask the folks at Intel and AMD.

I learned that there is no one-size-fits all cross-over point. For example, you can't say that, across the board, a system with four 64-bit processors at some clock speed and with some L3 cache (and other variables filled in) will match or beat the performance of a system with eight 32-bit processors. Points like that do exist, but it's more complicated than that.

For starters, performance probably won't matter if the application you want to run isn't available for the 64-bit brew (combination of operating system and processor) you choose. Whereas, Intel and AMD are engaged in the same ecosystem on the 32-bit front, no such compatibility exists on the 64-bit front where the two companies must go up against existing 64-bit brews from companies like Sun, IBM, and Apple, A developer cannot develop an application to run on Intel's 64-bit architecture (IA64) and expect it to run on the 64-bit personality of AMD's Opteron. Likewise, you can't obtain an application that was designed to run on one and expect it to run on the other any more than you could expect it to run on the 64-bit versions of the SPARC or Alpha processors (the latter is slowly being phased out by HP in favor of IA64)..

Not all applications available for all 64-bit architectures
AMD's and Intel's introduction of two distinctly different 64-bit architectures spawned two new 64-bit ecosystems at a time when other 64-bit ecosystems already existed. In these not-so-great economic times, developers wanting to capture the most of the post-IA32 market have been forced to choose between the two, or at the very least prioritize one over the other. Other developers aren't even bothering with the post-IA32 market. The result is that not all applications are available for all 64-bit architectures. That's where you'll need to check with your software vendor to see if there's a 64-bit roadmap and what processor support is on it.

The reason I said that performance "probably" won't matter is that there are actually some alternatives if you desperately want to run your 32-bit code on a 64-bit brew. Intel, for example, offers a software-based translation shim called the IA32 Execution Layer that allows 32-bit code to run on an IA64-based platform like Itanium 2. However, there is currently no cost effective amount of brute strength--in terms of numbers of IA64-based processors--that will make a 32-bit application run as fast or faster than it would natively on one of the recent and significantly cheaper 32-bit processors.

According to Intel enterprise platform marketing director Jason Waxman, "The IA32 Execution Layer comes into play when you want other stuff like antivirus or back up applications that aren't performance-intensive to run side-by-side with the 64-bit applications they support. It's good for people who don't want to bother setting up a separate system and the application is not performance critical. It doesn't factor too much into the cross-over."

When asked what sort of performance hit a 32-bit application should be expected to take when running on the IA32 Execution Layer, Waxman said it was inappropriate to look at it from that point of view but offered one data point for those interested: "The execution layer performs like a 1.6 GHz Xeon processor [Editor's note: a member of the Foster family, which preceded Gallatin]. So, the only people that might notice a boost are those who are consolidating or switching from a three-year-old, 900 MHz system."

AMD claims that scenarios do exist where someone who wants to run legacy 32-bit code on top of the Opteron's 64-bit personality might see a performance boost. According to AMD worldwide enterprise business development director Kevin Knox, "We're seeing customers getting a significant performance boost when they run a legacy 32-bit Linux application on SuSE's distribution of an Opteron-compatible 64-bit version of Linux." Within that distribution of Linux, SuSE has included technology that's a rough equivalent of the IA32 Execution Layer. While no benchmarks are available, my advice to those interested in investigating this interesting cross-over angle in the Opteron ecosystem is to get your solution providers to do some benchmarking for you.

Intel's Waxman and AMD's Knox agree that database-bound applications show the most promise for revealing your cross-over point (it will be different for everybody). The reason for this is that, along with 64-bit instructions, 64-bit processors also get you 64 bits of addressable memory space. That's 232 times more RAM in which to store data than what database servers could squeeze out of a 32-bit-based system. The more data that can be cached in memory, the fewer times a database application has to wait while the data is fetched from a disk, and the faster everything goes.

In cases like these, said both Waxman and Knox, something interesting happens. Not only might you get equal or better performance out of a four-processor 64-bit system than you would out of an eight processor 32-bit setup (the 64-bit setup would require more memory), but the reduced number of processors will also translate into a reduction of the annual licensing fees paid to database vendors such as Oracle and Microsoft. For example, the licensing fees for the standard and enterprise editions of the Oracle 9i application server are $15,000 and $40,000 per processor, respectively, regardless of whether the processor is 32 bit or 64 bit. Microsoft's SQL Server is $20,000 per processor. For just one server, the savings on licensing fees can range from $60,000 to $160,000 per year, which for many is probably enough to recoup a 64-bit system investment in a very short period of time.

Both Waxman and Knox said there are other scenarios to consider. Waxman claimed Itanium to be an ideal consolidation platform, especially after this week's introduction of the Deerfield family of Itanium 2 processors. The low-power design of the Deerfield chip is designed to help IT shops achieve higher densities of 64-bit rack-mounted systems. The new chip also offers a significantly better price point than previous Itanium 2 offerings. Waxman said he's already heard of customers being quoted $7,000 to $10,000 for two-processor systems.

Knox also played the consolidation card, revealing that AMD is currently in discussion with VMWare. Theoretically, if VMWare ends up supporting Opteron, the result could be a situation where IA32-compatible and AMD-64 bit-compatible virtual machines can be run on the same system-- an interesting possibility for those who are consolidating.

Have you given the cross-over point any consideration? What factors might motivate you to make the switch. Share your thoughts with your fellow readers using TalkBack.. Or write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.