Hacker News Reader

Comment by andrewia | Hacker News Reader

I'm very interested to see independent testing of cores without SMT/hyperthreading. Of course it's one less function for the hardware and thread scheduler to worry about. But hyperthreading was a useful way to share resources between multiple threads that had light-to-intermediate workloads. Synthetic benchmarks might show an improvement but I'm interested to see what everyday workloads, like web browsing while streaming a video, will react.

View on HN

I was surprised that disabling SMT has improved by a few percents the Geekbench 6 multi-threaded results on a Zen 3 (5900X) CPU.

While there are also other tasks where SMT does not bring advantages, for the compilation of a big software project SMT does bring an obvious performance improvement, of about 20% for the same Zen 3 CPU.

In any case, Intel has said that they have designed 2 versions of the Lion Cove core, one without SMT for laptop/desktop hybrid CPUs and one with SMT for server CPUs with P cores (i.e. for the successor of Granite Rapids, which will be launched later this year, using P-cores similar to those of Meteor Lake).

Probably because the benchmark is not using all cores so the cores hit the cache more often.

Since side-channel attacks became a common thing, there is hardly a reason to keep hyperthreading around.

It was a product of its time, a way to get cheap multi-cores when getting real cores was too expensive for regular consumer products.

Besides the security issues, for high performance workloads they have always been an issue, stealing resources across shared CPU units.

> there is hardly a reason to keep hyperthreading around.

Performance is still a reason. Anecdote: I have a pet project that involves searching for chess puzzles, and hyperthreading improves throughput 22%. Not massive, but definitely not nothing.

You mean 4 cores 8 threads give 22% more throughput than 8 cores 8 threads or 4 cores 4 threads?

Remember core to core coordination takes longer than between threads of the same core.

4c/8t gives more throughput than 4c/4t.

There are definitely workloads where turning off SMT improves performance.

SMT is a crutch. If your frontend is advanced enough to take advantage of the majority of your execution ports, SMT adds no value. SMT only adds value when your frontend can't use your execution ports, but at that point, maybe you're better off with two more simple cores anyway.

With Intel having small e-cores, it starts to become cheaper to add a couple e-cores that guarantee improvement than to make the p-core larger.

My experience with high performance computing is that the shared execution units and smaller caches are worse than dedicated cores.

As always, the answer is “it depends”. If you are getting too many cache misses, and are memory bound, adding more threads will not help you much. If you have idling processor backends, with FP integer or memory units sitting there doing nothing, adding more threads might extract more performance from the part.

For what it's worth, for security reasons, OpenBSD disables hyperthreading by default.

Generally HT/SMT has never been favored for high utilization needs or low wattage needs.

On the high utilization end, stuff like offline rendering or even some realtime games, would have significant performance degradation when HT/SMT are enabled. It was incredibly noticeable when I worked in film.

And on the low wattage end, it ends up causing more overhead versus just dumping the jobs on an E core.

> And on the low wattage end, it ends up causing more overhead versus just dumping the jobs on an E core.

For most of the HT's existence there weren't any E cores which conflicts with your "never" in the first sentence.

It doesn’t because a lot of low wattage silicon doesn’t support HT/SMT anyway.

The difference is that now low wattage doesn’t have to mean low performance, and getting back that performance is better suited to E cores than introducing HT.

> It doesn’t

Saying "no" doesn't magically remove your contradiction. E cores didn't exist in laptop/PC/server CPUs before 2022 and using HT was a decent way to increase capacity to handle many (e.g. IO) threads without expensive context switches. I'm not saying E cores are a bad solution, but somehow you're trying to erase historical context of HT (or more likely just sloppy writing which you don't want to admit).

I’ve explained what I meant. You’ve interjected your own interpretation of my comment and then gotten huffy about it.

We could politely discuss it or you can continue being rude by making accusations of sloppy writing and denials.

No, you haven't explained the contradiction, you just talk over it. Before E cores were a thing, HT was a decent approach to cheaply support more low utilization threads.

Backend-bound workloads that amount to hours of endless multiplication are not that common. For workloads that are just grab-bags of hundreds of unrelated tasks on a machine, which describes the entire "cloud" thing and most internal crud at every company, HT significantly increases the apparent capacity of the machine.

The need for hyperthreading has diminished with increasing core counts and shrinking power headroom. You can just run those tasks on E cores now and save energy.

Reply on news.ycombinator.com