Speculative Multithreading CPU-AMD Have Done It Already.

[Parrot]

All the doubters are in for a SHOCK!! 8O
If people ask NICELY, I will consider providing more details and a link!! :roll:

Download PDF of patent here:http://www.pat2pdf.org/patents/pat6574725.pdf

 

[Caboose-1]

Didn't know there were that many doubters...

 

[K8MAN]

All the doubters are in for a SHOCK!! 8O
If people ask NICELY, I will consider providing more details and a link!! :roll:

Plz elaborate more oh all knowing.

 

[Action_Man]

Thanks for that sock puppet.

 

[Bluefinger]

Thanks for that sock puppet.

Sock puppet?? where?! WHERE??!!! D: *dives behind sofa*

 

[Action_Man]

The Simpsons call FTW.

 

[Bluefinger]

:lol: You just can't beat the Simpsons

 

[S7A88Y]

WTF are you talking about. Seriously there arn't any doubters, IBM has already done it with there servers...AMD has IBM's R&D team...Are you hi?

 

[MoNeY3865]

He's refering to a previous thread on this topic where a bunch of posters wouldn't accept the fact that this technology is not only possible but currently used in other applications.

 

[kg4icg]

Not to be the one who throws a wrench into the gears, but you guy's do know hyperthreading is Intel right? Don't you mean Hyper Transport?

:twisted:
R Collins

 

[Action_Man]

No reverse hyperthreading not hypertransport.

I don't why the AMD fanboys are so excited, Intel's working on it too and probably started work on it before AMD did.

 

[Bluefinger]

No reverse hyperthreading not hypertransport.

I don't why the AMD fanboys are so excited, Intel's working on it too and probably started work on it before AMD did.

Eh, it'll probably end up being a battle on who can bring out a reverse hyperthreaded CPU the quickest. The same happened with 64-bit CPUs. Intel brought out Itanium, but it flopped since it wasn't x86 compatible, and AMD brought out a decent desktop 64-bit CPU after Intel. Same shit happens again and again, but hey, its business.

 

[Action_Man]

I wouldn't exactly compare it to that.

 

[joset]

Hello, Parrot!

Seems you're missing a link (a species one?!):

http://www.anandtech.com/printarticle.aspx?i=2507

The Mitosis project relies on both hardware and software (compiler) support to work. First, on the software side, blocks of code that have very few inputs and outputs are detected and considered for use as a separate thread. The entry and exit points of the current working thread are marked, and the portion of the thread that would be split off is separated. The new thread is then fed the appropriate input data that it needs to begin its execution. With the single thread now split into two threads, they are both sent to the multi-core processor and executed in parallel. At the end of the execution of the thread, its result is checked to make sure that the data is still valid, and if so, the result is committed and all is well. If the result is invalid the thread must be thrown away, but since we're talking about a single threaded application to begin with, there is no wasted performance, only wasted power as the core this thread was running on would have been idle had it not been for the speculative thread generation.The inclusion of a global register file and a register versioning table to keep track of which cores have the latest and most correct register values is necessary. You also need some additional logic to help validate the outcome of these threads.

The end result of all of this is pretty promising, especially for single threaded applications that would otherwise get no benefit from being run on a multi-core CPU.

A little deeper... http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm

... deeper still... http://www-cse.ucsd.edu/classes/fa05/cse231/Porter.pdf (Damn! This one's seems like a car accident...)

... and, clash?!


Cheers!

 

[BaronMatrix]

After 8+ weeks of thinking about it I finally figured it out. It's actually kinda simple in a complex sort of way. One way is to mark async calls and run them on a second proc (spell check on Proc A, grammar check on Proc B) or to separate class methods and run some methods on Proc A and some on Proc B ( Class A has Method A, Method B Method C, Method D Method E. Method A calls method B, Method C Calls D which calls E.

By running Method A on Proc A, and Method B on Proc B, if they are independent and synchronous, the process will run faster - an example would be a game where physics code can run on one chip, rendering methods go to another, joystick feedback can run on another, internet connection, (all have entry points). SInce every app has a main thread it would be possible to mark methods with Proc Affinity with a low level header. When programs load paths are computed and affinity is assigned to each entry point with independent results. Of course devs would have to do SOME of the work but it's a good tech for improving the "single threaded" code paradigm.


But then I could be wrong.

 

[Bluefinger]

I wouldn't exactly compare it to that.

Eh, I know its not the best of comparisons, but I couldn't think of anything else :?

 

[Ycon]

Who the heck would like reading about the most useless "technology" ever? :lol:

 

[BaronMatrix]

Hello, Parrot!

Seems you're missing a link (a species one?!):

http://www.anandtech.com/printarticle.aspx?i=2507

The Mitosis project relies on both hardware and software (compiler) support to work. First, on the software side, blocks of code that have very few inputs and outputs are detected and considered for use as a separate thread. The entry and exit points of the current working thread are marked, and the portion of the thread that would be split off is separated. The new thread is then fed the appropriate input data that it needs to begin its execution. With the single thread now split into two threads, they are both sent to the multi-core processor and executed in parallel. At the end of the execution of the thread, its result is checked to make sure that the data is still valid, and if so, the result is committed and all is well. If the result is invalid the thread must be thrown away, but since we're talking about a single threaded application to begin with, there is no wasted performance, only wasted power as the core this thread was running on would have been idle had it not been for the speculative thread generation.The inclusion of a global register file and a register versioning table to keep track of which cores have the latest and most correct register values is necessary. You also need some additional logic to help validate the outcome of these threads.

The end result of all of this is pretty promising, especially for single threaded applications that would otherwise get no benefit from being run on a multi-core CPU.

A little deeper... http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm

... deeper still... http://www-cse.ucsd.edu/classes/fa05/cse231/Porter.pdf (Damn! This one's seems like a car accident...)

... and, clash?!


Cheers!


So I was right, huhn? Hooray for me.

 

[JonathanDeane]

My insomnia demands I post ! lol I remember speculative branch prediction from waayyyy back (used to read about super computers while every one else was all into there Apple IIE's....) Its good for certain situations but games and OS's and almost everything we touch is very liniear. Its just the way humans work and think the best use for this now new again tech was physics they used it to predict particle collisions and things like that (nuke tests) Might be good for physics in games but I dont think there will be much gain for it from say an OS or most aps. Im half awake but seeing this thread was a nice warm up for my brain Joeset those where awesome links

Hmmm maybe they can finaly make a good pool game...

 

[JonathanDeane]

I found this link at the bottom of Joesets link and they actualy got some good performance. Although they used a hypercube of 1024 CPU's lol

http://www.scl.ameslab.gov/Publications/Gus/AmdahlsLaw/Amdahls.html

 

[JonathanDeane]

I was doing some searches and hit on this paper at the DOE its a fantastic read

http://www.science.doe.gov/bes/BESAC/Theory%20and%20Modeling%20in%20Nanoscience.pdf

 

[Bluefinger]

No reverse hyperthreading not hypertransport.

I don't why the AMD fanboys are so excited, Intel's working on it too and probably started work on it before AMD did.

Eh, it'll probably end up being a battle on who can bring out a reverse hyperthreaded CPU the quickest. The same happened with 64-bit CPUs. Intel brought out Itanium, but it flopped since it wasn't x86 compatible, and AMD brought out a decent desktop 64-bit CPU after Intel. Same **** happens again and again, but hey, its business.

It's happening with virtualization too -- and, as you put it with 64 bit, it does not necessarily matter who brings it out first -- what matters is does the market embrace and support it.

Yeah, all in all, its business as usual for AMD and Intel. Who can bring out the technology first, and then who can get the market to embrace it the first. Anyhoo... now to read up on all the sources you've linked... *sigh*

BTW... did you know I'm Portuguese as well... though I've forgotten to speak the language because I have lived in UK for a wee bit too long...

 

[Parrot]

Hello, Parrot!

Seems you're missing a link (a species one?!):

http://www.anandtech.com/printarticle.aspx?i=2507


A little deeper... http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm

... deeper still... http://www-cse.ucsd.edu/classes/fa05/cse231/Porter.pdf (Damn! This one's seems like a car accident...)

... and, clash?!


Cheers!

Thanks for the links, Joset-it saves my fingers-I hate doing long posts.

The ground work for this research was done by a company(no, NOT Intel or AMD) many years ago in collaboration with several universities. As you have discovered for yourself, they do not use the term "reverse hyperthreading". When I first heard the term I had a good laugh because I knew what people would type into Google and the result!! Anyway, I thought it about time that people learned the truth!! 8) :lol:

 

[joset]

JumpingJack wrote:

The Mitosis project relies on both hardware and software (compiler) support to work. First, on the software side, blocks of code that have very few inputs and outputs are detected and considered for use as a separate thread. The entry and exit points of the current working thread are marked, and the portion of the thread that would be split off is separated. The new thread is then fed the appropriate input data that it needs to begin its execution. With the single thread now split into two threads, they are both sent to the multi-core processor and executed in parallel. At the end of the execution of the thread, its result is checked to make sure that the data is still valid, and if so, the result is committed and all is well. If the result is invalid the thread must be thrown away, but since we're talking about a single threaded application to begin with, there is no wasted performance, only wasted power as the core this thread was running on would have been idle had it not been for the speculative thread generation inclusion of a global register file and a register versioning table to keep track of which cores have the latest and most correct register values is necessary. You also need some additional logic to help validate the outcome of these threads.

The end result of all of this is pretty promising, especially for single threaded applications that would otherwise get no benefit from being run on a multi-core CPU.

Fist off, sorry for the delay! (speaking of puns... )

Thanks for your kind words (and JonathanDeane's).

Actually, it was Action_Man who brought the "Intel's reverse hyperthreading" issue into this thread (see above). And, it immediately caught my attention (i.e., What?! Intel already...?!); like Parrot said, it took a while to find out it wasn't the correct designation (I was "shooting" every "reverse SMT" paper I could find...). It all ended up when I read "Mitosis"... and it wasn't addressing cell's division!

As for Speculative Threading, I must confess my [almost] utter ignorance on software issues (much poorer than hardware's). That said, is it me or is there a slight resemblance (remote as it might be), between the Speculative Threading & Memory Disambiguation? If one cares to look carefully at Intel's paper on the former & the way Jon Stokes (Arstechnica) addresses the later, I can only but wonder...

-> http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm

This figure also illustrates a speculation on a memory dependence. In this case, there is an ambiguous dependence through pointers P and Q. If the compiler suspects that this dependence does not occur, it can simply ignore it. At runtime, the hardware will check whether this dependence actually occurs, and if it does, the speculative thread is squashed.

Speculative threads enable the compiler to try numerous types of unsafe, aggressive, optimistic optimizations when generating the precomputation slice. In the end, you'll end up with highly optimized code that can precompute these values very quickly and still be correct most of the time.

-> http://arstechnica.com/articles/paedia/cpu/core.ars/8



Both use sophisticated speculation: the former relying in compiler intensive «precomputing» optimization while the later, in a sort of "preemptive" load execution. Using the former's terminology, I could say they both use some sort of «Optimized Slice» algorithms...

This comes as a mere curiosity, since I haven't had the time to go through the Speculative Threading papers, in deep.

(And, Jack, if I were to qualify any particular portuguese characteristic, that would most likely be adaptability; I really don't find us very... inquisitive! :lol: )


Cheers!

 

[joset]

(...) So I was right, huhn? Hooray for me.

Apparently... just.


Cheers!