Intel's Dual Core Strategy Investigated
by Anand Lal Shimpi on October 22, 2004 3:09 PM EST- Posted in
- CPUs
Dual Core Mobility
A while ago I asked Pat Gelsinger what was in store for the future of Pentium M with regards to threading, and he responded with multi-core. Thus it's no surprise to finally see Intel giving more details about Yonah (or Jonah depending on what part of the world you're from), the 65nm dual core successor to Dothan.
Yonah's dual core setup will be much more power optimized than what Smithfield will bring to the desktop, and in an effect, much more efficient. There's little information available about Yonah, other than it will most likely have a power and thermal balancing dual core setup, with the individual cores powering down when they're not needed. The idea here is to switch between cores not based on performance needs, but based on thermal and power needs. If one core happens to be running too hot, it can be powered down and the active workload shifted to a different thread running on the remaining core, thus reducing the problem of thermal density by effectively spreading the thermal load across two cores.
While Dothan was more of a small set of fixes and updates to Banias, Yonah is going to be a significant set of improvements to what we've seen in the past. Yonah has already taped out and Intel is slated to release the chip in 2006. Yonah will begin sampling by the end of 2005 and Intel expects it to ramp up to 50% of the performance notebook segment by the end of 2006.
Yonah's platform is codenamed Napa, which brings support for DDR-2 667 as well as the 667MHz FSB to help keep the dual core Yonah fed with data. Given that Dothan will ramp to 2.26GHz by the end of 2005, we can expect Yonah's clock speeds to be around there upon its launch.
Dual Core Servers
Most recently Intel announced that their only multi core enterprise product shipping in 2005 would be Montecito, the dual core version of Itanium 2. This is where the rumor of Intel not shipping any dual core chips until 2006 came from, as it seems that the first dual core Xeons won't ship until Q1 2006. Now as long as Intel's desktop chips don't face any further delays, there will still be dual core desktop CPUs based on Smithfield available by the end of 2005. Given Intel's track record lately, it would not be surprising to see these chips slip into 2006 as well though.
The first dual core Xeons appear to be nothing more than Xeon versions of Smithfield,
but Intel does list that more power efficient versions of the first dual core
Xeons will appear in the second half of 2006 - potentially including
some of the power management features that will be included in Yonah.
An interesting inclusion on Intel's dual core Enterprise roadmaps is the
mention of a Dual Independent Bus. The term Dual Independent Bus hasn't
been used since the days of the Pentium III to indicate the separation of the
internal L2 cache bus from the external Front Side Bus. However, we wonder if
the dual core Xeon's Dual Independent Bus may in fact be individual 64-bit
datapaths to each socket on a dual socket server. This way a pair of dual core
Xeons would have just as much FSB bandwidth per pair of cores as the present
day dual processor Xeons, which will end up improving performance tremendously.
The platforms that will enable dual core Xeon support will be Blackford and Greencreek for 2S (two Socket) systems, and the next generation Twincastle for 4S systems.
Facebook
Twitter
RSS
59 Comments
View All Comments
Dasoo - Tuesday, November 2, 2004 - link
Has anyone heard anything about possible implications of the move to dual-core on memory? While I would guess that there would be little impact, I'm wondering if dual-core systems will use more memory or if dual-core will require performance characteristics.Thanks
Speedo - Sunday, October 31, 2004 - link
#55, "Right...unless you also happen to be running another application. For example "Windows" with 26 services..."Yea, but does these services, in a normal gaming computer installation, really take that much cpu time to really show an improvement in games?
For example, taking a look at the taskmanager right now shows I have 99% (or more) cpu resources free.
dak - Monday, October 25, 2004 - link
#31, "Hang on -- to all those that say dual threads are crap -- what exactly are you running -- AMD 64 maybe? they'res no software that can take advantage of the 64 bit, so its virtually the same thing no? "Sorry mate, I've got 2 amd64 boxes running 64 bit. It's called Linux you dolt. Windows ain't the only thing going on out there. And I can't wait for dual core, it'll be great for source based linux distros like gentoo....
knitecrow - Monday, October 25, 2004 - link
The only people raving about dual-core equals double the performance would be Intel spin doctors and computer noobs.Having a multithreaded application is not a simple matter of a linear increase in programming time/skill/effort/debug/validation ... it’s a geometric increase.
This makes multithreaded apps, inherently expensive with longer development cycle.
Furthermore, poorly written multithread apps can run far worse than single threads.
The windows OS is quite dumb when it comes to multithreading; while it may suffice for 2P and 4P... it becomes less appealing when you scale to 8P and outright useless after that. No wonder UNIX remains top choice for multiprocessor supercomputers.
Please consider REALITY before raving about dual processor.
Audiophile1980 - Sunday, October 24, 2004 - link
[q]In a single threaded application, no they will not be any faster. In a game for example, two 3.2GHz cores will not be faster than a single 3.2GHz core.[/q]
Right...unless you also happen to be running another application. For example "Windows" with 26 services...
eachus - Saturday, October 23, 2004 - link
"When AMD mentions that their K8 architecture was designed for multicore operation from the start, they weren't lying. Each Socket-939 or Socket-940 K8 chip, whether it's an Athlon 64, Athlon 64 FX or Opteron, features three Hyper Transport links (whether they are all operational is another question). In order to create a dual core version of a K8 based chip, you simply remove a single pair of Hyper Transport PHYs, one from each chip, and fuse the two Hyper Transport links together - thus creating a direct path of communication between the two cores, capable of transmitting data at up to 8GB/s (at 1GHz) between the two chips."That is not how AMD does it. Hammer chips have a cross-bar switch with connections to memory, Hypertransport links, and up to TWO CPU cores with cache. Dual core chips have one copy of the crossbar and memory controller, and both CPU cores connect to it. All done. The crossbar works at core-clock not memory speeds. The only case where the cross-bar could be a bottleneck is if both CPU cores have >50% cache hit rates on the other core's cache.
eachus - Saturday, October 23, 2004 - link
stephenbrooks - Saturday, October 23, 2004 - link
#27:--[There are several reasons why games aren't written multithreaded: 1. multithreaded apps have more overhead so they run slower on single CPU systems.]--
I never said they'd use multiple threads when running on single CPU systems. There's a very simple call in Windows you can do to determine how many processors there are, and you can decide how many threads you produce based on that. For instance if you have to detect collisions with 400 objects, you could do 100 in each of 4 threads, or 200 in 2 or 400 in the original thread.
--[2. most gaming systems are single CPU.]--
Yes, _right now_. If we end up having 4 or 8-core chips by 2010, single-threaded games are going to look rather silly.
--[3. the threads need to communicate with each other to get the frames drawn. Since the threads have critical sections, running them on a single CPU will make the critical sections que up causing major lag and drop in framerate.]--
The game would scale down to 1 thread on a 1 CPU (non-HT) system.
I think the main problem is that since there aren't so many multi-processor SMP systems out there, developers just think in terms of one thread all the time. It will take dual-cores etc. to become commonplace to change that.
Finally, will everyone who assumes "different threads have to be doing qualitatively different things" please stop it? That's complete pants. Often you get the best (near-linear) scaling when you just have a lot of repetitive (non-mutually-relying) things to do and you can split them equally between a thread for each CPU.
It's certainly true that _when no apps are multiprocessor-aware_ the different threads you have will be doing different things, but when the programmers know about how many CPUs there are, it's a whole different ball game.
douglar - Saturday, October 23, 2004 - link
From aces hardware--"According to AMD documentation, both cores in a dual-core chip are connected to one shared SRQ (System Request Queue). The SRQ has ports for CPU0 and CPU1. The links between the two cores and the SRQ runs at core frequency with 64-bit data paths. The SRQ is connected to the XBar (crossbar) which handles signal routing between the SRQ, MCT (Memory controller) and up to three HyperTransport Links. The SRQ is also connected to a APIC (Advanced Priority Interrupt Controller) that services both cores (dual Int ports).
The important thing here is that the cores are connected before the crossbar, not after it, as Anand suggests. Hence the cores in a dual-core chip will share all the HyperTransport links and the memory controller.
See slide 26 of Fred Weber's MPF Presentation, 2001:
http://www.amd.com/us-en/assets/content_type/Downl... "
Briggsy - Saturday, October 23, 2004 - link
The following is complete and utter bullcrap (from page 2): "Each Socket-939 or Socket-940 K8 chip, whether it's an Athlon 64, Athlon 64 FX or Opteron, features three Hyper Transport links (whether they are all operational is another question). In order to create a dual core version of a K8 based chip, you simply remove a single pair of Hyper Transport PHYs, one from each chip, and fuse the two Hyper Transport links together - thus creating a direct path of communication between the two cores, capable of transmitting data at up to 8GB/s (at 1GHz) between the two chips."NO NO NO NO NO NO NO
This has been described in detail by AMD since 2001. AMD DO NOT 'fuse' together two Hypertransport links to make a dual core processor.
AMD's processor incorporates an integrated Northbridge, which is a crossbar that attaches to the memory controller, hypertransport controllers, and the processor interface, called the SysReq. The SysReq can connect to TWO cores, and this was designed as a capability from the very beginning. AMD's dual core simply adds another CPU core and attaches it to the currently unused port on the SysReq.
If you get a simple, well explained, detail like that wrong, I can only assume the rest of the article isn't very reliable either.