Are Intel And IBM Cheating With Their Quad-Core Processors?

[StyM]

source here (http://www.informationweek.com/blog/main/archives/2006/08/are_intel_and_i.html;jsessionid=03EDJNBKGP454QSNDL OSKH0CJUNN2JVN)

Are companies like IBM and Intel "cheating" in using multichip module (MCM) packages to create the latest advancements in multicore processors? Or is insisting that those next-generation devices be manufactured using a single monolithic design such as those by Advanced Micro Devices just gamesmanship?

:rolleyes:

[Vapor]

I like MCM packages better....easier to bin and produce high-clocking chips, effectively (*not* literally by more than 1-2%) reduces power density (when IHS is on), they take no performance hit (that we know of), reduces R&D costs, which reduces cost and wait time for the end-user.

I don't see what the big deal is....each approach works, and that should satisfy 95% of people. (the remaining 5% play favoritism to AMD or IBM/Intel or have a vested interest in the highest-clocking cores possible [OCers])

[Thorry]

I like MCM packages better....easier to bin and produce high-clocking chips, effectively (*not* literally by more than 1-2%) reduces power density (when IHS is on), they take no performance hit (that we know of), reduces R&D costs, which reduces cost and wait time for the end-user.

I don't see what the big deal is....each approach works, and that should satisfy 95% of people. (the remaining 5% play favoritism to AMD or IBM/Intel or have a vested interest in the highest-clocking cores possible [OCers])

Offcourse they take a performance hit...

They don't take a performance hit compared to a dual socket mobo (since it boils down to the same). But it depends a lot on the architecture if the performance takes a hit.

With Intel's current architecture for example the two 'cores/processors/logical units' share one FSB with th rest of the lot. These do take a hit compared to the integrated chips since a high performance interconnect is missing. But since there are no integrated chips (and prolly never will be, the Xeons will be much more rich in cache and the quad core 'Conroes' will be a new level of tech in it's own)

With AMD's current architecture seperate HT links can exist between the cores for a high performance link. AMD's architecture takes no performance hit compared to integrated chips, that's why the 4x4 platform is something sweet indeed.

But the great thing is: We can have both, if they come up with integrated quad cores they can use the packaging to get a octal core CPU or even with sixteen cores. Put that in a dual socket mobo and you have 32 cores in the system, that's a supercomputer on your desktop right there ;)

[turtle]

I like MCM packages better....easier to bin and produce high-clocking chips, effectively (*not* literally by more than 1-2%) reduces power density (when IHS is on), they take no performance hit (that we know of), reduces R&D costs, which reduces cost and wait time for the end-user.

I don't see what the big deal is....each approach works, and that should satisfy 95% of people. (the remaining 5% play favoritism to AMD or IBM/Intel or have a vested interest in the highest-clocking cores possible [OCers])

You're probably right on all points, but I quibble.

Taking no performance hit compared to what? A native quad core on the same design? When looking fundamentally at C2D's architecture of shared cache per native die, a native quad core will indeed work better even at 65nm (which will never exist), as a single core can utilize the whole bank as opposed to just the cache on each single die on a MCM package. I don't know at what cache level performance increases taper out or when decreasing returns occur, but looking at allendale with 2mb vs Conroe with 4mb, the performance differance can be as high as 10% (http://anandtech.com/cpuchipsets/showdoc.aspx?i=2795&p=4). Figuring a native part would 8mb cache on 65nm, that could in theory add at least another chunk. Considering afaik Bloomfield will be 8/16mb shared cache, it must still account for some performance benefit.

Don't get me wrong though, I agree with you on every other point, which on the whole are more important and it's crucial to realize native quad core on Intel's part will also come with a transition to a smaller process, so truely it would slow down R&D to have created a native quad first on 65nm.

[[TAG]Imp]

You're probably right on all points, but I quibble.

Taking no performance hit compared to what? A native quad core on the same design? When looking fundamentally at C2D's architecture of shared cache per native die, a native quad core will indeed work better even at 65nm (which will never exist), as a single core can utilize the whole bank as opposed to just the cache on each single die on a MCM package. I don't know at what cache level performance increases taper out or when decreasing returns occur, but looking at allendale with 2mb vs Conroe with 4mb, the performance differance can be as high as 10% (http://anandtech.com/cpuchipsets/showdoc.aspx?i=2795&p=4). Figuring a native part would 8mb cache on 65nm, that could in theory add at least another chunk. Considering afaik Bloomfield will be 8/16mb shared cache, it must still account for some performance benefit.

Don't get me wrong though, I agree with you on every other point, which on the whole are more important and it's crucial to realize native quad core on Intel's part will also come with a transition to a smaller process, so truely it would slow down R&D to have created a native quad first on 65nm.
the ability to use all the cache affects mainly single-threaded apps, as once more multi-threaded apps are out, the workload will be split evenly between both die modules, so it shouldn't affect it...

[Celeron Gamer]

I don't get how they're cheating, each company is using their own technology to develop their products.

[Vapor]

I think Thorry's most right about the performance hits. I'm sure there is one, but is it significant....and, specifically, is it significant enough to offset the higher yields at higher speeds?

I'll admit that there is a performance hit...but in regards to taking the EXACT same architecture, and then separating the dies (so no shared cache), and comparing those performance figures, there are no true numbers on the performance hit (it could be 10% or it could be <1%). Intels take a hit in performance for more reasons than just the separated dies. There are architectural inefficiencies, the split dies aren't known to be one of them.

Then comes the issue of incorporating a shared cache architecture with split dies....it's probably not worth the R&D time/money, so having a single die is a must for fully-shared cache architectures. Shared cache is more than just a single-threaded speed-up, so the advantages to go to a shared cache are absolutely there.

In regards to HTT....it's nicer than what Intel does for multi-sockets (no doubt there), but having a 1cm proprietary direct connection between dies on Kentsfield may very well be just as effective (keep in mind, Intel very likely has incorporated something like this....a 2xWoodcrest vs. Kentsfield comparo would shed light on this, IMO).

Again, there's a performance hit, but the probability of it being miniscule is very high. We're not talking about cross-socket communications here (that Intel isn't so great at :p: ), we're talking about cross-die, which Intel hasn't talked about much and could fairly easily throw in some direct connection tech into the arbiter unit.

[STEvil]

pointless arguement.

[nn_step]

No real point behind this arguement. Although such a design is slightly superior to Intel's 2P design (not AMD's) it however is beat by a similiar design that connects the two Chips directly (What AMD basically does) which is beat by the even more superior (but harder to scale) unified Multicore design (like Yohan/conroe)
So it is ultimately a pointless arguement. All that matter is performance and Cost. Everything else is details

[XS Janus]

Here it goes again...:rolleyes:
HEY WORLD, if it has 4 cores it IS QUADCORE

...the rest is just fine print... :slapass:

[onewingedangel]

MCM is almost as good as native multicore designs and can be easily produced out of existing mainstream high volume products.

MCM adds more flexibility, and is absolutely the right thing for intel to do right now, considering the large die size of conroe.

AMD will be moving to quad core with their second gen products after they move to 65nm, and Intel a few months later will release 45nm quad core MCM's with even more cache, before releasing the native quad core parts.

This will leave Intel probably 9 months to a year behind AMD on native quad core, but likely ahead of AMD in performance at least until k8L, and likely matching them after this until the shift to 45nm where they gain the lead again.

Intels move to native quad may coincide with their introduction of CSI, so the performance hit of scaling the number of cores will be reduced.

[Revv23]

certainly takes alt of R&D out of things..

I like it, more cores to me faster. Like said, useless argument.

[Thorry]

I think Thorry's most right about the performance hits. I'm sure there is one, but is it significant....and, specifically, is it significant enough to offset the higher yields at higher speeds?

I'll admit that there is a performance hit...but in regards to taking the EXACT same architecture, and then separating the dies (so no shared cache), and comparing those performance figures, there are no true numbers on the performance hit (it could be 10% or it could be <1%). Intels take a hit in performance for more reasons than just the separated dies. There are architectural inefficiencies, the split dies aren't known to be one of them.

Then comes the issue of incorporating a shared cache architecture with split dies....it's probably not worth the R&D time/money, so having a single die is a must for fully-shared cache architectures. Shared cache is more than just a single-threaded speed-up, so the advantages to go to a shared cache are absolutely there.

In regards to HTT....it's nicer than what Intel does for multi-sockets (no doubt there), but having a 1cm proprietary direct connection between dies on Kentsfield may very well be just as effective (keep in mind, Intel very likely has incorporated something like this....a 2xWoodcrest vs. Kentsfield comparo would shed light on this, IMO).

Again, there's a performance hit, but the probability of it being miniscule is very high. We're not talking about cross-socket communications here (that Intel isn't so great at :p: ), we're talking about cross-die, which Intel hasn't talked about much and could fairly easily throw in some direct connection tech into the arbiter unit.

Let me add something just to mix it up a bit:

It is possible to have shared cache and still have a MCM design. You could actually add a 3rd core with a simple cache memory controller and a load of cache. With AMD this would take almost no performance hit against a integrated shared cache.

On the other hand AMD doesn't have shared cache (altough there is talk of a shared L3 cache) as of yet. So that doesn't fly.

I have heard rumours about AMD's first quad cores: (Didn't get it of my usual source so no idea if this is true) The first quad cores from AMD will be MCM and have a single memory controller for the two cores. It is not clear if this memory controller is integrated into one of the two units and the second one piggybacking or if it's a seperate chip.

With a seperate chip it means only developing one type of core and a very small memory controller chip to be placed onto the PCB. I do not know if AMD has the ability to produce those chips (the memory controller chip), but they could let somebody else do that for them.

Other possibility is 'simply' each core it's own memory controller and have the user input 4 strips of memory (or two for dual single channel performance). Another unlikely possibility is having both cores both the ability to piggyback and the memory controller, this would mean more expensive cpus, but at the same time better yields so it evens out.

Ah we will see what the future brings.

People saying this is a pointless argument: You are wrong!

Intel does take a performance hit on it's dual cores due to the shared FSB, the new quad cores will have an even higher FSB just to keep the cores fed with data from the memory. However since there is no (and never will be) a native quad core on the same architecture we will never know how big that performance hit actually is.

That MCM is a nice thing for us is obvious, we've had dual socket systems for decades. MCM is the same thing only smaller...

It is not pointless at all, there are scalability issues with MCM. We will need faster and more integrated cores if we want to keep going forward at this speed...