> So if you've wondered why hyper-threading is sometimes considered a trick played by CPU vendors, now you know. Since the two threads on a core share so much, they are not fully independent CPUs in the general sense.
> Caches isn't the only thing threads within a core share, however. They also share many of the core's execution resources, like the execution engine, system bus interface, instruction fetch and decode units, branch predictors and so on [3].
I would go even further than this... rather than starting from the idea "they sound separate, but apparently share a lot of stuff", you are probably better off working from the original goal of a hyperthread: sometimes the CPU blocks on something slow, like memory or a dependent register, and it has nothing it can easily reorder to do in the mean time; the idea of hyperthreading was to provide the CPU something else to do when it got stuck. So from that concept we would never expect it to have anything at all that it doesn't share: you are just filling in gaps in the execution of a single core by having the CPU itself implement something akin to a coroutine task scheduler. The issue I take with the mental approach in the article is then that it still implies there is at least some parallel compution possible there that is being limited by how much is being shared, but the reality is that hyperthreading has more in common with "green threading" than real concurrency: there is really only one thing there pretending to be two things entirely for the purpose of tricking legacy software into giving it something else to execute.
It's a bit better than green threading since out of order engines are imperfect at extracting parallelism and you can often use a second thread to fill in spare functional units that the first thread isn't using. There's also the danger that the extra cache pressure from two threads on a core will cause enough thrashing that using SMT will decrease performance on net. So it's more complicated but of course you're right that green threading is a much better first approximation than multiple cores. I suspect you already knew that but just didn't want to go into it.
One technique I've heard about is to schedule producer and consumer threads on the same core so that there's zero data transfer overhead and no extra d-cache pressure.
> Caches isn't the only thing threads within a core share, however. They also share many of the core's execution resources, like the execution engine, system bus interface, instruction fetch and decode units, branch predictors and so on [3].
I would go even further than this... rather than starting from the idea "they sound separate, but apparently share a lot of stuff", you are probably better off working from the original goal of a hyperthread: sometimes the CPU blocks on something slow, like memory or a dependent register, and it has nothing it can easily reorder to do in the mean time; the idea of hyperthreading was to provide the CPU something else to do when it got stuck. So from that concept we would never expect it to have anything at all that it doesn't share: you are just filling in gaps in the execution of a single core by having the CPU itself implement something akin to a coroutine task scheduler. The issue I take with the mental approach in the article is then that it still implies there is at least some parallel compution possible there that is being limited by how much is being shared, but the reality is that hyperthreading has more in common with "green threading" than real concurrency: there is really only one thing there pretending to be two things entirely for the purpose of tricking legacy software into giving it something else to execute.