Printable View
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