There is one more thing about hyperthreading that I would like to comment on. I understand why one might think of "HT" as a "kludge", but I'd like to suggest another way of thinking about it. When I first started to read about HT I saw it as a creative way to drive incremental performance out of an existing processor architecture, and a natural progression in thinking. Consider:
1. Very early CPUs could only execute 1 instruction at a time. A good example of this was the CPU used in the early Univac 1108.
2. As time went by, processors were designed to enable the execution of multiple instructions in a single cycle. The restrictions were: All instructions had to be from the same thread; none of the instructions in the group could have a "conditional jump" instruction; none of the instructions could need access to the same processor resources. This parallel execution was referred to as a execution "stack" or "pipeline" and violating any of the aforementioned rules was sometimes referred to as "breaking the stack". When hand-coding assembler routines the mantra become "don't break the stack", as getting it right significantly improved performance. This type of architecture was available on the Univac 1110.
3. Somewhere along the way Intel processors leveraged the concept of "predictive branching". In this scheme, instead of a "conditional jump" always breaking the stack, or pipeline, the processor would attempt to predict which way a conditional jump would go. If it was right, the stack would continue to execute. If it predicted incorrectly, part of the results computed would be discarded and instructions re-executed. Please don't ask me which machine / processor introduced this -- that would stretch my memory way too hard  .
4. HT seemed like a natural progression of this type of work. In essence they allowed parallelism to now span multiple threads and replicated a very small subset of the processors resources to enable parallelism under certain circumstances. As the wikipedia article below indicates, in exchange for a 5% increase in die area, certain application mixes could achieve a 15% - 30% increase in performance. In my case, I saw a 40% increase in performance when it came to decoding and displaying HD video.
An interesting question is: What is the future of HT? Design and manufacturing advances have made it possible to produce true SMP processors at very low prices, so my guess is that HT becomes less interesting, perhaps to the point where you don't bother to support it anymore. I know my dual-core Pentium-D processor does not support HT. On the other hand, I read somewhere that intel will re-introduce HT into its multi-core architecture.
Marc
http://en.wikipedia.org/wiki/Hyper-threading
Quote: The advantages of Hyper-Threading are listed as: improved support for multi-threaded code, allowing multiple threads to run simultaneously, improved reaction and response time.
According to Intel, the first implementation only used an additional 5% of the die area over the comparable non-hyperthreaded processor, yet yielded performance improvements of 15–30%.
Intel claims up to a 30% speed improvement compared against an otherwise identical, non-simultaneous multithreading Pentium 4. The performance improvement seen is very application-dependent, however, and some programs actually slow down slightly when Hyper Threading Technology is turned on. This is due to the replay system of the Pentium 4 tying up valuable execution resources, thereby starving the other thread. (The Pentium 4 Prescott core gained a replay queue, which reduces execution time needed for the replay system, but this is not enough to completely overcome the performance hit.) However, any performance degradation is unique to the Pentium 4 (due to various architectural nuances), and is not characteristic of simultaneous multithreading in general.
|
