Intel's Kentsfield CPU (top) will be the first quad core desktop chip, Clovertown will be the server equivalent - Courtesy AnandTech.com

According to Intel, it says quad-core for desktops will be ready by 2007

IDF is definitely showcasing a host of exciting technologies, but today Intel showed details of some very interesting technology in regards to where servers and desktops will be heading in 2007. According to company slides, Intel expects to be shipping multi-core Xeon processors based on the Montecito core by mid-year 2006. Targeting the MP segment, Intel's next-generation Tulsa processor will be manufactured using 65nm fabrication technology with large 16MB caches.

For the desktop segment, Intel indicated that Kentsfield will be the first quad-core processor and will be released in Q1 of 2007 after Conroe. During mid-year 2006, Intel will introduce its Bridge Creek platform but it did not indicate whether or not it will be Kentsfield ready. Recently, AMD also indicated that it will be introducing quad-core processors in 2007 for the server segment, but did not talk about the desktop space. According to Intel slides, Kentsfield will be focused on immediately after Conroe.

Intel indicated that quad-core processors will only be needed for the very highest-end desktops. Corporate users and enterprise level productivity software will also be a target for Kentsfield. Tigerton, Intel's quad-core MP processor, will also be released in early 2007.

Comments

Threshold

Username

Password

remember me

This article is over a month old, voting and posting comments is disabled

quote: Furthermore, each pair is using a shared cache which is superior to even AMD's point connections

This touches on the problem...I/O.
A large part of the reason that Smithfield and the other MCM dual cores don't perform nearly as well as the X2 (or Conroe for that matter) is that they must communicate with each other through the FSB. The quad core Intel is announcing for the desktop will have a few familiar problems (IMHO):

1. It will still use the MESI (Modified Exclusive Shared Invalid) cache coherency protocol, which has a greater latency penalty than the MOESI (Modified Owner Exclusive Shared Invalid) protocol that AMD uses.

2. Cache coherency between the modules will need to go through the FSB, and considering all of the other data is going through the FSB as well, this is going to have to be a much faster and wider FSB (or even 2 FSBs) than Intel has announced on any of their current models.

3. Based on current Conroe specs, a quad core desktop will have to have:
a. 8 to 16 MB of cache (which would make it about the size and cost of Alaska), or
b. Less cache/core, which will hit performance fairly hard, or
c. Move to an L3 cache model, which is a completely new design...

Indeed. While I'm not exactly a big fan of that, if it works AND Intel prices it reasonable, I can live it. Obviously it won't be at first, but it's not like I need quad-cores right either (our servers are small enough that dual processors are quite enough thank you).

Price is a good point...
I don't know if you remember, but AMD signed a license with ISI at the end of last year for SOI cache made using Z-Ram.
Z-Ram gets 5 times the density of normal cache (and only works with SOI). In addition, it utilizes far less power than normal cache memory...
Imagine a quad core Opteron that has only a 50% increase in footprint vs dual core at the same node, but has double the cache and double the cores...and uses the same power.
Add to that AMD's new strained silicon process, and I think we will see AMD keep the server crown for awhile...at least until their nextgen chips come out.

You should go back and read the posts again...
Cache partitioning only occurs within each die. The quad cores will have 2 dice per CPU, so coherency must be maintained via the FSB!
While I can't say how much traffic there will be (nor can I answer "how long is a piece of string"...), if you're going to actually USE the 4 cores it should be at least double that of a dual core...QED. In addition, the quad core must use the same FSB for coherency between dice...

Your first false assumtion is that both L2 caches must always be coherent. They only must be cohent for data that resides in both caches - in other words in threads that sharing resource amomgst the cores. Independent threads do not need their written data sent to the other cache.

We can go on and on about other things, such as how all memory writes must transverse the FSB anyway and we really don't have any idea what - if any - impact cache updates have.

quote: Your first false assumtion is that both L2 caches must always be coherent

I don't think I made that assumption...
I'll quote from a white paper done at Berkely:

"Not surprisingly, we find that caches are effective at reducing the processor traffic to memory. We observe improvements in L2 cache miss rates for L2 cache sizes up to 1 MB, the largest available for this processor. While larger caches are effective, this benefit is not without con-sequences. Coherence traffic, in the form of cache misses to dirty data in other processors’ caches, increases as caches get bigger, and as the number of processors increases. We find that the exclusive state of the four-state MESI cache coherence protocol is under-utilized for multi-processor configurations, and could likely be omitted in favor of a simpler three-state protocol. Finally, multipro-cessor scaling of this workload is good, but even modest memory system utilization degrades application memory latency, limiting database throughput..."