Ever since last year’s dramatic announcement that AMD would be producing designated stock keeping units (SKUs) of its Opteron server processors with 64-bit ARM technology instead of the x86/x64 architecture it pioneered, questions have centered around what the differences in their two product lines will be, and whether AMD would find itself competing against itself.

Those questions will come to a head this week. Beginning Wednesday at the Software Defined Networking (SDN) and OpenFlow World Congress in Düsseldorf, Germany, AMD will publicly demonstrate similar or identical Network Function Virtualization)  functionality on its “Bald Eagle” Embedded R-Series APU processors (which has already begun sampling) alongside its “Hierofalcon” Embedded R-Series 64-bit ARM systems-on-a-chip, which AMD formally announced a few weeks ago.

Confusing alphabet soup

It’s a confusing alphabet soup, but the two R-Series processors are designed for low-power, high-efficiency processes such as NFV, AMD’s product directors tell DatacenterDynamics. Dilip Ramachandran, the company’s senior director of product marketing, acknowledges that the Opteron will be running at higher frequency with a lower core count to match the 8-core ARM chip.

“Nevertheless, we are able to demonstrate both side-by-side,” said Ramachandran, who added that the demonstration will include migrating virtual functions between both classes of test units, to show how they might behave side-by-side in a telco data center. “It’s about being able to demonstrate clearly that the ARM solution is ready, the ecosystem that AMD has put together is ready for NFV, and that AMD is truly ambidextrous. It has both x86- and ARM-based solutions, and offers customers the ability to migrate to different architectures, different providers, etc., in a much easier way; and bring down their operating expenses.”

Just what does AMD expect attendees to take away from the demonstration? If ARM architecture is not necessarily superior in an all-around way to x86 for NFV, then why would communications service providers make the investment? And if it is superior in demonstrable respects, then why continue to offer the x86-based option? More to the point, can’t AMD draw any preliminary comparison between the two from a perspective of performance profiles?

For the time being, no. “Fundamentally, when we look at a processor architecture, whether it’s ARM, PowerPC, MIPS, or x86, when you design a chip, you can actually achieve the multi-gigahertz with ARM that x86 has achieved,” says Kamal Khouri, AMD’s director of embedded product management. “It’s just not been done before. And I believe you can achieve the ultra-low-power implementations of ARM in x86, but they’ve just never done it. I don’t think fundamentally, when you look at computer architecture, there’s anything stopping an ARM and/or x86 from competing in the various markets. It’s just the fact that ARM started in mobile, and x86 started in PC.”

That said, continues Khouri, any rational comparison between the two architectures depends on the workload used in that comparison, especially in NFV situations that deal with IP packet processing. The implication here is that, if potential customers supply the workload parameters for the demonstration, the results they get will only be applicable to those parameters. Or, put another way, their mileage may vary.

“If your code has implemented the packet processing or the [virtual packet] inspection, or whatever the algorithm that you’re looking into is,” Khouri goes on, “if your bottleneck is single-threaded performance, it doesn’t matter how many cores you throw at the problem. You want the fastest single-threaded processor out there. However, if your application needs to be good enough in single-threaded performance — and really, it’s a mass of parallel data, which a lot of packet processing in data planes turns out to be — you don’t need that super-high single-threaded performance. You just have a lot of stuff coming in, and you need that bandwidth. Then throwing more processors at the problem scales very nicely.”

But after these demonstrations are complete, isn’t it likely that we’ll get a clearer picture of which workloads fall on which side of Khouri’s dividing line?

“We’re not promoting one architecture as superior to the other,” responded Ramachandran. “AMD has investments in both x86 as well as ARM-based products, and the goal is to show that the ARM-based product is great at certain things, whereas the x86 product is great at other things.”

“The question of, is Bald Eagle better for certain applications versus Hierofalcon is the right question to ask,” Khouri interjected, “but not because one of them is x86 and the other is ARM. It’s because Bald Eagle is a different SoC architecture [from Hierofalcon]. It’s not so much about the core as it is about what’s around the core.

AMD, at some point in the near future, can actually publish something saying: ‘We recommend our Bald Eagle platform for these types of functions, because it has higher single-threaded performance; and Hierofalcon is better suited for these types of workloads because it has 8 cores that can run in parallel versus the 4 in Bald Eagle.’  Never in that will we say it’s because one is x86 and one is ARM, because we don’t believe it matters.”

In the history of processor design, the features that have ended up making all the difference have been those which their implementers said didn’t really matter (run a search on Intel and “hyperthreading” for more). Even if the difference ends up not mattering in this specific instance, for the duration of this first head-to-head test of NFV on two architectures from the same manufacturer, enough people watching this test may conclude, for now, that it certainly does.