Intel's next-gen Arrow Lake CPUs might come without hyperthreaded cores

With typical database servers, hyperthreading provides about 1.4x the performance "for free" because it allows execution units to do something useful while another thread is waiting for memory.

Where it isn't useful is typical game engines, except in some corner-cases as you've noticed.

Typical game engines like to have dedicated cores with the highest possible performance. Hyperthreading improves overall throughput at the expense of single-threaded throughput.

Similarly, game engines tend to run task-per-thread with different code, which tends to pollute the L1 code cache too much. So if two different threads are running on the same core but are doing different things, they'll fight over this precious resource.

Intel measured something like a +20% overall improvement averaged out across a wide range of workloads. A few had regressions, and a few (like ray tracing) had huge benefits.

IMHO, hyperthreading makes the most sense for servers, or laptops with a small number of cores (2-4). For high-end gaming, 16 cores with HT off will likely have the best performance.

More recently we did some DirectX 12 MT-rendering tests; since there's more considerable overhead for breaking up the work into more batches so we wanted to be sure so we checked carefully.

On a i7-12700K we found that distributing Dx12 work to SMT or E-Cores had no benefit, even in a contrived rendering stress-test.

However, on an unnamed game console, we found that scheduling additional work to the SMT cores improved draw performance by maybe 7%.

YMMV but my impression is the workload needs stall on memory enough to get signfican gains by interleaving the ALU from another thread and this might benefit low-power systems like laptops or mobile phones more than workstations.

* hyperthreading is useless for purely-numerical code (the inner loop of math/science software), and for this kind of code it is also often harmful per the next point

* hyperthreading is harmful for code that is highly cache-sensitive within the scheduling quantum (though multiple cores may share caches too, and for the degenerate case of RAM-as-cache-for-swap people generally think in terms of "too many threads means more thrashing"; hyperthreading really isn't special there). This is more likely for "busy" tasks, but "background" tasks are likely to have no problem here.

* hyperthreading is beneficial for OO-like code that does a lot of pointer-chasing (which almost all software is, at least in part)

* hyperthreading might beat threads in separate cores for contended atomics

If you're trying to optimize particular code, it's generally better to eliminate the horrible memory patterns in the first place than expect a handwaved hardware "solution". Where it wins is for broader code that is too spread out for you to focus your attention on.

And of course, there is still a lot of code that is fundamentally single-threaded (at least in the critical path), and if allowed to hog the CPU will not see any benefit from hyperthreading.

For a long time hyperthreading was any easy win on desktop for all the various single-threaded background tasks. Now, with increasing core counts, specialized E- vs P-cores (and focus on power management in general), and Spectre/Meltdown, I'm not sure.

edit: Instead running two hardware threads interleaved and sharing the resources on a single core, the implication is that you're turning it into a problem of scheduling work on separate cores with some provably separate resources. That probably makes it easier to have certain guarantees, and leaves you more time to worry about resources that you really do need to share but cannot afford to duplicate/distribute across the machine. Sometimes you really want two threads to share memory!

They beat on price and energy with no SMT.

This should be ok I assume in a similar vein if you can stuff as many cores as possible.

There is no such thing, basically core speed is a curve where they get more and more inefficient the faster they run, and the hard frequency limit is just some arbitrary point on that curve.

If a particular HT friendly workload gets more done at a specific clockspeed, that is a significant boost to efficiency even if it uses more power, as clockspeed power usage scales very non linearly towards the top.

That being said, I dont think you are wrong. In consumer devices, HT seems like a bad tradeoff for a bigger, more cache heavy core.

I think two cores that are 50% utilized burn through less power than one core that is 100% utilized but that also contains all the extra stuff it needs to pretend it's two cores. And that's the best case scenario. Quite possible that in the days HT was introduced, idle units weren't half as good at not consuming power as they are now.

If your threads are io-busy, pick thread counts based on io limits (depending on where on the throughput/latency spectrum you fall)

If you've got P and E cores, you might need to do some perhaps new stuff to balance threads --- the old way where an e core was about half the perf of a P core, so two threads on P and one on E was kind of even won't work without hyperthreads, but if you don't cpu pin your threads, maybe it works out. (Maybe the OS needs to do more work to track usage though)

another poster here commented on a 10% performance boost overall with HT on vs it off, that about matches up with my experience in an HPC-adjacent environment.