Intel's Hyperthreading won't make much of a difference

INTEL'S 'core hopping' technique for improving the performance of multi-core CPUs, discussed in an interview with Intel Labs technical director Wilf Pinfold over on Cnet, isn't half as smart as the interviewer seems to think it is.

The idea behind the technique is simple enough, and certainly sounds plausible: you take a multi-core CPU and dynamically switch instruction threads between each core to ensure that the die doesn't experience localised temperature rises that impair performance. So if an instruction thread is making particular use of integer units, flipping the thread between each core prevents any one of them from over-heating. The upshot: the chip stays cooler and Intel can clock it higher.

But we doubt it will make much of a difference. An instruction thread might well favour one kind of execution unit, but who's to say the other threads, the ones that are running in parallel with the 'troublesome' one, won't be favouring the same execution units? Assume you've got two cores per die, and that's two threads running simultaneously. Chuck in Intel's much-touted HyperThreading technology and you'll have four threads being processed in parallel, two per core, all being 'hopped'. Chances are that at least two of them will be using the same execution units, so swapping them round isn't going to change anything.

It's like swapping the contents of two honey jars - you still end up with two jars full of honey. That's fine if you're Pooh Bear, but not much help if you're trying to moderate processor temperatures.

At gigahertz speeds, is there really time for the circuitry to cool sufficiently before the instruction thread has hopped back to where it started? The point is, the core's going to be darn hot, no matter which execution units the running thread is using.

So why is Intel talking about the idea at all? With the company moving to 0.09 micron lithography next year, it's going to have a lot more transistors to play with. You can only add so much cache RAM to a core before the benefits gained from having close, fast temporary instruction and data memory tail off. Bung on the requisite meg or two of on-die L3 cache, and you're still looking at plenty of left-over real estate.

Going multi-core is an obvious way to improve performance, as IBM has already demonstrated with the Power4. Why have two virtual processors on your die - the theory behind HyperThreading - when you can have the real thing? HyperThreading made sense when the thermal characteristics of 0.13 micron transistors limit clock speed increases, so you can do more processing at a given clock speed, but as new, more condense lithographies come on stream, the thermal characteristics change again, allowing to continue chanting its mantra - altogether now - 'gigahertz... gigahertz... gigahertz...'

The jury's still out on whether HyperThreading delivers much of a performance gain. Even Intel's figures aren't much to write home about - it certainly doesn't turn a single-processor machine into a dual-CPU rig, or double-up a two-processor box into a four-way system.

Adding extra processor cores, on the other hand, will make a difference and remains the best way to increase system performance, whatever the size of your transistors. The trouble is, with IBM already shipping a dual-core processor, Sun rumoured to have a multi-core UltraSparc in the works and some pundits saying that's what AMD has in mind too, Intel will just be playing follow-the-leader. Core hopping, given a suitably hi-tech brand name (Streamlined Highly Integrated Threading? Threads Over Several Superscalars? Quantispeed?) will, like HyperThreading, allow it to claim an edge. µ