Hacker News Reader

Comment by bakugo | Hacker News Reader

> I can't think of a good principled reason to say SMT cores aren't "real".

It really depends on your definition of "real", yes you can treat them like "real" independent cores but that's not ideal for performance because under the hood they're not actually independent. Your operating system is aware of this and will often avoid scheduling two tasks onto the same physical core unless it has to. If you have 20 logical cores (10 physical ones with hyperthreading) and 10 tasks to execute, the OS scheduler will usually allocate one task to each physical core and leave the other logical core idle.

View on HN

I did an experiment and effectively proved this to myself many years ago.

I had just upgraded to an i7-3770K (8 threads, 4 cores) from a Core 2 Quad (4 threads, 4 cores). I did a POV-Ray render several times using 1, 2, 4, and 8 threads. 2 was nearly double the speed of 1, 4 was nearly double the speed of 2, but 8 was only about 15% faster than 4.

To ensure I wasn't bottlenecking RAM at that level, I tried again with 2 threads, but forced both threads onto a single core, and it was only 15% faster than 1 thread.

That was all the proof I needed of how you really can't treat two CPU threads as two cores.

That said, I've never personally found an instance where allowing a processes to span all CPU threads actually reduced performance, and I'm not sure I've ever seen a real-world case where it does. It's usually something contrived.

When I bought my current desktop the two CPUs I was looking at were the i7-9700K and i9-9900K. This was the generation where intel went from 6 cores with HT to 8 cores w/o HT for the i7. The i9 has 8 cores with HT.

I liked the idea of the i7 because without HT you have a real picture of how utilized your CPU is. If it says 100% on a core it's 100%. I ended up going with the i9 though when a promotion was too good to pass up.

When I got it I ran Cinebench both with and without HT enabled in the BIOS and it made a decent impact so I left it on.

That's one use case. SMT is not designed to address it. POV-Ray will saturate your execution resources in the core and adding another frontend doesn't change the facts.

SMT is designed to hide memory load latency. In this use case it is completely brilliant. You will get 2x speedups with hyperthreading when randomly accessing memory.

> You will get 2x speedups with hyperthreading when randomly accessing memory.

...unlesss you access so much memory (while doing relatively little compute on each piece) that hyperthreading just causes more cache invalidation.

An underappreciated consequence of this is that if doubling the number of cores doubles performance (meaning the multi-threading is good) but going on to the hyperthreads only gives a 15% speedup then that means that in the hyperthreaded case each hyperthread must be running 57.5% of normal speed - barely half as fast. That's just math.

This slowdown of each thread may not matter, or it may lead to increased latency.

TL;DR - when both hyperthreads in a core are in use it is highly likely that each one is running significantly slower than if only one was in use.

Reply on news.ycombinator.com