[pjmlp]

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.

[sapiogram]

> 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.

[magnio]

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

[rbanffy]

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

[sapiogram]

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

[hajile]

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.

[pjmlp]

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

[rbanffy]

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.

[binkHN]

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