Core Multiplexing technology???

[Tony]

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

[freecableguy]

yes we do

EDIT: pictures added for effect.

Conroe: 2 -> 1 core possible



Kentsfield: 4 -> 2 cores possible



-FCG

[Nathanael]

If that is indeed that, than Kentsfield will rock =P .

[freecableguy]

4 cores -> multiplexed to 2 cores....imagine that.

Kentsfield at 3.6GHz could easily look like a Conroe @ 6GHz+

[Iconyu]

Are you two smoking weed and not sharing?

[Lestat]

reverse hyper threading ?
why would they do that ? that would focus totally on one core and not even bother with both.

by definition -

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.

in other words multiple sources of data shoved down 1 pipe.

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.

[Lestat]

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.

[vapb400]

WOW. and it was as simple as a BIOS update.

Hope you guys are right (not doubting you for a second though )

[Lestat]

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.

[Chuck232]

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.

[BrownTown]

yeah, I can make random speculation as good as the next guy, anyone actually have any info, or just speculation?

[Tony]

Originally Posted by BrownTown

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.htm

Good read

[Tony]

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?

[Aganerral]

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

[STEvil]

gee, I think i've been saying this for a year now and people keep telling me its impossible or inefficient lol.

[Hassan]

Originally Posted by STEvil

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

[overclocker.at]

CMT (Core Multiplexing Technology) only for Intel Core Extreme

[Pomme]

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 ?

[theteamaqua]

Originally Posted by freecableguy

4 cores -> multiplexed to 2 cores....imagine that.

Kentsfield at 3.6GHz could easily look like a Conroe @ 6GHz+

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 kentsfield

also u said 3.6 GHz?? air??

[uOpt]

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.

[freecableguy]

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.

[mascaras]

Originally Posted by overclocker.at

CMT (Core Multiplexing Technology) only for Intel Core Extreme

where did you saw that???


regards

[nn_step]

Originally Posted by uOpt

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.

well I agree with the statement that Intel's version seems very limited in nature...

[lawrywild]

IMO

bad for 24/7

awesome for superpi

[uOpt]

Originally Posted by nn_step

well I agree with the statement that Intel's version seems very limited in nature...

I haven't seen a paper on what exactly AMD is doing but I bet 45 cookies that it is the same thing.

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.