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