CPU Cache Flushing Fallacy

Re:CPU Cache Flushing Fallacy by MichaelGG on Thursday February 14, 2013 @12:49PM (#5220687)

"When hyperthreading is enabled these registers are shared between the co-located hyperthreads."

How does that work? I thought each HT had its own registers - otherwise, wouldn't that add a lot of complication and overhead? And does that mean if I disable HT, a program can double the available registers? Wouldn't that need different machine code?

[ Parent | on HN ]

Re:CPU Cache Flushing Fallacy by brigade on Thursday February 14, 2013 @01:28PM (#5221004)

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.

[ Parent | on HN ]

Re:CPU Cache Flushing Fallacy by tbrownaw on Thursday February 14, 2013 @02:16PM (#5221412)

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.

[ Parent | on HN ]

Re:CPU Cache Flushing Fallacy by jules on Thursday February 14, 2013 @02:28PM (#5221513)

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.

[ Parent | on HN ]

Re:CPU Cache Flushing Fallacy by brigade on Thursday February 14, 2013 @03:40PM (#5222060)

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.

[ Parent | on HN ]

Re:CPU Cache Flushing Fallacy by jules on Thursday February 14, 2013 @04:25PM (#5222445)

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).

[ Parent | on HN ]

Re:CPU Cache Flushing Fallacy by MichaelGG on Thursday February 14, 2013 @02:38PM (#5221599)

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?

[ Parent | on HN ]

Re:CPU Cache Flushing Fallacy by brigade on Thursday February 14, 2013 @03:52PM (#5222179)

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.

[ Parent | on HN ]