Re: HT vs execution pipelines

Wow! Very cool explanation! Thanks !!

> On Jan 20, 2026, at 07:26, Yuri Davidovsky <[email protected]> wrote:
> 
> 
>> On 20 Jan 2026, at 14:12, David McClain <[email protected]> wrote:
>> 
>> What I notice is that whenever the “HyperThreading” cores get lit up, then my CPU throttles down.
> 
> HT is bad news indeed. It seemed like a solution at the time by giving the control of extra CPU core resources to the programmer, but it was oversold on the promise. Essentially what it was used for in practice, is the developer trying to figure out ways to use the computational circuits in one thread while the other was waiting for data (meaning you would have to have register-fulls of data and have a good bunch of compute to do on them). It is not a trivial task at all (as it turned out) that requires a more than superficial understanding of how the CPU operates and no-one has a shortage of things on the learn-at-some-stage backlog.
> 
> ARM platform bet on parallel execution pipelining — instead of having just two threads that have to be controlled manually, on M1, for example, we have:
> 
> 1. 4 scalar execution units.
> 2. 4 SIMD execution units.
> 3. 4 memory operation units (3 read and 1 store)
> 
> You could think of those as specialised HT threads that do just one task, but do it well, while a hyper thread is no different from the software point of view to a regular full fat thread and can do everything a physical thread can. As we can see above, we have 8(!) threads for doing computations alone, rather than a single feeble HT thread, and those can find and perform work in the decoded instruction buffer on their own, without input from the programmer:
> 
> +--------------------------------------------------------------------------------------+
> |                           REORDER BUFFER (ROB) SNAPSHOT                              |
> |   (The "Window" of instruction execution - M1 has ~630 slots like this)              |
> +-----+-------------+--------------------------+---------------------+-----------------+
> | ID  | ITERATION   | INSTRUCTION (Renamed)    | DEPENDENCIES        | STATUS          |
> +-----+-------------+--------------------------+---------------------+-----------------+
> | 001 | Iter 1 (i=0)| LOAD  P10 <- [Base + P01]| Depends on P01 (i)  | [ DONE ] (Hit)  |
> | 002 |             | ADD   P11 <- P05 + P10   | Depends on P10 (Dat)| [ BUSY ] (Math) | <--- CURRENTLY
> | 003 |             | ADD   P12 <- P01 + #1    | Depends on P01 (i)  | [ DONE ]        |      CALCULATING
> | 004 |             | BNE   (Branch)           | Predicted Taken     | [ DONE ]        |
> +-----+-------------+--------------------------+---------------------+-----------------+
> | 005 | Iter 2 (i=1)| LOAD  P13 <- [Base + P12]| Depends on P12 (i)  | [ DONE ] (Hit)  | <--- Data ready!
> | 006 |             | ADD   P14 <- P11 + P13   | Depends on P11 (Sum)| [ WAIT ]        |      Waiting for
> | 007 |             | ADD   P15 <- P12 + #1    | Depends on P12 (i)  | [ DONE ]        |      Iter 1 sum
> | 008 |             | BNE   (Branch)           | Predicted Taken     | [ DONE ]        |
> +-----+-------------+--------------------------+---------------------+-----------------+
> | 009 | Iter 3 (i=2)| LOAD  P16 <- [Base + P15]| Depends on P15 (i)  | [ DONE ] (Hit)  | <--- Data ready!
> | 010 |             | ADD   P17 <- P14 + P16   | Depends on P14 (Sum)| [ WAIT ]        |
> | 011 |             | ADD   P18 <- P15 + #1    | Depends on P15 (i)  | [ BUSY ]        |
> | 012 |             | BNE   (Branch)           | Predicted Taken     | [ WAIT ]        |
> +-----+-------------+--------------------------+---------------------+-----------------+
> | ... | ...         | ...                      | ...                 | ...             |
> +-----+-------------+--------------------------+---------------------+-----------------+
> | 600+| Iter 20...  | LOAD ...                 | ...                 | [ DISPATCHED ]  |
> +-----+-------------+--------------------------+---------------------+-----------------+
> 
> The table above (I hope it makes it through the email client formatting, let me know if it doesn’t) shows serialisation of the instruction buffer of a simple loop (we skip loop termination checks for table simplicity as those involve CPU operation flag handling):
> 
> for (int i=0; i<N; i++)
>     { sum += data[i]; }
> 
> where in the table Pn entries are physical registers (the number of which can be in the hundreds) that are waiting to fade into focus and get assigned a proper register name. As we can see in the table snapshot, most of our data offset arithmetic is completed already ahead of time, same is for the data handling threads, our bytes and words are waiting for us in the registers too: we only need to do a single pass to accumulate the sum. Accessing those will be instant.
> 
> Overall I think HT is a thing of the past and you already can see new x64 processors that do not support it (at least on the Intel's side), the multiple execution pipeline architecture appears to be the right way to utilise the core resources. HT also turned out to be a security liability and the famous Spectre and Meltdown exploits depended on it. Interestingly, the patches released at the time when the breach was discovered reportedly reduced the performance of CPUs by 10-20% — the exact performance gain that HT produced to start with. 
> 
> I suspect those patches were simply disabling hyperthreading on the affected CPUs and that was about it.
>