Ahead of the Curve: Optimizing for Opteron

AMD has its hands in a lot of technology areas, and I track and report on all of them. I'm a huge fan of AMD's Athlon FX and X2 client CPUs, Turion notebook CPUs, and Geode ultra-low power technology. But I know the AMD you care most about is the one that will turn your entire server room into a one-rack, one-man operation.

AMD will do it. The whole company is driven to achieve the goal of creating mainframe-grade, high-availability, maximally scalable systems on its affordable x86 technology; this is not new territory for AMD's lead architects and engineers. But they're not knocking off Intel chips. The x86 server platform split has occurred. There is now generic x86, defined by the overlap between Opteron and Intel Core Microarchitecture, and enterprise x86, which is Opteron.

The reality is that the AMD/Intel generic server concept was invalidated the day Opteron shipped, but ISVs have been straining to keep it together. AMD, not wanting to alienate them, hasn't put up a fuss. ISVs write system software, such as operating systems and virtualization solutions, for the far-less-capable Intel x86 server platform, knowing that Opteron will stoop to run it.

That's got to end, now, and IT has to bring about the end of it. The capabilities of the Opteron platform that go unexploited from being handled in software like Intel x86 are disturbing. Just to pick one example, every Opteron has memory controllers on the CPU die; you know that. Opteron also has multiple HyperTransport bus controllers built into the CPU, controllers that link to I/O; more importantly, they create a fabric of Opteron CPUs using dedicated high-speed links. CPUs can map each others' address space, reach into each others' Level 2 cache, and generally chat productively without straining the rest of the system. The potential is limitless in terms of fixed and dynamic partitioning, scheduling, virtualization, and power management.

But no such solution -- no solution of honest enterprise scope -- makes it to first base if it's written for the Intel x86 platform. The shared bus (now two, same problem), the off-board memory controller, one hub-routed channel for inter-CPU traffic and a single shared pool of RAM hobble Intel, and when software assumes that these limitations are present on an Opteron system, they waste potential and cap scalability. AMD took great pains to build smarts into its architecture so that arcane Intel tech like memory segmentation (on a server!) would get invisibly transformed into something more sensible. These smarts account for the impressive performance gains seen when Intel x86 server software is run on Opteron. But I know that the next step in x86 server evolution is to flip those "Opteron = Xeon" bits off in system software.

When hardware-assisted virtualization solutions land, the ingenuity of virtualization ISVs will be tested. Intel's VT and AMD's Secure Virtual Machine extensions make virtualization much, much easier to code and will improve performance on Intel and AMD platforms. What will separate low-rung virtualization ISVs from the innovative is the extent to which they exploit the Opteron platform's unique architectural properties. Here again, the Opteron platform is built for flexible virtualization.

I don't expect to see "Made for Opteron" stickers on software today. But it's a discussion that enterprise ISVs should already be having. Give them a few weeks, and then start asking them about it.

Join the newsletter!

Error: Please check your email address.

More about AMDIntelScalable SystemsSoftware TodaySpeed

Show Comments

Market Place