AMDs marketing is just as sketchy. Their new Zen6 server page claims 3.3x performance per watt over vera on "agentic workloads" for a 100 kW rack. Maybe they are comparing a CPU heavy rack to an nvidia vera rack with 50 kW of GPUs sitting idle, who knows?
I don’t think picking a handful of SPEC benchmarks that approximate today’s most common agentic workloads (compiling code, interpreting Python) and then calling them “agentic benchmarks” is misleading at all.
That you need a whole lot of “ordinary” compute to benefit from the scaling properties of agents is the reason Nvidia is making this chip in the first place.
The four benchmarks selected are cppcheck, llvm, cpython, and gcc [1]. These are all essentially compiler benchmarks... and all of the compiler benchmarks in SPEC cpu2026! This makes the benchmark selection somewhat suspicious to me, since it's not particularly representative of a diverse set of workloads.
I also don't buy that it's a particularly representative set of tasks you might do with agents. Also included in the SPEC benchmarks are multimedia codecs, lossless data compression codecs, sqlite (i.e., database), all of which are going to be things you should easily throw into the sets of tasks an agentic workload might do. Cherry-picking just the compiler benchmarks instead of all of SPECint... again, it just raises a couple of eyebrows.
[1] To be honest, I'm kinda surprised that both gcc and llvm are in SPEC cpu2026.
The code in compilers is the closest to your typical app you can get in a benchmark like SPEC, eveerything else is actually far more specialized. Compiler code is full of small basic blocks, lots of branches, indirect memory access; it's actually harder to get good performance for such code, both for CPUs and compilers (that was part of the death of Itanium too).
That's true of most of the applications in SPECint (SPECfp is a different matter); there's nothing special about compilers there.
Where compiler code is going to get really unusual, I suspect, is that compilers tend to be a little mono-focused on relatively few data structures. I know I was able to get measurable (single-digit percent!) performance differences in LLVM making very small tweaks to layout in llvm::Value. By contrast, when I was working on Thunderbird, the only similarly small change I could think to make that kind of difference would be to "oops, all string functions are now a cross-DLL call" (and even then, only because string handling is so dominant in that kind of application). Another kind of difference is that the compiler-based benchmarks are going to be quite light in virtual or indirect function calls (there's more of an emphasis on switch-based dispatching than vtable-based dispatching in most compiler implementations), which is going to make it a poorer proxy for some kinds of applications.
Death of Itanium was that it was a) VLIW and b) Intel was too arrogant. So it went to the same destination as later Larrabee and ATI/AMD attempts at VLIW GPUs.
That is, nowhere.
Also you are wrong and anyone sizing up an arch to put their loads onto must first try that load on it and not rely on "bah, compilers compile on it".
In a hypothetical world where AMD wasn't allowed to do AMD64, and Intel stayed committed to Itanium: Itanium would still have sucked, and both PowerPC and SPARC would have out-sold Itanium by an even wider margin than they did in this reality. Itanium could only have succeeded if AMD64 wasn't possible and literally all of the competing 64-bit architectures were killed off by their owners so they could jump on the Itanium bandwagon. Itanium managed to kill off PA-RISC and Alpha and (high-end) MIPS roadmaps, but it still had competitors that were not just viable but actually more successful.
VLIW works for DSP applications, it's not an instant dead end. It's a good fit in cases where code path and memory accesses are predictable, like shader code.
Let’s not forget the fact that despite their new market cap and being the beneficiary of having a near monopoly on making incredibly complex pickaxes during a gold rush… Nvidia is still the company with a long and consistent history of misleading their customers via marketing. Their greatest hits include:
- The digital equivalent of the VW emissions scandal where drivers detected when they were being benchmarked and altering rendering for better results
- Selling GPUs as having 4gb vram when it was only 3.5gb usable, the remaining 0.5 being absurdly slower and causing performance loss when used
- Using intentionally misleading naming schemes to obfuscate things like memory bus width being drastically different between what superficially appeared to be similarly spec’d cards
A dozen other less egregious but similarly disingenuous decisions
But to be clear, I’m a huge fan and continue to run Nvidia because their products are generally incredible regardless
I'm glad to see the competition; nothing provokes meaningful change without it. Not surprised at Nvidia's blatant fabrications though; more of the same we've seen time and again (Superchip anyone, with 2+ year old designs).
In today’s “agentic” world, everyone seems to have forgotten approximately everything we used to know about security. And this new CPU is going all in on value speculation. Delightful.
Maybe if “cyber” models get good enough at exploiting speculation attacks, people will start demanding equipment that is less prone to these attacks.
Olympus’s raison d’être is to orchestrate GPUs—handling the control-heavy, latency-sensitive workloads that keep Rubin fed and the AI factory running without bottlenecks. Including tool calling and data marshaling.
They are not competing in the CPU space. Different markets.
AMDs marketing is just as sketchy. Their new Zen6 server page claims 3.3x performance per watt over vera on "agentic workloads" for a 100 kW rack. Maybe they are comparing a CPU heavy rack to an nvidia vera rack with 50 kW of GPUs sitting idle, who knows?
https://www.amd.com/en/products/processors/server/epyc/9006-...
I don’t think picking a handful of SPEC benchmarks that approximate today’s most common agentic workloads (compiling code, interpreting Python) and then calling them “agentic benchmarks” is misleading at all.
That you need a whole lot of “ordinary” compute to benefit from the scaling properties of agents is the reason Nvidia is making this chip in the first place.
The four benchmarks selected are cppcheck, llvm, cpython, and gcc [1]. These are all essentially compiler benchmarks... and all of the compiler benchmarks in SPEC cpu2026! This makes the benchmark selection somewhat suspicious to me, since it's not particularly representative of a diverse set of workloads.
I also don't buy that it's a particularly representative set of tasks you might do with agents. Also included in the SPEC benchmarks are multimedia codecs, lossless data compression codecs, sqlite (i.e., database), all of which are going to be things you should easily throw into the sets of tasks an agentic workload might do. Cherry-picking just the compiler benchmarks instead of all of SPECint... again, it just raises a couple of eyebrows.
[1] To be honest, I'm kinda surprised that both gcc and llvm are in SPEC cpu2026.
The code in compilers is the closest to your typical app you can get in a benchmark like SPEC, eveerything else is actually far more specialized. Compiler code is full of small basic blocks, lots of branches, indirect memory access; it's actually harder to get good performance for such code, both for CPUs and compilers (that was part of the death of Itanium too).
That's true of most of the applications in SPECint (SPECfp is a different matter); there's nothing special about compilers there.
Where compiler code is going to get really unusual, I suspect, is that compilers tend to be a little mono-focused on relatively few data structures. I know I was able to get measurable (single-digit percent!) performance differences in LLVM making very small tweaks to layout in llvm::Value. By contrast, when I was working on Thunderbird, the only similarly small change I could think to make that kind of difference would be to "oops, all string functions are now a cross-DLL call" (and even then, only because string handling is so dominant in that kind of application). Another kind of difference is that the compiler-based benchmarks are going to be quite light in virtual or indirect function calls (there's more of an emphasis on switch-based dispatching than vtable-based dispatching in most compiler implementations), which is going to make it a poorer proxy for some kinds of applications.
Death of Itanium was that it was a) VLIW and b) Intel was too arrogant. So it went to the same destination as later Larrabee and ATI/AMD attempts at VLIW GPUs.
That is, nowhere.
Also you are wrong and anyone sizing up an arch to put their loads onto must first try that load on it and not rely on "bah, compilers compile on it".
Itanium only died because AMD exists, and due to various licensing reasons they were allowed to come up with AMD64.
In a hypothetical world where AMD wasn't allowed to do AMD64, and Intel stayed committed to Itanium: Itanium would still have sucked, and both PowerPC and SPARC would have out-sold Itanium by an even wider margin than they did in this reality. Itanium could only have succeeded if AMD64 wasn't possible and literally all of the competing 64-bit architectures were killed off by their owners so they could jump on the Itanium bandwagon. Itanium managed to kill off PA-RISC and Alpha and (high-end) MIPS roadmaps, but it still had competitors that were not just viable but actually more successful.
VLIW works for DSP applications, it's not an instant dead end. It's a good fit in cases where code path and memory accesses are predictable, like shader code.
Let’s not forget the fact that despite their new market cap and being the beneficiary of having a near monopoly on making incredibly complex pickaxes during a gold rush… Nvidia is still the company with a long and consistent history of misleading their customers via marketing. Their greatest hits include:
- The digital equivalent of the VW emissions scandal where drivers detected when they were being benchmarked and altering rendering for better results
- Selling GPUs as having 4gb vram when it was only 3.5gb usable, the remaining 0.5 being absurdly slower and causing performance loss when used
- Using intentionally misleading naming schemes to obfuscate things like memory bus width being drastically different between what superficially appeared to be similarly spec’d cards
A dozen other less egregious but similarly disingenuous decisions
But to be clear, I’m a huge fan and continue to run Nvidia because their products are generally incredible regardless
This is neat. I'm only halfway through but some really cool discussion about the internals of the chips and what they offer.
I'm glad to see the competition; nothing provokes meaningful change without it. Not surprised at Nvidia's blatant fabrications though; more of the same we've seen time and again (Superchip anyone, with 2+ year old designs).
In today’s “agentic” world, everyone seems to have forgotten approximately everything we used to know about security. And this new CPU is going all in on value speculation. Delightful.
Maybe if “cyber” models get good enough at exploiting speculation attacks, people will start demanding equipment that is less prone to these attacks.
Attacker: I can run any code on this machine? Time for speculation attacks!
Attacker: Oh wait, I can run any code? I already own the machine...
Not really, Spectre showcased an attack from within a JavaScript sandbox, which isn't considered to own the machine.
Any side effects from speculation machinery can easily become a side-channel to infer values across security boundaries.
So typical big corp marketing material disguised as whitepaper.
So, is this rip AMD
AMD announced a faster CPU two days later.
It’s a time-honored tradition to compare your upcoming product to the competition’s old news.
That said, looks like an impressive core and complete CPU built with it. Would love to see a smaller, affordable version.
Olympus’s raison d’être is to orchestrate GPUs—handling the control-heavy, latency-sensitive workloads that keep Rubin fed and the AI factory running without bottlenecks. Including tool calling and data marshaling.
They are not competing in the CPU space. Different markets.