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. However, 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 independent software vendors (ISVs) have been straining to keep it together. AMD, not wanting to alienate them, hasn’t made a fuss. ISVs write system software, such as operating systems and virtualisation 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 — which link to I/O — built into the CPU. This HyperTransport bus controllers link to I/O and then creates a web 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, virtualisation and power management.
But no such solution — at least not one of genuine 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, the one hub-routed channel for inter-CPU traffic and a single, shared pool of RAM hobble Intel. 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 technology such as 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 virtualisation solutions land, the ingenuity of virtualisation ISVs will be tested. Intel’s VT and AMD’s Secure Virtual Machine extensions make virtualisation far easier to code and will improve performance on Intel and AMD platforms. What will separate low-rung virtualisation 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 virtualisation. I don’t expect to see “Made for Opteron” stickers on software today. But it’s a discussion ISVs should be having. Give them a few weeks and then start asking about it.