AMD reverse multi-threading tech 'does not exist'
Someone misunderstood virtualisation?
AMD is not working on technology to allow a multi-core processor to emulate a single-core chip, it has been claimed by reports citing sources close to the company. The claims contradict alternative allegations that maintain the chip company has been working on just such as system.
Source cited by Xbit Labs and another by VNUNet claim AMD isn't working on the technology - which both maintain does not exist. One said it represents a misunderstanding of another technique, though (s)he didn't elaborate.
Maybe it's something AMD looked at but rejected. We can see why it might. The idea's a simple one: if simultaneous multi-threading (SMT) technology makes a single core operate like a double-core part, you can come up with a system that operates backwards, making the two cores appear to software as one. Intel calls SMT HyperThreading, so the technique has been dubbed by some 'Reverse HyperThreading'.
It's said to be about giving games, which are traditionally, but not exclusively, single-threaded apps. In fact, there have been multi-threaded apps for years - the Mac release of LucasArts' Dark Forces, to name but one - but that doesn't appear to matter to the folk touting Reverse HT as a panacea for games.
SMT improves the performance of a processor not by making it appear as two CPUs per se but by using this technique to keep as many arithmetic units in operation at any one time. The easiest way to reverse this on a dual-core chip is simply to turn off one of the cores. This is possible now.
It's also unnecessary. Modern operating systems juggle multiple processes each made up of one or more threads. The more cores to share between all those threads the better. If one process - the game, say - has but a single thread, it's still running alongside plenty of other threads, and they all need to be spread across the core resources available. Many will take up no processor time, because they're effectively sitting in the background waiting to be told by the OS that they've got some user interaction to deal with. Some, however, use up CPU cycles anyway.
They'll do so whether the CPU has one apparent instruction pipeline or many, and the OS will still have to switch from active thread to active thread. If the user turns off as many of these threads as possible, the game gets more CPU time, but the dual-core CPU - even one masquerading as a single-core part - will have to deal with an number of threads simultaneously.
Ultimately, the only way Reverse SMT works is if the OS' scheduler can split a given thread into two parts, one for each core, allowing you to, essentially, do twice as much work in a given time-slice. Which is the definition of parallelism. The question is, is it more efficient to do it this way than simply allow the OS to use both cores and schedule threads accordingly? Only research will provide an answer and then any gain - if there is one - for Reverse SMT has to be weighed against the cost of implementing it in silicon and the OS.
A better route might simply be to leverage virtualisation or similar techniques to run a game's thread on a single core, while leaving the other core to handle all the other threads. But since we are, very clearly, moving into a multi-core world, it makes more sense for game developers to embrace the change than to stick to the old ways in the hope chip makers will come up with technology to ensure single-thread games don't get penalised.
It makes more financial sense for AMD to encourage and assist games developers to transition to multi-threaded code than develop technology to allow software writers to delay the inevitable a little longer. ®
Read our review of Intel's Core 2 Extreme and Core 2 Duo processors here
Sponsored: DevOps and continuous delivery