Bios rev 1181, Intel badaxe, could this be reverse hyperthreading on Intel...could this be Intels answer to AMD secret weapon?
We wait to see;)
Printable View
Bios rev 1181, Intel badaxe, could this be reverse hyperthreading on Intel...could this be Intels answer to AMD secret weapon?
We wait to see;)
yes we do ;)
EDIT: pictures added for effect. :)
Conroe: 2 -> 1 core possible
http://members.cox.net/kjboughton/CMT.png
Kentsfield: 4 -> 2 cores possible
http://members.cox.net/kjboughton/CMT_QUAD.png
-FCG
If that is indeed that, than Kentsfield will rock =P .
4 cores -> multiplexed to 2 cores....imagine that.
Kentsfield at 3.6GHz could easily look like a Conroe @ 6GHz+
;)
Are you two smoking weed and not sharing?
reverse hyper threading ?
why would they do that ? that would focus totally on one core and not even bother with both.
by definition -
in other words multiple sources of data shoved down 1 pipe.Quote:
Multiplexing (also MUXing) is a term used in electrical engineering to refer to a process where multiple sources of information are combined in order to ease the organization, conversion and transportation of the material from one place to another. The information is usually held completely intact after it has been multiplexed but is transported in a different manner than normal.
so why in the hell would intel focus massive amounts of calls to the cpu to one core ? that would totally defeat the purpose of dual cores.
This is the absolute opposite of what we want ot achieve which is both cores cranking out at the same time.
Windows is not coded to use two cores, it maybe cpu capable but watch your task manager as you do things and 99% of the time everything is focused on one core/cpu while on small bits are focused on the second cpu/core.
very few apps are designed to utilize both cores or cpu's. and i am appauled at this in this day and age.
there should have been massive patches released by MS, and every other software maker to utilize dual cores. but there isnt.
so we are left with dual core cpus or such as my 955 XE a dual core wITH hyperthreading with MASSIVE amount of processing power just left idle doing nothing.
the only way multiplexing would work is if there was a way for the system to tell everything..
ok 50% of you go to this core and the other 50% go to the 2nd core.
then and only then would it do any good.
the other sid eof it would be the ability to allow sources of data coming from ram and hard drive and video to be handled super efficiently into one stream or multiple streams.
or maybe,, possibly some sort of a raid style data bursting down the throat of the cpu.
a little from this address a little from that address and back and forth back and forth until all data is processed.
it does however leave the door open for insane amounts of data corruption.
FCG. your thinking in reverse.....
multiplexing would make a 2.13ghz Conroe feel like a Kentsfield at ,, lets say 3 ghz.
the quad core can handle massive amounts of data while, for example, in simplest terms, the conroe can handle only half.
so with multiplexing the dual core cpu is being fed, data from multiple sources.
if a quad core was multiplexed it would be like a Octa-core.
WOW. :slobber: and it was as simple as a BIOS update.
Hope you guys are right (not doubting you for a second though :))
well from my knowledge because the bios is the brains of the motherboard. it is possible that it could.
more than likely the latest rev's of boards had this feature added or all rev's had it built in. and they needed to work ont he bios end of it.
but the bios could tell the mem controller to do this and that and tell the ide controller do this and that. and funnel the data all at once. thus streamlining it into the already exsisting pipe.
the mem controller and nb and sb bus has always been capable of much much more than the current hardware has been able to give it.
so with newer hard drives .. you get the idea.
it also could be something that is designed to mazimise the PCI-Express bus also. since it too is also capable of much more data thruput than is being used.
who knows.. we will havet o wait and see.
Multiplexing in this case would probably mean combining the data from more than one core into a single data stream. I'd presume this would be for more single-threaded applications which don't benefit as much from multicores.
I'm pretty sure demultiplexing would actually take that one stream and split it up into its original components.
yeah, I can make random speculation as good as the next guy, anyone actually have any info, or just speculation?
http://www.intel.com/technology/maga...ading-1205.htmQuote:
Originally Posted by BrownTown
Good read
How about this.
Enable apps to control the CPU's on the fly..IE if the app is running in single thread mode all 2 or 4 cores are used..IE combined.
Then, as the app moved to multi thread the CPU's go back to hyperthread mode and you get the speed benifit both ways.
Could it be possible to do something like this?
I think the theory behind AMD's reverse multithreading, and perhaps this multiplexing thing, is not quite what you describe Lestat. The purpose would be to enable a single threaded app to make use of multiple cores. So in a Kentsfield, it would split into 4 streams to use all of them, then recombine.
This is all speculation, since neither AMD nor Intel have announced anything of the sort :)
gee, I think i've been saying this for a year now and people keep telling me its impossible or inefficient lol.
its impossible and inefficient :nono:Quote:
Originally Posted by STEvil
CMT (Core Multiplexing Technology) only for Intel Core Extreme :confused:
That seems like a very innovative and impacting development for the future. That would make life of programmers a lot easier, causing low cost software to benifit from multiple cores.. Right ?
wow this gon rock, cos i gotta say the benchies from coolaler and hicook didnt seem that impressive at all, if this is true (which seem like the case) im getting kentsfieldQuote:
Originally Posted by freecableguy
also u said 3.6 GHz?? air??
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.
Not sure why there is so much resistance to this technology. The work is already done, Core 2 already contains all the technology required to implement this new feature.
1) L2 cache is shared and does not require bus access to read/write.
2) Single FSB shared by both cores.
3) Cores can be dynamically enabled/disabled.
4) L2 cache can be dynamically assigned.
5) Individual execution units can be dynamically powered-up and down.
Quote:
Originally Posted by overclocker.at
where did you saw that???
regards
well I agree with the statement that Intel's version seems very limited in nature...Quote:
Originally Posted by uOpt
IMO
bad for 24/7
awesome for superpi :D
I haven't seen a paper on what exactly AMD is doing but I bet 45 cookies that it is the same thing.Quote:
Originally Posted by nn_step
I wouldn't see it that much as a limitation.
Instead my view is that clearly the chip makers want to have multi-core and want applications to be multi-threaded.
However, they realize some people are stuff with either single-threaded applications or with applications that scale only to two cores when later there will be 4 or 8 around.
So they try to do what they can for the users of single-core applications to make use of the silicon at hand, even if it is not much.
You can mostly rule out that AMD does anything more or less fancy than Intel explains in this paper. This is all academic research from 10 years ago, chipmakers don't just pull this stuff out of their hats.
mm cookies.. can I have one?
Theres none left....Quote:
Originally Posted by lawrywild
http://i5.tinypic.com/15f5a28.jpg
I don't understand how people could not want this technology when almost all desktop software is single threaded.
Hopefully it will have some nice results, but i through we were already doing this on a software level (OS - cpu wait states) maybe doing it on hardware level will provide better performance.
Not sure all the logic that would be needed to handle this could possibly fit in a bios update which is already full. The rumors say AMD requires a new cpu driver and an update to windows for their solution. That I can see, but a bios update? I doubt it. Everything sounds fine until you take into account running single core apps and apps that can actually use more then 1 at the same time. How does it switch from single to dual (or quad)? How often? What is the overhead of all that switching? When does it make a decision to stay in one mode or the other? Seems to be a lot of logic involved.
BIOS doesn't have any code in it other than the setting bootstap options, initializing the CPU(s) and setting switches on or off (including setting timings, variables, conditions, etc.). To think that theres "code" in the BIOS to handle this is ignorant of how things work. A BIOS update does little other than tell the CPU to enable to technology....that's why all it takes it a BIOS flash and Windows code and/or CPU driver update.
That's exactly my point. How can they put the needed logic into the bios. And logic is needed. Unless their solution is all single core or all multi-core. If it is then it's worthless.
They're not, the BIOS is just a toggle option to tell the CPU to enable or disable the feature.Quote:
Originally Posted by Donbp
Donbp, instead of shoving the knife in and twisting. How about actually waiting for results first?
You come off sounding like a rabid fanboy.
What matters.
@ FCG or Tony:
Have you enabled this feature in Bios rev 1181?
Have you run some single thread app?
and if response to these questions is "yes", then, Is there a perfomance improvement?
Good point, although I do hope that it isn't like HT, in the way that it works better for Single threaded apps but multithreaded apps suffer..Quote:
Originally Posted by FUGGER
So do they actually use both cores together or do they disable one, and then overclock and use the cache ment for both cores on the other one?
Anyway if this is true and it works, imagine a 3.5ghz kenthsfield 4-in-1 in superpi :slobber: 14 conroe-gigahertz effective :slobber: :slobber: :slobber:
lol..Hey, I didn't start this thread that says it will be enabled with just a bios update. Yell at who did.
donbp, you're the one not realizing that the tech is already there, on the cpu, and all the bios is doing is flipping an on switch.
Yeah, maybe I misunderstood what people were saying. It sounded like they were saying that was what it is. As everything today has just been rumors and smoke I was getting a laugh out of it.Quote:
Originally Posted by Bloody_Sorcerer
^ Lame defense after insulting everyone whos posted in this thread.Quote:
Originally Posted by Donbp
I'm starting to love these technology secrets. You're already excited bout getting a conroe/kenthsfield then they tell you with a bios upgrade you get an TWO conroes/kenthsfields. Oh the joy.
No. With a BIOS update you can simulate a much more powerful single core chip with a Conroe and a crazy-fast dual core with a Kentsfield.Quote:
Originally Posted by sealion
Lol, what he said. But yea, its awesome when something like this happens. Our performance just increased 66% in 90% of our apps without us having to do much about it, lol.
i dont like this concept, u get the best performance with kentsfield when there are 4 threads at once lol, how hard is it to do that !!!
Guys don't forget AMD has a secret too, I have a feeling we may see PR's from both companies around 27th July or so...well im hoping they do..:)
I have no insider Info here, I have talked to neither Intel or AMD about this, i just read what gets posted and put 2+2 together, like Fugger says lets wait and see.
Regarding have a switched the option on...nope but FCG has,issue is we need the divice driver for XP to get it going and maybe a further bios update to straighten out some niggles etc...who know???
I know this much, it looks like both companies are pushing to better each other with secret tweaks they added into their latest CPU's, it can only make our experience of these platforms more enjoyable in the long run :)
Then I better make damn sure it is included in XS OS :DQuote:
Originally Posted by Tony
ok, if ppl are still buyin am2, idk what intel can do to stop them lol
they seem to have bested them in every concievable way, including having AMD's rumored tech lol
YeahQuote:
Originally Posted by grimREEFER
Conroe -> more OC'able
Conroe -> 8 IPC, AM2 6 IPC (with reverse HT)
Conroe -> win ;)
Still ... these RHT techs have gotta be lossy (in my unknowledgable opinion).... lets see some bencies ;)
first you might want to see something other than a rumor...
Also, please everyone stop talking like a quad core @ 3G will be equivilent to a single core at 12G, life don't work that way, you'll be lucky to get theequivilent of a 4G single core even IF this technology exists (obviously there will be some instances where it is higher, but on average). Also, it would likely work like the origional HT where some programs actually run slower if all the specualtions end up to be wrong. Or, backround threads might get in the way and gum up the works.
Lol, best post summarizing Intel's current ownage I've seen in a while.Quote:
Originally Posted by grimREEFER
I love AMD, it is too bad that they have no chance now :(
Intel is going to have the performance crown for a while if this comes true.
Let's wait and see.. both intel and AMD have a secret.. :D hehehe the waiting is killing me.. :p
so current am2 cpus will work with anti ht?
yes, like intelQuote:
Originally Posted by metro.cl
and a bios update and new processor driver will unlock the feature
Quote:
Originally Posted by andL64
in this thead the say only conroe XE migh support this
thanks for the answer, i wont sell my am2 yet then :)
Well I have a BIOS option on my Bad Axe for core multiplexing with an E6400, CPU is an ES tho.
Screen ?Quote:
Originally Posted by Atomicpineapple
/Does happy dance
Can't wait for my Conroe!
Cooper, rigs in bits atm for GFX card upgrade watercooling cleaning and a general tidy up! Will get it running on air later tho for a screenie.
**EDIT** Screenie as requested, appologies for poor pic quality, was taken from my camera phone.
It`s good enough to read, thanks :)
But I guess this doesn`t do anything atm, right ?
Hmm...and what`s that SW Single Processor Mode is about ? Anyone have a clue ?
According to FCGs post further up SW single processor mode disables 1 core totally.
It disables one execution core, afaik.Quote:
Originally Posted by Cooper
I'm wondering how CMT manages several threads. I mean : when one logical CPU takes in charge several threads, the context switch overhead is not negligible. And HT for example allowed to handle two contextes for this reason. Still very fuzzy, anyway :)
Ok, just tried a few things. Core multiplexing, when set to disabled, causes my PC to not boot. SW single CPU does indeed cause the PC to boot and use only 1 core. SW single core gave a slightly faster Pi time tho that may be an anomaly.
Don`t think it`s a anomaly. L2 is shared, so you have all 2MB just for one core -> better result.
I wonder what core is disabled: 0 or 1 ? And is there a chance to control which to disable. By manufacturing one core might clock higher than another - would be great to have a tweak allowing to choose which core to disable (of course is there`re switches in both cores).
Cooper, see post #2 in this thread. I show pics....just disables core 1 and gives all 4MB/2MB cache to the functional core.
Yeap. That was just what I`ve write, didn`t I ?Quote:
Originally Posted by freecableguy
FCG perhaps any info on which core is disabled ?
I still haven`t seen any proof that one of the cores might be weaker, but don`t think it`s not a fact.
Always disables Core 1 (the secondary core).
not even a second faster... looks like Multiplexing no work for that cpu...Quote:
Originally Posted by Atomicpineapple
its quite normal coz it needs an updated cpu drivers for the windows for it to work...
i||uSi0n^
nn_step, that wasnt multiplexing that was 1 core disabled and all the 2mb cache used by the 1 active core.
I hope that driver is doing as little as possible other than enabling the feature, software emulation will always be inferior to real HW support, kind of like HT compared to preemptive multitasking. If this thing is anything like a Dual to Single SW Gateway its probably gonna suck.Quote:
Originally Posted by i||uSi0n^
Do you mean when Enabled :confused:Quote:
Originally Posted by Atomicpineapple
amd's solution uses hypertransport while intel's solution uses shared L2 cache?
if this is true, isnt intel's solution going to be considerably better?
core family also have l1 to l1 direct link..Quote:
Originally Posted by grimREEFER
True, a shared L2 cache is superior to two processors connected Via Hypertransport link BUT such a design needs to be completely redesigned to add more processors. IN contrast all AMD needs to do is link and link. So for quick efficient upgrades AMD's is better BUT as a design for Performance ONLY a Shared L2 is about as good as it gets.Quote:
Originally Posted by grimREEFER
Yea, was thinking the same thing, lol.Quote:
Originally Posted by lawrywild
Do you have something I can read to better understand how they work? Just trying to figure out how exactly they plan to accomplish this.Quote:
Originally Posted by grimREEFER
I'm kind of lost here. The first image posted by "FCG" shows that there are two ways that multiplexing can be done.
The first way would be to dissable a core and run it that way, and another would be to give both cores the same thread.
Now, FCG then said that multiplexing technology always dissables one core. That begs the question "so what's the benefit of multiplexing?" If it dissables one core and gives the other core all 4 MB of L2 cache, core multiplexing wouldn't be anything to write home about (southern lingo lol). If that's all it does, why are people so excited about it?
I mean if it truly did use both cores to execute one thread, then yeah that's pretty groundbreaking, but if it's just a turning off of one core then i don't see the point...
He said that the 'SW Single processor mode' disabled one core, not that the Core Multiplexing did.Quote:
Originally Posted by Fuji
Given that the feature hasn't been announced yet, anything here is speculation :) The tag might be in the new BIOS, but it might not be fully enabled still, or might not be enabled on these ES samples, etc.
I think it's not the RHT or whatever you call it in "AMD's case"(since we are not sure what it is in AMD's case yet).
I got an email from a friend with this possible explanation:
It's probably a technique that makes possible the situation in which 2 cores are seen by a FSB as a single CPU core and thus utilazing the whole 1066 MHz bus much more effectivly.So its closely related to FSB and not to threading...
hey FCG, if your gonna make diagrams in MS Paint can you at least write that they are drawn for demonstration purposed only, there are some misguided folks going around to other forums acting like those images are from Intel documentation and it would be nice if you could kinda post that this is currently unconfirmed information etc...
Yeah, I know its not your fault what these people do, but alot of people respect what you say, so it might be best if you put a disclaimer there or something.
He signed them ©FCG 2006
wow, and yet still people are posting it like its official, oh well, guess they can just live in lala land if thats what they want.
finally, nobody made core multiplexing work though many have core 2
http://liberty.princeton.edu/Publica...calability.pdfQuote:
Originally Posted by Flanker
http://www.cslab.ece.ntua.gr/courses...chitecture.pdf
http://www.princeton.edu/~rblee/ELE5...roc_akkary.pdf <-- simulation article concerning multithreading a singular thread, co-authored by Intel, note the buzz words Memory Disambiguation.
Someone also aluded to earlier that "wouldn't Intel's implementation work better since it is shared L2 cache", the answer is yes.
q:
will this be availible for non intel mobo, but with intel chipset?? like DFI infinity 975?? cos i want to get DFI 975 infinity for OC, but if badaxe is the only one has it .... OC can be pain in badaxe lol
Core multiplexing is enabled by default and says that 'when set to disabled disables secondary cores'.
Like any newly introduced Tech the first implementasion won't be all that. But lets look ahead to nehalem . As I understand it Nehalem will have a IMC not unlike the ATI R520 . Now when you look at the R520 were the memory writes to 4 channels and the right software compilers is written . This can easily speed up single threads to 3x speed in a quad core pc. and speed up a dual thread to 2x speed . But the right kind of memory controller has to be in place . ATI has just such a contoller and intel and ati seem to be sharing tech. So Conroe's use of CMP will be a first stepps taken to Nehalem Mitosis settup with all the correct parts inplace.
Brown Cow it would seem that CMP for Conroe is less specutive for Intel than AMD RH/T . I seen a lot of AMDers picking up the RH/T banner when they thought that AMD had something to fight Conroe with . Dreams get crushed everyday. You should have paid att. To what Intel was saying openly.Quote:
Originally Posted by BrownTown
It was the Inquirer who opened up this can of worms along with X-Bit labs.
I am surprized at people. The sleeping giant has awoken and for some strange reason some thought it took another snooze. :nono:
The Inquirer picked up on private conversations techs were having from 2 weeks previous, many heard AMD had plans for something like this a couple of months ago but NDA's etc kept everyone quiet and the lack of actual info was scarce. I know i have heard zero info officially but google is your friend when you want to find more...i have been pushing the search engine for 4 weeks now and its supprising what you can find when you pinpoint places to look.Quote:
Originally Posted by Turtle 1
Bios files are beginning to show something is about to happen, all we need do now is look for a patch from m$ and we will know the day has arrived.
AMD from news on the web is looking for the gaming crown back from Conroe, i have a feeling we will be seeing some real fast dual cpu setups real soon along with RHT etc etc...the only issue is our wallets won't be deep enough ..LOL
Much thanks. But thats over my head, heh. Could you offer a basic explanation of how it works? As far as I know, it works by sending every second instruction to the second core, but I'm told that that is not possible.Quote:
Originally Posted by JumpingJack
Uh oh. Well, it may be enabled, but it needs that patch from MS to make it work. The second part worries me though - It disables the second core. So...we have no choice but to keep it enabled or suffer with a single core?Quote:
Originally Posted by Atomicpineapple
Lol. A bit of a fanboyish comment, but witty and well-placed. I liked it.Quote:
Originally Posted by Turtle 1
I'm not sure, I also have a SW single Core mode which disables 1 core, they must do something different?!Quote:
Uh oh. Well, it may be enabled, but it needs that patch from MS to make it work. The second part worries me though - It disables the second core. So...we have no choice but to keep it enabled or suffer with a single core?
i dont understand this at all lol, so to simplified this:
it makes dual core runs single thread application faster right??
and it also turns kentsfield into a conroe with pretty much double the clock speed??
but is this on the CPU side or the mobo side?? and when can i expect to see M$, Intel, mobo maker all to patch this up??
@ theteamaqua - Yes, it will let single threaded applications be run on both cores. But no, it won't work at double the clock speed. A 66% increase is more what we should expect.
Its on the CPU side.
People it is NOT in Core2 Duo...
The tech. called Core Mult. Tech. is closely related to FSB and not SW/HW threading implementation.
Ummm....Quote:
Originally Posted by nn_step
Doesn't AMD use it's cross-bar for the 2 cores to communicate?
Interesting article .. taking about "Reverse hyerthreading" (Core Multiplexing) ... pretty much comes down to its going to work great, ok, or only good on some programs. (Link: Overclockers.com)
It's been said that Intel's FSB isn't necessarly bottlenecked with Conroe, but will be bottlenecked with kentsfield so logically speaking, they are not going to make a technology that fills the FSB even more...Quote:
Originally Posted by informal
to me the core multiplexing sounds like a on off switch for the shared cache scheme which would explain why the system crashes with it dissabled.
im probably wrong but its my first guess lol i love what some of you here are coming up with 6ghz conroe performance....... hahaha
Sure, no problem --- and whoever told you that every other instruction sent is impossible is telling you correctly, it is impossible as memory load/stores and branching would conflict very quickly.Quote:
Originally Posted by Flanker
Reverse Hyperthreading (RHT) was first circulated around the net in early April. It derived from a french web site written by a fella who had a chance encounter with an AMD engineer at a bar True: http://www.bit-tech.net/news/2006/04...yperthreading/
The concept is this... in computers today with single core the majority of code base was designed and written to run in serial mode, one instruction follows the next (single threaded). As multi-core processing popularizes, these single thread designs still run fine, except they utilize only one core of multicore set, wasted resources. There are two approaches to splitting up the thread and allowing to use more than one processor. One is in programming, the programmer can split off various tasks that need to happen but are independent of the task being performed or the compiler analyzes the code base and organizes the machine level code to thread through multiple cores. This is the software/compiled solution.
The second is to have the system do the "splitting" via HW. In this case, as the concept goes, the singular thread is chopped into segments and the segments are split between the two cores. Or, another way to look at it, the two core CPU looks like a single core CPU. This is the concept of RHT or CMT.
Here is how it essentially works. The incoming instruction/data stream is segmented into chunks, for simplicity lets say segment A and segment B, such that segment A precedes segment B in logical order. Segment A goes to Core 0 and segment B is executed speculatively on Core 1. Speculatively in that it is a what if scenario. There are two outcomes to this situation
One scenario: After segment A and B finish, the results are compared -- if segment B read/wrote/or branched in such a way that is in conflict with the results frome executing segment A then the conclusion is that the B segment is errant and the result is simply ignored. This is OK because now segment B will execute in logical order on core 0 and nothing has been lost (albiet nothing gained either).
Second scenario: After segment A and B finish and the results are compared, and it is determined that no conflicts arose in memory reads/writes/branches between the two segments, in such a case the result from A is valid and the result from B is valid. As such, keep both results and simply merge them into the architecuteral state. In this scenario, we have gotten the speed up benefit of concurrently executing two segments of code in time that would other wise need to wait for A to finish before B began. In this case both segments retire concurrently.
In otherwords, segment B was executed speculatively sorta like asking a questions "let's run this ahead of time, and if it doesn't muck things up then I have done it right and killed two birds with one stone". So RHT or CMT are not perfect multi-threading solutions, but the worst case scenario is that some gains in performance will be realized.
Now, when you sit down to think about it RHT or CMT has practical limitations. For example, lets say CPU1 is operating on Thread A and CPU2 is operating on thread B. But thread A changes a memory location that Thread B needs --- when does thread B get the data before or after the change. Neither CPU knows unless they are communicating. Same thing with branch prediction, if thread A predicts a different branch than what is executing on thread B, then the work on thread B is wrong and needs to be discarded.
Another way to envision this concept is think of the inclusion of the OOOe (out of order execution engine). Basically the CPU buffer takes a set of insturctions and re-orders them in sequence to execute most efficiently through the core execution units. This is instrution level parallism (ILP). In essense, the unit examined is individual instructions. In thread level parallelism (TLP), the unit examined to be reorder is > 2 instructions within in the thread. You can think of RHT or CMT as grouped instructions being re-worked for exectuion similar to how a OOOe engine might reorder at the instruction level.
At first many people thought rubbish, then more details and actual technical papers on the subject have been found. It appears to be a reality, if so we can expect some performance improvements without having to buy new software. One would expect very serial, non-branchy code to get the biggest boost which means Games will not see huge improvements as these tend to be very "branch" code bases.
I dont think anyone ever doubted (not that ive seen anyway) that code could be paralelized by hardware. What was doubted (and rightly so) is that one instruction could be split to execute on 2 cores.Quote:
Originally Posted by JumpingJack