This week, we published a piece on how Mapping Licensing for Virtualization is Cool Now. Something stood out while doing that piece, aligning with what we have seen in the market. After years of hearing simultaneous multi-threading (SMT) is flawed, it is exceptionally tough to buy a mainstream server CPU without SMT in 2025, and it will perhaps get more challenging in the future. Let us get into how we got here, and why.
We are going to use some AMD EPYC 9005 platforms here to demonstrate and use chips and a system AMD sent. We need to say this is sponsored by AMD. Still, the implications reach far beyond the systems we are using to test here.
The Key Feature for Server CPUs is Still Two
There are plenty of guides out there, but the idea of SMT has been around for some time. For our purposes, we are going to discuss SMT in the context of having two threads per core, but we have systems in the lab, such as the IBM Power9, that have SMT=8 available, just as an example. By having two threads in flight, handled by the same core, the compute resources that would otherwise sit idle waiting for data to be retrieved through the memory hierarchy can instead switch between two threads to keep the compute engines fed.
Just looking at some practical examples of this, here is the lscpu output of the AMD EPYC 9965 where you can see “Thread(s) per core: 2” showing SMT=2 in this platform.
If you prefer pictures, then here is the topology where we can see the Core L#0 has PU L#0 P#0 and PU L#1 P#384.
That shows the two threads on one physical core.
SMT Performance Impact
We have shown a few times that SMT generally helps performance. Here is a quick look at the impact of SMT on many of the workloads we commonly use at STH:
To be clear, it is not in every case that SMT helps. For those running HPC workloads, often disabling SMT as well as setting nodes per socket (NPS) values to align with a chip’s physical layout are important tuning steps. In most cases, however, having SMT on helps tremendously.
It is not just us. Michael Larabel of Phoronix is one of my favorite people to grab a beer with. He found a very similar pattern when looking at SMT.
The counterpoint posed by proponents of not having SMT are twofold. First, generally one wants one customer per physical core so both threads must be consumed by one customer. Typically a cloud vCPU is one thread. As a result, with the AMD EPYC 9965 with 192 cores and 384 threads, that means the maximum number of two vCPU VMs one could host for a cloud customer keeping one physical core per customer VM is 192. One can charge for two vCPUs, but only have 192 customer VMs of two vCPUs each. If you have only physical cores without SMT, then your core/ thread count equals your VM count.
The second is that without SMT, the idea is that one can remove a number of transistors and tolerances dedicated to SMT functions and potentially add more cores. Currently the densest server CPUs are those with SMT, but to be fair, the Intel Xeon 6780E has 144 cores. While the Intel Xeon 6900E 288-core part was pulled from a public launch, two 144 core Xeon 6780E’s can almost match a 192 core/ 384 thread EPYC 9965. The one caveat here is that while AMD removed caches and lowered the maximum clock speed for the EPYC 9965, it is using the same Zen 5 instruction set while Intel removed features such as AVX-512.
That is where this discussion goes a bit sideways. Many of the Arm server CPUs and the Intel Sierra Forest CPUs focus on integer performance and running open source workloads that do not require big floating point engines. The cut to transistor count to shrink the core size is not just SMT, it is also to those functions as well. To be clear, there are a ton of web servers, firewalls, and other systems out there that can use that type of core.
Still there is one other big tell. The current NVIDIA Grace does not support SMT. That CPU is designed really for the interconnect between the company’s GPUs. The company also announced that in the future its Vera generation replacement for Grace will adopt SMT. If SMT was detrimental to performance, we would not see NVIDIA go from not supporting SMT to supporting SMT with two threads per core. Also, when Cavium, then Marvell started working on its Broadcom Vulcan derived ThunderX3, that was a SMT=4 design offering a lot more performance than ThunderX’s no-SMT design.
Still, that brings us to the point of licensing that we explored this week on STH and we will cover next.
There were rumors that AMD was considering SMT=4 for Epyc a couple years ago. Would have been cool to see.
I’ve always understood Arm CPU guys trumpeting that they’ve got no SMT as a feature as it’s B.S. And that doesn’t stand for Blue Smoke
It should be pointed out that, while Cavium’s initial design for the ThunderX2 used a single-thread-only core design, the final production ThunderX2s that were released (CN99xx) were based on Broadcom’s Vulcan core and that core supports SMT4, four threads per core. Technically, this means that the ThunderX2 does, in fact, have SMT. Patrick isn’t wrong, but he isn’t entirely correct, either.
No Nutanix AHV? No idea how you can have Redhat virtualization as enterprise level, but forget the only real enterprise grade alternative to esx….
I am not so sure the idea is clear cut, and that is ignoring security issues with SMT. For cloud vendors with vCPU unit selling price that is very nice way to sell it. For x86 that might have make sense. but once you start comparing the core size of ARM without SMT is also smaller.
At the end of the day it is just about price / performance ratio. And COGS of CPU is only part of the calculation without also factoring their margin, R&D, support etc.
You’re missing one issue here *against* SMT — the shared state between threads makes spectre/meltdown type attacks much harder to defend against. It’s really hard to avoid leaking cache miss data between threads, as there’s just too much in common between them.
It’s not necessarily that big of a deal when you own both threads, but when someone else’s VM is running on the other half of “your” CPU then you’re at risk of them being able to extract your encryption keys, etc just by cache timing attacks. We *might* have closed all of the known attacks today, but I’d be shocked if we don’t continue finding more over time.
Spectre and Meltdown was over 7 years ago. I don’t think 2025’s gens of CPUs with Hyper Threading have Spectre and Meltdown vulns
Outside of small Linux DNS or ancient Server 2003 systems, almost nothing runs well on a single core anymore. Even a simple Win 10 Jumpbox needs 2t to be usable. Therefore there really isn’t any reason to not use SMT to double your vCPU.
Is that licensing per physical core a major reason why some places deploy IBM Power Systems? Those eight threads per core (also in Power 10) might be a strong incentive.
@eastcoast
People deploy Power because they went Power years ago and cannot get off that platform. On a performance, and especially cost, aspect Power cannot compete with x86 even with SMT 8. Some software, IIRC, like Oracle licenses per vCPU on a virtualized platform so SMT 8 doesn’t help you reduce cost.
Thanks for the response! Yes, it seems that the POWER user base keeps shrinking by the year. Was also disappointing that IBM abandoned Open Power after POWER 9.
And, I’m a bit amazed that Oracle is still charging by the thread.
I’m glad to see there are options if I “did not wis ant” to buy a server CPU with “cores designed to more!”
Zen 5 was specifically designed for SMT. It features dual instruction decoders – one for each thread. The second decoder is not being actively used for single threaded use cases, in contrast to Intel Gracemont’s clustered out-of-order 3+3 decoder design for example.
The anti-SMT sentiment is based on older designs, especially Intel, that did lower overall performance in some use cases. This is similar to how early AVX-512 implementations lowered performance vs. AVX2 due to heavy downclocking.
In both cases AMD’s designs seem to have the edge, but Intel’s later designs have mostly caught up.
@geoff
In order for Nutsnix AHV to be considered an esxi alternative it has to be comparable on price. I can tell you it isn’t close to the same price. Their “mid level” license is as expensive as the top esxi license. That makes it a hard no for a lot of companies.
I don’t think many people have an issue with SMT. But the original HT, man, that was a mess.