4 ms·

Renamed registers for OoOE, not architectural registers. These number over 100 (200-300 counting FP/SSE) for modern x86 CPUs. Hyperthreading splits resources (

by brigade 14y ago

Renamed registers for OoOE, not architectural registers. These number over 100 (200-300 counting FP/SSE) for modern x86 CPUs. Hyperthreading splits resources (including registers, branch prediction, TLB, etc.) between the threads. This split is static in Sandy Bridge and older and dynamic in Ivy Bridge and newer.

tbrownaw 14y ago
Within each core are separate register files containing 160 entries for integers and 144 floating point numbers. These registers are accessible within a single cycle and constitute the fastest memory available to our execution cores. Compilers will allocate our local variables and function arguments to these registers. When hyperthreading is enabled these registers are shared between the co-located hyperthreads. The article is oversimplified here to the point of being incorrect. The registers the compiler sees don't change (and there aren't 160 of them, I think there's a dozen or less), only the behind-the-scenes ones as the parent comment says.
- jules 14y ago
  Actually while the compiler will not explicitly output instructions to access these 160 registers, compilers can and do take advantage of the fact that under the hood there are 160 registers instead of a dozen or so. They do this with "instruction scheduling" which carefully orders the instructions in such a way that at the end when the hardware is done with it they can be executed in parallel and thus need more than the dozen or so architectural registers. So in a way "Compilers will allocate our local variables and function arguments to these registers" is correct.
  - brigade 14y ago
    Opposite actually - instruction scheduling is significantly more useful for in-order processors without renaming. Compilers take advantage of OoOE and register renaming by not caring too much about careful scheduling in favor of reducing register pressure. For example, the compiler could order a sequence of load -> store copies as 4x load -> 4x store, or 4x (load -> store). They're equally fast on an OoOE CPU, so compilers might choose the latter so as to spill fewer registers elsewhere in the function.
    - jules 14y ago
      It's true that the need for instruction scheduling is reduced in an OoO processor, but now you're comparing it to a processor that does not do OoO and hence needs to expose its entire register set as architectural registers. A compiler for an OoO processor still needs to be aware that under the hood there are 160 registers that can be used instead of 14 (at least if it wants to generate the most efficient code).
MichaelGG 14y ago
OK that makes sense. So this would add to the scenario where you have a compute-intensive task, to disable HT? HT's more suited as another level of latency hiding, while one thread's stalled the other can work?
- brigade 14y ago
  It's pretty rare for a thread to completely stall in modern CPUs as you might imagine an in-order CPU doing, but it is common to achieve less than 1 instruction/cycle throughput out of a theoretical ~3-4 instructions/cycle in the frontend and 6 µop/cycle in the backend (Sandy Bridge). So another thread helps feed the execution units, even if the first thread has no classical stalls.

by brigade 14y ago

tbrownaw 14y ago

Within each core are separate register files containing 160 entries for integers and 144 floating point numbers. These registers are accessible within a single cycle and constitute the fastest memory available to our execution cores. Compilers will allocate our local variables and function arguments to these registers. When hyperthreading is enabled these registers are shared between the co-located hyperthreads. The article is oversimplified here to the point of being incorrect. The registers the compiler sees don't change (and there aren't 160 of them, I think there's a dozen or less), only the behind-the-scenes ones as the parent comment says.

jules 14y ago
Actually while the compiler will not explicitly output instructions to access these 160 registers, compilers can and do take advantage of the fact that under the hood there are 160 registers instead of a dozen or so. They do this with "instruction scheduling" which carefully orders the instructions in such a way that at the end when the hardware is done with it they can be executed in parallel and thus need more than the dozen or so architectural registers. So in a way "Compilers will allocate our local variables and function arguments to these registers" is correct.
- brigade 14y ago
  Opposite actually - instruction scheduling is significantly more useful for in-order processors without renaming. Compilers take advantage of OoOE and register renaming by not caring too much about careful scheduling in favor of reducing register pressure. For example, the compiler could order a sequence of load -> store copies as 4x load -> 4x store, or 4x (load -> store). They're equally fast on an OoOE CPU, so compilers might choose the latter so as to spill fewer registers elsewhere in the function.
  - jules 14y ago
    It's true that the need for instruction scheduling is reduced in an OoO processor, but now you're comparing it to a processor that does not do OoO and hence needs to expose its entire register set as architectural registers. A compiler for an OoO processor still needs to be aware that under the hood there are 160 registers that can be used instead of 14 (at least if it wants to generate the most efficient code).

MichaelGG 14y ago

OK that makes sense. So this would add to the scenario where you have a compute-intensive task, to disable HT? HT's more suited as another level of latency hiding, while one thread's stalled the other can work?

brigade 14y ago
It's pretty rare for a thread to completely stall in modern CPUs as you might imagine an in-order CPU doing, but it is common to achieve less than 1 instruction/cycle throughput out of a theoretical ~3-4 instructions/cycle in the frontend and 6 µop/cycle in the backend (Sandy Bridge). So another thread helps feed the execution units, even if the first thread has no classical stalls.