Compiling

These results are similar to what we saw on the quad-core system.

Audio encoding

Ditto. The single- and quad-core systems demonstrate similar results in this group of tests.

Video encoding

The "red cards" obtained in Canopus ProCoder and DivX disappeared, and the average performance gain from HT in this group is twice as high.

Java

21% performance gain from HT is a very good result. Note that our Java benchmark behaves in different situations just like the compile test.

3D games

Grand Theft Auto 4 sticks to its brand style, responding to HT with a 50% performance gain. The second core yields 142%. We have an impression that the game has sort of a switch: to work slowly in case of one core, and to speed up in case of two or more cores! Far Cry 2 handles multiple physical cores well, and it also favors HT. Another two games with good multithreading optimizations -- Unreal Tournament 3 and World in Conflict -- unanimously reject this technology. It's an indirect proof of the simple thesis that a program with really good SMP-optimizations cannot benefit from multiple virtual cores because of its optimizations. Essentially (using idle execution units), HT must be more disposed to the raw messy code. On the whole, HT gains in games amount to 6% -- not a very good result.

Conclusions

So what have we got here? The second physical core gives us 39% on the average, Hyper-Threading -- about 12%. That's the answer to the question about the ratio: a virtual core is approximately 1/3 of a physical core.

In order to answer the question about scalability of Hyper-Threading we don't even need to run additional tests "2 core HT ON", as we can compare performance gains from HT with a single core (this article) with HT gains with four cores (previous article) -- this will suffice. Why is it enough? It's because performance gain with a single core is ~11.8%, four cores -- ~10.2%. The difference is 1.6%, that is there is nothing to speak of: from 1 to 4 physical cores, HT scales practically perfectly, and Intel has no plans about 6-core desktop CPUs yet (extreme modifications are not usual desktop models -- just as Lamborghini is not a passenger car).

However, we expected better results. Having seen a 10.2% performance gain with a quad-core processor, we actually expected at least 20% with a single core. Alas, it did not happen. When you already know test results, it makes no sense to speculate whether it's good or bad -- facts are neutral. We feel sorry for the dream: if HT efficiency had raised significantly when the number of cores is decreased, we might have hoped to see dual-core CPUs with HT support from Intel in the nearest future to be positioned as an alternative to cheap honest quad-core processors from AMD. Considering generally higher performance of the new core from Intel per MHz -- why not?

However, 10-11% advantage, provided by HT, won't be enough for the virtual quad-core processor to compete with a real one. So from the point of view of providing a real performance advantage, Intel has no objective incentive to promote Hyper-Threading to Low-End. HT does not provide a sufficient performance gain to help expensive (relative to dual-core processors from AMD) dual-core processors from Intel to stand up to cheap (relative to quad-core processors from Intel) quad-core processors from AMD. However, pointlessness from the practical point of view does not at all mean that omnipresent marketing specialists won't try to use this resource.

However, there is another conclusion suggested by results of these tests. Indeed, 11 "red cards" for performance drops in HT tests with four physical cores have magically turned into two cards in our tests with a single core. But this technology hasn't changed: because we use the same processor. So our conclusion is quite optimistic: perhaps the problem is not in the hardware optimization of Hyper-Threading. It's reasonable to assume that Windows Vista was so stupefied to detect eight processors that its task scheduler just couldn't cope with such an abyss of new opportunities. At least this explanation to so many HT failures with an 8-processor system (from the OS point of view) seems the most logical to us. So if we take this as a working hypothesis, the problem is in system software only, and the situation can be improved without changing the hardware (that is it's not Intel's fault).

However, despite the problems described above, it seems to us that R&D engineers from AMD feel envious about Hyper-Threading deep in their hearts. Even if we ignore the pure marketing aspect (doubling the number of cores from a user's point of view), it's still a jaunty, elegant, and probably inexpensive solution. It generally provides at least a 10% gain to real performance without increasing the number of physical cores, cache, or frequency! They simply must be envious... As always happens in such situations, we are rationally optimistic: SMT (HT is its special case, and the very concept was not invented by Intel, by the way) has proved up, so all leading manufacturers of modern x86(64) CPUs will adopt this technology sooner or later. It would have been silly to miss all "free-of-charge" bonuses out of pride, wouldn't it?

P.S. In the end we suggest that all curious readers interested in the history of modern x86 CPUs should take a dive into 2002, when it all started.

Write a comment below. No registration needed!