Intel's Dual Core Strategy Investigated
by Anand Lal Shimpi on October 22, 2004 3:09 PM EST- Posted in
- CPUs
The Problem with Intel's Approach
The major issue with Intel's approach to dual core designs is that the dual cores must contest with one another for bandwidth across Intel's 64-bit NetBurst FSB. To make matters worse, the x-series line of dual core CPUs are currently only slated for use with an 800MHz FSB, instead of Intel's soon to be announced 1066MHz FSB. The reduction in bandwidth will hurt performance scalability and we continue to wonder why Intel is reluctant to transition more of their CPUs to the 1066MHz FSB, especially the dual core chips that definitely need it.
With only a 64-bit FSB running at 800MHz, a single x40 processor will only have 6.4GB/s of bandwidth to the rest of the system. Now that 6.4GB/s is fine for a single CPU, but an x40 with two cores the bandwidth requirements go up significantly.
AMD's Strategy
While Intel's current roadmap appears to place dual core on the desktop before it makes its way to the enterprise (other than with Itanium), AMD's strategy is reversed - with dual core appearing in workstations and on servers before making a splash on the desktop.
Overall, AMD's approach simply makes more sense, since the overall performance benefit to dual core on the desktop will be minimal at best but strong in very specific applications and usage patterns. With most desktop applications continuing to be single threaded, dual core will still have to wait until there is more application support before truly being useful on the desktop. Heavy multitaskers and those running workstation applications will appreciate the benefits of dual core, but gamers and most other users will find higher clocked single core chips to be better suited for their needs.
The scenario is exactly the opposite in the workstation and server space, with the applications already seeing huge benefits from going to multiple processors thanks to their multithreaded nature.
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. Update: There is some debate as to how AMD implements dual core in their K8 architecture. The above description was provided by AMD from an earlier discussion but many readers have emailed to point out that the two cores are connected at the SRQ level. We are awaiting official confirmation from AMD as to exactly how their dual core technology is implemented. Update 2:While AMD never got back to us with an official response, unofficially they did confirm that the two cores on a single dual core Opteron die do communicate at full speed and are not connected at the HT level. We apologize for the error.
AMD's performance limitation here will be memory bandwidth, with the two K8 cores sharing the 128-bit DDR memory bus. While we currently don't see a huge performance increase from going to a 128-bit memory bus from a single channel 64-bit interface, the move to dual core will definitely make greater use of memory bandwidth.
AMD continues to list the second half of 2005 as the introduction timeframe for their dual core CPUs, with Opteron coming first and then Athlon 64 FX. Once again, as with all release dates, nothing is set in stone, but right now it looks like that both AMD and Intel are planning on having dual core on the desktop in the same general timeframe.
AMD has yet to reveal what the official specifications of their upcoming dual core desktop products are, but based on roadmaps and what we've seen, it would seem that the first dual core desktop parts will be based on two 90nm Athlon 64 FX cores with a shared memory controller. Interally AMD is referring to this CPU as "Toledo" as we've already published.
59 Comments
View All Comments
GhandiInstinct - Friday, October 22, 2004 - link
So why not test this technology and leave it in the labs instead of wasting consumers times. Obviously it's a waste of money if we don't have any software utilizing it. So, oh wow! KUDOS to the company to release it first, but remember the Prescott? First 90nm.... crossing the finish line first doesn't mean you earn that place.dak - Friday, October 22, 2004 - link
Good points :) Glad we don't use single cpu's at work lolBrian23 - Friday, October 22, 2004 - link
#25 There are several reasons why games aren't written multithreaded:1. multithreaded apps have more overhead so they run slower on single CPU systems.
2. most gaming systems are single CPU.
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.
Once multi CPU systems are the norm, I'm sure there will be games released for multi CPU systems.
dak - Friday, October 22, 2004 - link
Hmm, I never really saw the big deal about thread creation. Who really cares if it takes a freaking tenth of a second to spawn a thread, if you're only doing 20 or so threads at the startup of a game? I can't think of the last time I used a temporary thread. I usually spawn 'em at startup for a pre-defined role. Can't be the overhead of thread creation, they could split one off for texture loading in the background, and obviously the network clients. Personally I think it would be harder to NOT thread games, but I guess I'm too used to threading...stephenbrooks - Friday, October 22, 2004 - link
Windows thread creation has a bigger overhead than Linux threading, but you can still shuffle them about quite a bit and still get benefits. I'd imagine if they could keep it at one fork per tick or frame, it'd be pretty good.No reason I can think of why video games aren't being designed for multi-processors. Apart from the fact someone should take their shiny FX-55s away and give them quad-2.0GHz things to work on instead - _then_ they'd take advantage of it.
dak - Friday, October 22, 2004 - link
Strange, I'm kinda surprised that video games are single threaded. We write flight sims at work (*nix only), and we thread/fork all over the place. Flight sims are really just really big video games :)I would think with AI, physics engines, network clients for multiplayer, and oh yeah, that rendering loop thingy, that they'd be all over threading. I don't know about winders programming really, is the scheduler too borked for that? I can't imagine it would be, and I'm not one to give anything to microsoft....
stephenbrooks - Friday, October 22, 2004 - link
#19, I assume you mean XP Home. I'm running XP Pro on dual hyperthreaded Xeons and get 4 showing up in task manager.stephenbrooks - Friday, October 22, 2004 - link
I was looking around some presentations on Intel's site - it seems that we're in a dead zone before some fundamental changes are made to their transistors in the 2007-08 time frame (metal gate, tri-gate and high-K something-or-other), which might give real performance and clock speed improvements again (mention is made of reducing leakage 100x, for example). All the weird stuff happens in the 45nm and 32nm processes, with the 65nm one being another "boring" one like 90nm, hence the focus on dual-core for the next few years, I guess.HardwareD00d - Friday, October 22, 2004 - link
Overclocking a dual core would be a waste because until software developers start to write games in a way that uses multiple cores, you're just going to have one OC'd core sitting there looking dumb (and probably putting out a shedload of heat).HardwareD00d - Friday, October 22, 2004 - link
er I mean #15 sorry