2 ms·
True, but then the point the original article makes kicks in: that's a relatively poor way of doing things. Originally HT was supposed to be transparent. Then i
by Confusion 17y ago
True, but then the point the original article makes kicks in: that's a relatively poor way of doing things. Originally HT was supposed to be transparent. Then it turned out the abstraction wasn't quite as good as they hoped and OS level support was needed. That adds a lot of complexity and possibilities for mistakes. At that point, they should have dropped HT and go for actual cores instead.
- neilc 17y agoOriginally HT was supposed to be transparent. According to whom? I don't think anyone with a clue would have suggested that. If you care about writing high-performance code, you care about the behavior of your processor. Obviously, multiplexing the execution of two program threads onto a single physical core is going to affect performance, whether in the form of scheduling differences, caching effects, etc. they should have dropped HT and go for actual cores instead. Well, you can do both, of course. If HT gets you better utilization of a single core, then fair enough. The question is really whether the transistors/power you burn on HT would be better spent on additional cores (or bigger caches, etc.).