Video encoding

Modest success of TB can be explained -- this group of tests includes programs that are mostly well optimized for multithreading. But response to HT varies greatly. We can forgive the old Canopus ProCoder its negative response (when this version was developed, Pentium 4 already forgot about HT, and there was no HT in Core i7 yet), but modern DivX demonstrates a very strange response. It's x264 who has to fight for the honor of the group: this codec with excellent multithreaded optimizations gains much even from Hyper-Threading. XviD also has a pleasant surprise in store for us, even though it didn't ace the test with varied number of physical cores.

Java

Everything lies on the surface in this test: SPECjvm responds well to growing the number of physical cores, we know it from our previous tests -- as you can see, it also likes virtual cores. A small effect from TB is essentially explained by the above said (we already mentioned it when we wrote about results in rendering and audio encoding groups).

3D games

Both the diagram and the table clearly broadcast one idea: bad luck. Neither the perfectly multithreaded World in Conflict nor the controversial Grand Theft Auto 4 (which still responds to the increased number of cores) reveal no optimism about HT. Moreover, Turbo Boost, which is often very effective when Hyper-Threading throws up the cards, is absolutely unimpressive in this case as well. Games belong to the most indifferent group to both boost technologies.

Conclusions

Everything is generally straight as a ruler: Turbo Boost yields 7%, Hyper-Threading -- 10%, both technologies combined -- 18%. So these technologies are generally useful: it will be very difficult to persuade anyone that technologies yielding 18% performance gains are harmful.

However, if you take a look at details (in case you have scrolled this article right to the conclusion, we strongly recommend that you should do it), you'll have a different impression: Hyper-Threading may sometimes go haywire even in applications well-optimized for multithreading, which perform decently with physical cores. In these cases we have an impression that the main objective of Turbo Boost consists in making up to such glitches rather than accelerating your computer, at least to avoid performance drops (by the way, performance drops cannot be avoided sometimes, quite often actually). It's very touchy that Intel has paired HT with a "stabilizing companion". However, Core i7 presentations interpreted Turbo Boost differently. ;)

On the other hand, our practical recommendations do not change: combined usage of HT and TB is justified, as we have seen many times that Turbo Boost comes in handy precisely when Hyper-Threading yields no results or goes haywire. Of course we can dream about some smart scheme to switch between TB and HT on the fly depending on which technology performs better at a given moment. However, this is something fantastical for now (for example, it's logical to assume that the OS scheduler may go crazy from frequent switching HT on/off). That's why it's generally reasonable to keep all technologies enabled -- perhaps one of them may come in handy.

Hyper-Threading is definitely a champion in terms of problems it creates. It's got much more "red cards" (performance drops) than Turbo Boost (in fact, TB has only one red card about a 1% drop, which can be explained with a measurement error). On the other hand, HT is much more useful (when it really works). Some unity and struggle of opposites: generally more useful HT is also harmful more often. We've already explained why: when HT is enabled, resources of a single physical core are shared between two virtual ones (sometimes in half, not dynamically). As a result, performance of one virtual core may sometimes be objectively lower than that of a physical core.

However, we still have to establish a fact that some results of our today's experiment cannot be explained. It does not mean that Core i7 has some built-in randomizer that controls performance. It's just that a modern processor is a complex device. And when each of its physical cores has to form two virtual ones (eight in total), clock rates of each pair controlled dynamically, we cannot even imagine how many "funny" situations may emerge. It's possible to calculate them all, but it will take so much time, that we may barely make it by the time this series is discontinued. So it looks like we'll have to get used to the idea of floating performance.

In general, Intel has probably succeeded here. Both technologies are sometimes buggy, but there are no reasons to disable them for good -- on the contrary, they should be perfected and their drawbacks should be rectified. We are also sure that it's impossible to get rid of all their drawbacks -- complexity of HT without losses will get close to two physical cores. However, if we don't get distracted by nuisances, we'll see that the current implementation is not bad at all.

The next article in this series will be devoted to another detailed analysis of Hyper-Threading. We'll try to simulate a situation with the most transparent conditions and then see how it will perform there.

Write a comment below. No registration needed!