A deep dive into Nvidia's Vera CPU and the Olympus cores that power it

DEEP DIVE For the first time, Nvidia has directly challenged Intel and AMD's CPU dominance. With the launch of Vera, the AI arms dealer aims to flog its standalone CPUs to as many hyperscalers and other cloud providers as it can. Alibaba, ByteDance, Meta, Oracle, CoreWeave, Lambda, Nebius, and NScale have already signed up to …

[bazza]

Hmmm, no matter which way one looks at this, it’s going to be one juicy chip!

I’d like one…

[BoHu]

Yeah ... looks great to me too! It'll be nice to see this Vera compete with the ARM AGI CPU, Fujitsu Monaka, AWS Graviton5, MS Cobalt-200, Google Axion, Qualcomm Dragonfly C1000, SiPearl Rhea 2-3, AmpereOne M, Apple Baltra ACDC, and others imho.

I'm also quite glad it's of the PCIe 6.+/CXL 3.+ generation (finally!) which should help "to do more workload disaggregation going forward" [ https://www.theregister.com/systems/2026/07/23/amd-and-cerebras-join-forces-against-nvidias-groq-lpus/5277817 ] -- and in this it should be able to compete with upcoming EPYC Zen6 and Diamond Rapids of x86 space as well.

The idea that it may even help beat crazy-high RAM pricing temporarily by reusing older sticks at scale until some market cooldown arrives is also rather neat afaics (TFA's "memory appliances" concept) [ https://www.theregister.com/systems/2026/06/29/zuck-saves-meta-bucks-by-reusing-memory-from-old-servers-with-a-custom-cxl-asic/5263483 ].

[Anonymous Coward]

Now I know why Microsoft is working on Windows 12

I think the award for most inefficient code ever shall forever remain with Microsoft. Very early on (think OS/2 days) it was already clear that using any compiler but Microsoft's would create much smaller and faster running code, and they got more than lazy with Intel producing ever faster chips to hide just how bad their code really is - it is as if Microsoft's second aim (aside from milking its users for every dime) was to waste as much computing power as possible.

This chip seems to fit almost perfectly into this scheme..

[Sproggit]

Microsoft and Chip Design

Actually, you're slightly off target with your observation [but not by much] and the history of this topic is pretty well chronicled.

Back in the 1980s, a British company, Inmos, developed an entirely new processor family known as the Transputer.

https://en.wikipedia.org/wiki/Transputer

These had a radical, out-of-box-thinking design in that while individual Transputer chips were perfectly functional, they were designed to work in massively parallel clusters. I saw a demonstration of a Transputer cluster with 1,024 discrete processors at a London trade fair, but the design was originally built to scale to 16,384 units in the "Parsytec GigaCluster".

https://en.wikipedia.org/wiki/Parsytec

The concept of MPP - massively parallel processing - took the chip design world by storm, sufficiently that Intel went away and built their own prototype of MPP, which they named the Intel i860 RISC processor and which was designed for the same sort of massive parallelism that Inmos had pioneered.

Intel showed the i860 to Microsoft - and Bill Gates threw a complete tantrum. He sent Intel away with a flea in their ear, all because Microsoft's own compiler [and, more importantly, their developers] discovered that they simply weren't able to wrap their heads around the MPP paradigm. Instead, Gates insisted, what Intel needed to produce for Microsoft was a CPU that didn't have massive horizontal scaling, but just ran faster and faster and faster. What I heard at the time was that Gates was actually furious with Intel, because what they inadvertently did was expose Microsoft's limitations - in effect Microsoft held back the entire industry because of this.

This quickly led to what became known at the time as the Gigahurts Wars, where Intel and AMD were leap-frogging eachother with ever faster CPUs, all to satisfy Gates and Microsoft. In fact, I'm pretty sure it was covered by el Reg at the time, but one journalist or researcher took some data from existing processors and looked at the clock rates and the "thermal output per square centimetre of surface" and calculated that if the then current crop of processors were scaled up to 5GHz [at the time the leading chips were sitting around the 1.5GHz range] then the thermal signature of such a 5GHz processor would be hotter than a fuel rod in a nuclear reactor at full power...

It's difficult to imagine from today's perspective, with hyperthreading and multi-core CPUs being commonplace, but we only got here by accident. Microsoft almost completely killed the concept of massively parallel processing and multi-threaded code - because it was too difficult for them to write compilers that could benefit from those features.

Only now, decades later [well, OK, that's a small exaggeration] has software development fully caught up with hardware design.

It would be interesting to try and picture what our industry would be like today, if only Microsoft had embraced parallelism when Inmos and Intel offered it.

Very different from what we have today, I suspect.

[PhilipN]

Re: Microsoft and Chip Design

"Microsoft held back the entire industry" countless times and they are not yet finished.

[James Turner]

Re: Microsoft and Chip Design

That almost sounds like the ring of truth, except famously MS developed the initial version of NT on the i860. That doesn’t sound like something where Intel have been told to get lost.

The i860 itself wasn’t massively parallel, but it did get used in some supercomputers that were. Its main issue was a dependency on the compiler to do optimisation that other chips did in hardware. You may recall Intel tried this approach somewhat later with Itanic. Nobody could get decent performance out of those either.

[Sproggit]

Re: Microsoft and Chip Design

You're right... but wasn't that decision (to prototype on the i860) made by the folk who joined the team from Digital?

Windows NT was [started, at the very least] as a collaborative effort between Digital and Microsoft. Digital were looking for a graphical update to the venerable VMS Operating System for their [then new] Vax Workstations [which included i860-based models] and Microsoft were looking to be taken a bit more seriously in the business world, given that their existing OS was known affectionately [or not!] as "Windows for Playgroups".

The naming of Windows NT (WNT) was a play on that relationship, since the 3 letters of that acronym are each one letter beyond the VMS by which Digital's OS was known.

The i860 had the performance to be suitable for workstations and high-end machines and would have been an expensive proposition for the desktop space that was Microsoft's traditional stomping ground, especially if it initially sold in smaller numbers and didn't get economies of scale.

I wasn't there, so freely admit I could have that wrong, but that's my understanding. Certainly the history shows that Microsoft did not support the i860. A bit of digging around confirms that early prototype code for what was internally known as NT OS/2 ran on an i860 emulator... alongside some custom, in-house boards. That was done mainly to ensure OS portability and that their code wasn't tied to the x86 architecture. However, Microsoft found that the i860 suffered from slow context switching [critical vulnerability for a pre-emptive multi-tasking OS], as well as other architectural limitations, so dropped the i860 in favor of the MIPS3000 and the i386.

In total they experimented with the i860 for a few months in 1989.

[bazza]

Re: Microsoft and Chip Design

I cut teeth on Transputers.

To be fair, Inmos weren’t much better at tools for MPP than anyone else. Sure, they could produce a compiler, but debug and general supporting libraries were woefully inadequate.

Also, even by the time transputers had come along the idea of SMP was well entrenched.

In short, the only appealing aspect of MPP at the time was that it was possible to assemble a large amount of compute. But one avoided doing so at all possible costs. When PowerPC hit the embedded systems market, I / we jumped from Inmos to Motorola with unseemly haste. It’s not even as if we stopped writing parallel code; it was simply far far easier to write for and debug multiple PowerPC cards in a single VME chassis running VxWorks than anything Inmos had aspired to.

Inmos’s big mistake was to assume that their serial interconnections between transputers was the only interface a transputer would need. They forgot the “development” use case. Has they added something like JTAG to every node so that at least debugging, loading and hardware config were easier, they may have survived.

There is a case for the return of MPP transputer like architectures, though I note that NVidia have not done that for this chip (cache coherency abounds). And these days. With both Go and Rust effectively reimplementing Transputer’s CSP (ironically on top of SMP environments), code written in these languages could be targeted at CSP hardware. Rust in particular with its Fearless Concurrency could be recast to do CSP automatically (which would be neat). And if CUDA isn’t all about parallelism, I don’t know what is.

Certainly such things - when grasped by the modern developer - generally perform well. The Cell processor in the PS3 had a lot in common with Transputer; you had to write software to push data around the SPEs instead of all memory being universally addressable (akin to sending data through a channel in Transputer). Whilst initially alien to many, those that mastered it got huge performance from it.

It took the SMP world many years to finally match the Cell processor, a couple of silicon process generations down the line.

MPP still rules in some places, eg the Fugaku supercomputer in Japan.

So did MS kill off MPP? I don’t think so. Pragmatism is an important part of technology, and ecosystems matter to all but the academics. It was already too late for an SMP->MPP hardware transition to be quick and easy by the time the i860 came about, even though few of us had dual CPU machines. Had MS gone along with it, we’d all now be running Solaris on Sparc (because that’s what would have won).

[Yet Another Anonymous coward]

Re: Microsoft and Chip Design

>Inmos’s big mistake was to assume that their serial interconnections between transputers was the only interface

Ironically we used Transputers in a lot of physics experiment data capture systems because you got a super fast serial data link (much faster than the ethernet of the day) built-in for free

[Bebu sa Ware]

It would be interesting to try and picture what our industry would be like today…

"It would be interesting to try and picture what our industry would be like today, if only Microsoft had embraced parallelism when Inmos and Intel offered it."

Or if Garry Kildall's plane was in dock undergoing an airworthyness on the fateful day Big Blue called.

I recall a fair amount of enthusiasm at the time (1980s?) for the Transputer and Occam but I think part of the problem was so few enthusiasts ever got their hands on the hardware.

Also I suspect a lot of the coding at Microsoft around the i860 time was in assembly - coding a multithreaded application in assembler could be interesting.

Microsoft's development tools were never particularly leading edge - MSC v3 was I think just a lightly warmed over Lattice C. MSC v4 was a little better but very slow. Walter Bright's C compilers^† were far faster (and cheaper.) Turbo·C, and Borland's tools generally, likewise.

_{† I believe Zortech C/C++ was the first native code C++ compiler to support Windows development ie not a preprocessor (cfront.)}

[Yet Another Anonymous coward]

Re: It would be interesting to try and picture what our industry would be like today…

Zortech was also the first to give you a flat 32bit address space (on a 386) rather than having to chop everything into 64k blocks with Microsoft

[Sorry that handle is already taken.]

Re: Microsoft and Chip Design

Even though multi-threading is now universal on modern x86 CPUs, single threaded performance is still about 5-6× that of the best Netburst could offer, even at the same clockspeed.

[Anonymous Coward]

Re: Microsoft and Chip Design

As far as I'm aware Microsoft is *still* totally rubbish at handling multiple cores. The crud Redmon jokingly refers to as an OS loads up one core and only switches to the next core when the previous one runs at full load - the very idea of load distribution has as yet to arrive there. Any other OS does proper load distribution, but Microsoft does not, which also has consequences for thermal load and chip longevity.

The rest of the world has moved on to paper and ballpoints, yet Microsoft still insists licensed stone tablets with chisel and optional extra fee hammer are THE way to work.

[Sunset]

Not a modified Cortex

It isn't a modified Cortex or Neoverse, and the resemblances are largely superficial.

There are both legal and technical reasons preventing modification of ARM IP - customers usually don't receive full RTL, and modification of what they do receive is prohibited except as officially-sanctioned parameterization options (ie, the now-defunct Built On Cortex program.)

[bazza]

Re: Not a modified Cortex

Depends on the license. Apple and some others are licensed to implement the ISA their own way.

What ARM provides to many licensees is prepackaged implementations, saving them from having to do all the work themselves.

And either way, ARM controls the ISA and expects compliance to the ISA from those doing their own implementations.

That doesn’t stop ISA implementors like Fujitsu adding to it; they’ve bolted on their own vector unit for the Fugaku supercomputer, giving their ARMs a whole set of instructions not found on other ARMs.

[zipityzi]

Re: Not a modified Cortex

I also didn't know this was possible: Arm allows some Neoverse configuration options, but nothing deep inside the microarchitecture.

However, Arm's interview The Next Platform by Timothy Prickett Morgan appears to aligns with the El Reg's reporting.

Q:Is there any cloud builder or hypervisor to date that doesn’t use a Neoverse core and that uses a customized core in any way? To my knowledge, there isn’t, although there might be something happening with Nvidia’s future “Vera” server CPU. I strongly suspect that the Nvidia slide that said “custom Arm core” meant to say Compute Subsystem.

Mohamed Awad, Arm: There is no hyperscaler or cloud builder today that is building an SoC based on a custom architecture. Their SoCs are all built on Neoverse."

That was quite surprisingly, as NVIDIA always calls it "custom".

My hypothesis: I would not be surprised if Arm and NVIDIA had a quiet sweetheart deal where Arm's Neoverse architects worked with NVIDIA's architects to design the Olympus core (for a fee above the typical ALA & TLA prices). I do not imagine it was cheap, as Arm would have to go above & beyond their typical ALA / TLA obligations to make this work.

[O'Reg Inalsin]

Get Smart

Agents raise the ratio cpu:gpu, but they also raise the total volume of tokens. The cpu:gpu ration change from 1:8 to 1:1 is the easy part. The change in overall token volume is much harder to estimate, other than that it is alway >> 1, as much as 1000x according to [1]. So far there is no indication that agents can improve GPU efficiency. That's being deferred under the assumption that it actually increases efficiency of humans in the real world.

Recent agent R&D at OpenAI and Anthropic raises interesting question about that efficiency - what does those agents that "escaped" their sandboxes and attacked other companies demonstrate about the operating humans in the real world? It looks a little like a street intersection "takeover" where rowdy teenagers spin their cars in a circle and occasionally take out a random bystander. I guess those teenagers can be forgiven because they're just having fun and feeling their power in the moment - eventually they will grow up and mature - maybe.

In any event the real bottleneck is not really cpu to cpu communications - its the net benefit to real world economy and humanity.

It's easy to get lost in the moment.

[1] https://digitaleconomy.stanford.edu/news/how-are-ai-agents-spending-your-tokens/

[Sproggit]

SMT on ARM Cores

Tobias writes:-

"SMT has been a mainstay of x86 chips since 2002. The technology boosts utilization by enabling two threads to harness idle execution units during a single cycle. While SMT doesn’t double throughput, for certain applications it can deliver double-digit percentage gains.

While Arm has supported SMT in the past — you may recall Cavium ThunderX2's four-way SMT implementation prior to its acquisition by Marvell — the company has downplayed its value with its own agentic CPU.

Arm's dislike for the tech didn't stop Nvidia from implementing SMT-like functionality in Olympus. We say SMT-like because it's not SMT in the conventional sense. Rather than simultaneous multi-threading, Nvidia markets it as spatial multithreading, which is an apt name given how it works."

I believe this either skips over some critical context, or mis-states the underlying CPU design - at least to a limited extent.

Although many-generations-removed, today's ARM cores have a history that go all the way back to the ARM CPU and associated chipset (MEMC, IOC and VIDC) that powered the Acorn Archimedes back in the mid- to late-1980s. This entire family of processors, right up to the modern versions, are RISC based (Reduced Instruct Set Computer) and not the CISC (Complex Instruction Set Computer) that is found in the x86 family of processors.

The early generations of ARM - in the likes of the Archimedes and follow-on machines - returned staggeringly close to 4 MIPS of sustained throughput from a chip clocked at 4MHz. That speed was actually quite a little bit faster than contemporary Intel silicon. It achieved this for-the-time staggering throughput by having a relatively simple instruction set - 44 basic instructions that could be enhanced with conditional execution flags - that eventually evolved in to the sort of pre-fetch, pipelining and pre-execution that we see in current CISC based processors.

All the above is relevant because the whole point of SMT is that it allows multiple threads to operate during "idle cycles" in a processor. "Idle cycles" are common - in fact typical - in CISC-based designs, but they are much, *much* less useful in RISC-based processors, because the much faster execution rates for individual instructions. Say your CISC-based processor averages one instruction per 4 or 5 clock ticks... that means that 75-80% of your "clock ticks" are essentially lost because other parts of your CPU are busy performing logic steps for you.

SMT was a genuinely brilliant adaptation to processor design that found an elegant way to soak up that unused capacity by allowing the "idle" processor cycles to perform activities for other threads.

But SMT doesn't bring the same sorts of advantage to ARM processors, because they don't have "idle" processor cycles in quite the same way.

We can be quite confident that if SMT brought genuine advantages, it would have been more widely adopted before now.

[Fido]

Re: SMT on ARM Cores

My impression is previous ARM designs didn't have a wide enough backend to support SMT. IBM Power and the recent Nvidia ARM offerings show this is not an intrinsic performance limitation of RISC.

Since Nvidia spends even more development effort on software than hardware, it's reasonable to assume a significant amount of co-design was involved and Vera is tuned to actual software workflows.

Said another way, new processors for running micro-services that require a standard unit of cloud compute based on single-core Xeon performance from ten years ago is, in my opinion, weirder than Nvidia's new offering.

[zipityzi]

Re: SMT on ARM Cores

Interestingly, even some of Arm's smallest &w weakest cores have SMT: see the Neoverse E1.

"The Arm Neoverse E1 CPU delivers best in class throughput efficiency. It incorporates a new simultaneous multithreading (SMT) microarchitecture design. With SMT, the processor can execute two threads concurrently resulting in better aggregate throughput performance."

Now, how effective and how useful is SMT on the E1? I can't say that I've ever seen a design with it.

[tojb]

32 or 64

I couldn't be bothered reading all of this: all I need to know, is can I use 64 bit floats efficiently on this thing?

[Kevin McMurtrie]

Re: 32 or 64

It says it's super optimized for Python (the most performant number crunching language ever) so it must be 64 bits.

[wiggers]

Yes, but...

Does it run Doom?

[PeeTee]

Re: Yes, but...

Damn, I was going to ask if it could run Crysis

[Steve Channell]

Missed a bit...

While there is plenty to say about Vera and pairing with Rubin GPU, the other pairing of Vera is with Blueffield DPU, which is where the spacial multithreading comes into it's own.

Vera coupled into Blueffield 5 (not announced yet) increases the performance of DPU devices for TOE and CXL, but also allows the offload of more beefy workloads like KV-cache and KV (LSM) engines for databases.

The pincer move is that DPU offload and GPU integration push the case for Vera CPU from both ends.

Given the pincer strategy, the journalistic question becomes: why aren't you announcing Blueffield 5 at the same time?

[aardvarkus]

Shouldn't they have a trees-burned-per-minute rating too?