Xbit reports on anti-HyperThreading technology

[Smalltimer]

AMD to Boost Single-Threading Performance on Multi-Core Chips

SourcesSay - AMD to Launch “Anti-Hyper-Threading” Shortly

Advanced Micro Devices may offer gamers something, which significantly boosts performance of single-threaded games with its new central processing units (CPUs) in socket AM2 form-factor, the sources claim.

In April 2006 some rumors emerged that AMD was working on the technology designed to boost performance of single-threaded applications on multi-core processors. According to certain sources familiar with AMD plans, the company is going to offer their own technology that will work in an opposite way to what Intel Hyper-Threading does: it increases performance of dual-core chips in single-threaded applications. If the latter splits resources of a single physical processor core, then AMD’s new know-how will allow combining the resources of the two physical cores to speed up the processing of tasks that work in the most optimal way on single-core CPUs, according to sources.

According to sources, it would be possible to double the number of decoders this way so that the “combined: CPU will process 6 instructions per clock cycle. This thing only can become a pretty decent response to Conroe processors and it should be expected that this technology would debut closer to July 24, the day of the Intel Core 2 for desktops launch. But the feature should require synchronization of chips’ L1 cache in general along with some other capabilities. Perhaps, the new technology will simply overclock the processor and disable the second core in certain situations.

The corresponding functionality has already been built into dual-core Athlon 64 X2 processors for Socket AM2 form-factor, the sources claim. To activate it customers will “only need to update the processor driver and the mainboard BIOS,” they say. Microsoft Corp. will reportedly even release a corresponding patch for the operating systems that will allow recognizing two cores of the Athlon 64 X2 as a single one.

According to sources and alleged preliminary test results, the CPU will be able to switch into this “combined” mode dynamically, depending on the type of the application. There is no secret that a lot of tasks still benefit from single-core CPUs more than they would from the dual-core processors working at lower nominal frequencies.

It is remarkable that at the same time AMD will also push forward their 4x4 platform for enthusiasts who cannot imagine their life without multi-tasking and absolutely extreme performance. It seems that these two completely different initiatives will be positioned in different market niches. At least the owners of socket AM2 Athlon 64 X2 will be able to put two cores into a single virtual one for free if we do not consider downloading the new BIOS and OS driver that much of a trouble.

Full Story

[VulgarHandle]

well, seems all the news/review sites seem to believe it...wish we could get something official from AMD, digitimes wasted an opportunity to ask Henri Richard(unless they didn't know to ask at the time of the interview)

[Motiv]

Just the same rumour that been around for a couple of weeks. As the previous poster as said, until someone from AMD can say something it's just hype and misdirection prior to the woodcrest/conroe release.

[gOJDO]

this was allready posted, there was a debate and the thread got locked and deleted

[Cooper]

Repost
Let`s behave on discussion in this thread, shall we ?

[Smalltimer]

Well I for one hope its true, although like most people I am sceptical of the entire gig. There is still room that this could be real and if this is the case then it would explain the AMD execs stance on the Conroe solution during the last trade show

[Smalltimer]

Here is an exerpt from overclockers.com.

I would like to caution that this publisher has earned a reputation as emotionally charged when writing on technology and usually meaningless contrasting results. However his columns often post decent infrormation sources.

AMDZone reports that Overclockers.ru has an article saying that reverse hyperthreading is possible on current AMD AM2 chips and that it will debut right after Conroe.

The article goes on to say that this feature will be enabled with just an MS driver and a BIOS change.

We have two observations:

1) We doubt this is going to even come close to doubling the capabilities of a dual-core AMD system running a single-threaded application. What this technology appears to do is make two CPUs look like one bigger processor, sort of like making two Intel chips look like an Itanium. It doesn't parallelize anything: if the application can take advantage or more decoders or in-flight operations or simultaneous processes, great, if not, not.

Such a generic approach can hardly be optimized for specific apps (though perhaps apps can optimize their code eventually).

But then again, anything helps, but . . . .

2) If this is so easy, why can't the same thing work for Intel chips, too? Not saying it has to work, or would work as well, or might need a different driver and/or BIOS tweak, but until we get a detailed explanation otherwise, one ought not exclude that possibility.

Even if there is a hardware reason built into the AM2 chips that would enable this, even in the worst case scenarios, it probably would take little to enable Intel chips, indeed, it would be surprising if next year's Kentsfield didn't have such a feature (provided it actually helps to more than a nominal degree).

What To Think?

This is one of those "you'll find out soon enough" situations. Best guess is that one of two things will happen:

# AMD will announce this, they'll say it helps a few programs a lot, then in a day or two, some testing will disclose that that's pretty much all it does, or

# AMD will announce this, it actually does help more than help a few programs, but Intel duplicates the feat either immediately or fairly shortly thereafter.

This smells like a stunt, at least for the short-term. Not that the concept might not yield real benefits down the road, but like x86-64 (or for that matter hyperthreading), this is going to need software aware of and optimized for the new environment.

If this truly were an OMG, 50% or even 25% improvement, believe me, AMD would be loud and proud about this. They certainly wouldn't be submitting itself to Intel's Conroese water-torture routine, and if you think AMD is keeping this quiet just to spring a big surprise on Intel, well, first, the cat's been out of the bag since April, and second, you've been watching too many movies and/or pro wrestling and/or fairy tales, but I repeat myself. Too many people outside of AMD would have to know about this, and people talk.

[VulgarHandle]

Here is an exerpt from overclockers.com.

I would like to caution that this publisher has earned a reputation as emotionally charged when writing on technology and usually meaningless contrasting results. However his columns often post decent infrormation sources.

while the overclockers.com excerpt is well written, isn't it bad enough that we have to speculate on wether or not it exists, much less speculate what benefits it will have

i mean, i've read threads on how it CAN'T exist, threads on how it's possible but not plausible, and now, if it does exist it won't be that good

his point that heavy multi-taskers won't benefit too much, this is somewhat true, but even multi-taskers run single-threaded apps, and people who use multi-threaded programs most likely also use single-threaded apps, so they will benefit...

one of these articles even says multi-threaded apps will benefit, simply because if the multiple threads get divided up among the cores, and 1 core is being used more than the other, RHT would kick in and divide up a thread to be processed on both cores...again, benefit

of course, like the oc.com exerpt, it's all speculation

this discussion is limited to 'we need official word' and 'possible benefit' when discussing AM2 in general

[nn_step]

you have to remember Doubling the IPC is not going to double the Performance.
however a 40% performance increase isn't too much of a stretch.

[WiCKeD]

Did this rumor start around 4/1, by any chance?

If it is true, Intel won't duplicate, for the same reason Intel did not rip off the on-die mem controller or AMD did not steal the original hyperthreading - patent law.

Personally, I don't see how it could work. The chip processes an instruction that moves through it's pipeline and spits out the result. The only way I can see it working is if the second core shared the L1 cache and used branch prediction to guess the correct result and continues on to the next instruction. For the most part, I would think that would result in redundancy and a minor increase? So essentially, you would need to interrupt the 14(?) pipeline stages and have the second core work on the next stage. If you wait until the core runs through its stages, all you would be doing is switching back and forth between which core is used, which accomplishes the same thing as a single core processing the same thread.

[uOpt]

This is research technology from the 90ties. I bet there'll be no significant difference between what AMD and Intel are doing. The results will be different because of different cache design and a few other factors.

Here's a shameless repetition of what I posted in one of the other threads on the topic.

At work I talked to some guys who worked on this concept in in the 90ties. Their IRC comments are not enthusiastic.

I didn't find anything specific about AMD's solution, but from the Intel paper this will be very limited. The problem is that you can execute a single thread in parallel only as long as the additional branches do not "commit", aka write to memory. You can only allow one thread to write to memory after you can prove from the other threads that this thread actually had a right to execute to this point.

The whole point about this speculative execution is that you execute code that you do not know yet whether it is actually what the program wants to execute. If it turns out that this thread had no business going there you just disgard the results it computed. But that's the catch, it means you can speculatively execute one thread only as long as it doesn't commit to memory. Every speculative thread that tries to write into memory must be stopped until it can be proven that this speculative thread was actually real.

In addition, there is severe cache synchronization overhead as prove threads commit and modify memory that unproven threads use. These threads will be on different cores in different L1 and L2 caches (most likely the L2 cache is disabled entirely on cores executing speculative threads).

But the code has not been written with caches in mind. If you have good multithreaded code then people are careful to keep the data that the different threads use on different cache lines, to keep the locks a cache line away from the data they protect etc. If you try to execute a program in parallel that was not meant to be parallel it will not have any of that.