AMD's Reverse-HyperThreading

[demonic]

"It seems that all AM2 CPUs were outfitted with a support for Reverse-HyperThreading, an architectural change which enables software to think that it is working on a single-core alone."

http://www.theinquirer.net/?article=32589

---------------

Is this real? I havent seen anything like this on other forums (maybe I have been under a rock lol) - Also, how viable is this. Will it work on only certain applications, or does it have a broad spectrum of support?

Personally, for Dual and Quad CPU's. I see the way of manually assigning threads i.e MPEG Conversion on 1, Winamp on another, CD Burning on Another and playing a game as just a gimmick. Its just enabling you to do more, not leveraging the architecture.

When we move toward towards an 8 Processor Desktop Box, which will win out. An Architecture like Ps3, Cell Programming? Or Applications knowing if Multithreading is available. Or this AMD solution. Where load balancing comes into play?

Oh and if AMD's solution does work. Can we say goodbye to CPU bound situations with games?

 

[Xentropy]

The rumors have been around for a while now, but still no official information. It is starting to look like there might be something to the rumors though, since there are so many of them now.

Don't expect a direct scaling with the number of cores when using single threaded apps. Of course, if we even get 20% average performance increase, that would be pretty impressive to me.

 

[nutball]

I dunno, I've seen a few comments from more clued up people to the effect that it's all a load of nonsense. Personally I think it's a combination of Chinese whispers plus a general unwillingness to believe that AMD won't have something available in the short-term that will halt Conroe in its tracks.

 

[demonic]

I also found this : http://news.taborcommunications.com/msgget.jsp?mid=536014&xsl=story.xsl

 

[nutball]

APO? Ummm, yeah wake me up when it works on all but the most trivial workloads.

 

[3dilettante]

I'm not sure about the general usability of this.

In theory, if a thread has a lot of ILP (and nothing unexpected happens), then there is (relatively) little penalty in throwing parts of it on the other core and just pretending they went to the same place.

The big problem of course is that it's not that simple. AMD has discussed clustered multi-threading, where clusters of execution units that run the threads can in a pinch "borrow" another cluster's units. It would be transparent to the programmer, but any sharing would incur costs.

Any instruction that gets sent across whatever network that shares units will have a delay of several cycles (going and coming back, heaven forbid there's also an exception or mispredict).
If the thread is very heavily loaded, and it is very time-sensitive this can be a win. For example, if the thread in question has a lot of data that is absolutely needed for other threads to proceed, it's a win.

What this story seems to say is even more aggressive and rather dubious.
Execution would be scheduled as if the two processors are a single twice as wide core. The problem is that dependency tracking, branch prediction, and exception handling wouldn't be so easily shared.

If instruction A goes to core 0 and instruction B goes to core 1, but B needs A's result, something has to be done to halt execution. But that requires expensive communication,(probably the equivalent of several processor cycles for communication alone). If there are a lot of those depenencies, then the stalls will happen very often and it would have made more sense to schedule work on a processor half as wide that takes twice as long than a pair of processors pretending to be one twice as wide that takes three times as long.

Branches and exceptions would also be a problem, since the cores would have to devote logic and cycle time to driving this sharing.

It could work in the case of rare, long latency instructions(floating point divide, transcendentals), or highly parallel straight line code, because a large amount of the overhead could be hidden by the longer execution times of the instructions or a lot of extra work.

Fast additions and shifts wouldn't offer enough of a cushion to hide overhead or cleanup work.

 

[hoom]

Hoping to find more info, I googled & one of the sites somebody had posted this AMD patent
(Forgot which site that came from though)

Sounds much like demonics link & also seems related to earlier Inq article where some tech guy was pointing out changes in the out of order buffer area on the AM2 chips vs socket 939.

 

[tmp]

From what (very little) I have read about it, this "reverse hyperthreading" is some extra instructions to help with fine grained and low overhead threading.

e.g. in case of A(B(), C()); where there are no dependencies between B and C, function(or code block inside a function) C could be kicked on its' own core. This requires compiler support, and I believe Intel is working with something similar.

Take this with an approximately football sized grain of salt, it's likely to be completely wrong.

 

[ANova]

Intel has been experimenting with the idea behind AMD's "anti-hyperthreading" for awhile now as well, it's code named Mitosis and some think it may already be implemented into the Core 2. The Core 2 Duo will also have a feature called Core Multiplexing which appears to allow you to disable one or more of the cores while the remaining has access to the entire shared L2 cache.

 

[Fox5]

Intel has been experimenting with the idea behind AMD's "anti-hyperthreading" for awhile now as well, it's code named Mitosis and some think it may already be implemented into the Core 2. The Core 2 Duo will also have a feature called Core Multiplexing which appears to allow you to disable one or more of the cores while the remaining has access to the entire shared L2 cache.

That's not the same though and I think Core Duo already has that.

Anyhow, the rumors about AMD haven't been an automatically multithreading compiler, but rather it seemed more related to branch prediction. One processor would run one branch in code, while the other processor would run the other branch, and the correct one would continue running, thus adding just a bit more efficiency to the already >95% accurate branch predictor.

 

[ANova]

Mitosis != Core Multiplexing

 

[Moloch]

http://www.theinquirer.net/default.aspx?article=32790

 

[tEd]

http://www.theinquirer.net/default.aspx?article=32790

I think this mainly helps on application which had problems with dual-core cpu's where before you had to manually put them to a specific core to run normal

 

[hoom]

And then ***poof***
http://www.theinquirer.net/default.aspx?article=32885

The Inq he gives and The Inq he taketh away

 

[demonic]

Alright, well my question still begs.

Soon we will have 4 cores on 1 chip. Someone throws out a dual board. That could potentially be 8 cores in 1 box.

Can we realistically see all applications one day being multi-threaded. Or will we see a more Cell like approach?

I just cant help seeing a situation where out of those 8 cores in 1 box. Only 1 core will be fully utilised. What a waste.

 

[hoom]

Well yeah, it seems odd that there would be patents & a competing intel product for something completely baseless.
Perhaps its just the 'makes it look like one processor' bit that doesnay exist, reality being a more subtle speculative use of 2nd core when there is spare processing.