Reverse hyperthreading : 2 physical processors = 1 logical Processor

[TrinireturnofGamez]

  AMD's   replacement to the k8 architecture will include reverse hyperthreading , this will allow performance boosts for software that is not threaded enough to take advantage of large numbers of cores eg. 8 , by making the software ''think'' that several processors are actually one , much faster processor , thus allowing linear performance gains for older software without  forcing companies to spend money on recoding them . 
       
   
       Genius.....  why didn't intel think of that ? :p

link :

http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=fr_en&url=http%3A%2F%2Fwww.x86-secret.com%2Findex.php%3Foption%3Dnewsd%26nid%3D933

[TriniXaeno]

it sounds too good to be true!!!

[Spazosaurus]

That sounds very interesting. So much so that I beginning to think about holding back on upgrading until it comes out. The move to DDR2 isn't a very good inspiring upgrade factor but this reverse hyperthreading certainly is.

[TrinireturnofGamez]

  this won't be available till mid 2007 at least , ''the replacement the k8 core'' K9 , K10 , K8L or whatever its called will need to much die space to implement all its features on 90nm fabrication, but when 65nm is available to AMD , then we'll see the magic happen..
  Other technologies rumoured to be implemented are integrated PCI express controllers , L3 cache , SATA and RAID controllers etc .

[W1nTry]

Well its K8L since they scrapped K9 and K10. This reverse hyperthreading is interesting... basically hardware level threading... begs to ask, if you using 2 cores as 1, and the program is sequential (which is single threaded) then how exactly will the 2nd core benefit? I mean (1 of the paradigms of multithreading):
Let's say you have 3 threads A, B and C.
Thread B depends on thread A and thread C depends on B.
Even with 2 cores, thread A will only execute as fast as a single core can process thus thread B and C are waiting on thread A. Now I suppose if you're using the other cores to 'guess' the outcome of some calculations thread A on core 1 is doing it could help... but even so it not really gonna speed up really. So you still have Thread B waiting on A and C waiting on B. No amt of cores gonna help you with that really. But call me synical it could just me marketing, but I leave it in the hands of those geniuses and hope for the best. I am sure intel prolly thought of it... but maybe the feasibility isn't there or they figure its just not worth it to push singlethreaded apps since the future is multithreaded. I mean sure that (should it work) would help older apps. But consider it'll be out in wha 1-2 yrs time? i'd like to think by then we'll have much better multithreaded support and thus be phasing out the older apps.

[Czar]

Hmmm...while I agree that multithreaded apps will be at a better state in 1-2yrs, I still think that single threaded apps will be more prevalent, simply because they're so much easier to create. As much as AMD & Intel would like to push us towards the multithreaded goodness, it still rests on the lowly programmers to efficiently implement said goodness in their apps. Maybe if yuh last name is Carmack, yuh ridin cool, but otherwise, this is not something that Joe programmer can do with the flip of a coin. I hope to be proven wrong, but I honestly can't see it being any other way...at least not in the near future.

[W1nTry]

Well Czar all we can do is hope, wha yuh go do.

[Spazosaurus]

What about a processor that can adapt to which ever application is being run. For example, to a single threaded app, two ( or more) cores will appear as one and the multi threaded apps recognising the actual number of cores present. Best of bot worlds. Another thing...check it...how many people use apps made by Joe programmer? I know that I dont use many if any at all, but thats just me. Many of the big software manufacturers are likely to go te multithreaded route so maybe, just maybe more apps will be muli-threaded. Also with the ability to work either way, nprmal apps made by normal people will also be able to run optimally.

[Czar]

Well Czar all we can do is hope, wha yuh go do.

I hear that my brother...and hope I will...

[TriniXaeno]

I think rather than depending on John Doe Programmer to get his Multithreaded code write, we need to hope for a DirectX like implementation.

A bunch of API's that are themselves Multithreaded marvels. That way, the regular programmer only make calls to those API's and his app gets the benefit of your two CPUs.

on the other hand, I'm sure if it were that simple it would have been done already.

Maybe it's something we will see in Directx 12. lol

[Spazosaurus]

Hmmmm makes a lot of sense, but as you said, if it was that simple, it would have already been done.

[Beomagi]

       Genius.....  why didn't intel think of that ? :p

It's sounds simple, intuitive, but it's one of those "evil" problems. Analysing instructions in real time to ensure those in one pipe are exclusive to the other? Not easy at all. And i dont mean easy as in "hard to think of" I mean difficulty as in "feasability".

I'm certain once all companies saw the wall, everyone thought of that. In fact, Intel HAS thought of this AND published papers (Mitosis) but it's hampered by the current nature of processors.


See, no instruction is executed before the one after it has started being decoded (unless it's a branch misprediction)
in general, all instructions follow a sequence of analysis - Fetch-decode-Execute.
Today, due to stretching, those stages are stretched - 12 stage athlon64, 30 stage prescott, 14 stage conroe give or take a couple.
It's split up because each substage can run at a higher frequency than a large stage, thus letting you attain higher speeds.

In order for the second processor to execute instructions, any instruction sent to the second pipeline MUST be mutually exclusive to every instruction in the first pipeline.

Given the length of pipes, a misprediction can cause a loss of half the pipeline in cycles for the instruction to be executed, or just not add any speed if the instruction to be taken, is dependant on instructions in either pipeline. e.g. first instruction relates to ax. second to bx. third adds ax to bx and stores in ax. Such an instruction can cause a stall until both pipes execute the mutual instructions in either.

decoding a jump instruction would cause not only a flush on the first pipe, but on the second pipe, with the added difficulty on tracking which instructions came in after that jump.

You're talking about HEAVY modifications to the architecture - ability do do forwarding, register sharing to another pipeline - and then there's the simple fact that the next pipeline is farther away than the cache!

It makes much more sense as stated before, to rely on programmer not to half ass it, and hope engineers are smarter (that hardware complexity would just hold us back), but to make easier api's to handle threads.

[W1nTry]

Before Neo labels me with necroposting (since this thread is a few months old). This is an update to this article as Reverse Hyperthreading RHT is soon to be enabled on all AM2 and potentially some A64 X2's as well... take a read:

AMD Socket AM2 has a secret weapon

Expect wonder results with Reverse HT


By Theo Valich: Friday 23 June 2006, 08:58

THE LAUNCH OF Intel Conroe is scheduled to go on July 23rd, when partners will start rolling out the new products. The NDA for reviews is scheduled to expire around July 28th.
However, AMD has a counter-attack weapon hidden in its Socket AM2 infrastructure.

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. By combining two cores, the company has been able to produce the six IPC "core" that will go head to head against four IPC "core" from Conroe/Merom/WoodCrest combo.

It seems that in certain cases, even an old AMD Athlon 64 3800+ can wipe the floor with Core 2 Duo E6300 CPU.

As we all know - the results from E6700 and X6800 against FX-62 will be nice, but the real fight with AMD is the one for the Conroe with 2MB of L2 cache. The system memory avoidance technology is working flawlessly on a 4MB cache model, but the case is reversed in the two Meg cache variant, especially in cache-hit sensitive apps, such as games.

In single-treaded apps, Core 2 Duo is expected to struggle against Reverse HyperThreading CPUs, which work at higher clock frequencies and produce higher instruction per clock ratios (IPC).

AMDs Reverse-HT is a dynamic technology, and with Microsoft's Windows update and a new processor driver, the driver will copy the graphics drivers of today's 3D accelerators. The driver will detect the app, see if it is multithreaded or not and turn the ReverseHT on, or leave it off. µ

Everyone is touting Conroe, but until we see the performance gains of this hidden marchitecture, we're not sure how it will affect the benchies and real world performance of the dual cores... since more apps today (ESPECIALLY GAMES) are by far and lare single threaded... well AMD could well hold onto the gaming crown with this... 6IPC vs 4IPC... then factor in the 4x4 marchitecture they aiming at late Q4 2006-Q1 2007 i.e. the DUAL SOCKET AM2 dual core, or quad core rigs for the DESKTOP (NOT JUST SERVER MARKET). I'll post an article on that next. Things look to be heating up again folks... (not that it ever really cooled off in the first place).