Intel Dual Core Performance Preview Part I: First Encounter
by Anand Lal Shimpi on April 4, 2005 2:44 PM EST- Posted in
- CPUs
The Intangible Dual Core
The move to dual core is a bit of a "catch 22". In order to deal with the fact that a dual core die is twice the size of a single core die, AMD and Intel have to use higher yielding transistors. The larger your die, the more defects you have; so, you use higher yielding transistors to balance things out. The problem is that the highest yielding transistors run at the lowest clock speeds, so dual core chips end up running at slower speeds than single core chips. While the Pentium 4 could have hit 4GHz last year, we won't break the 4GHz barrier until late 2006 at the earliest.
In Intel's case, we're talking about 2.8GHz - 3.0GHz vs. 3.6GHz - 3.8GHz for the high end single core chips. In order to offset the difference, Intel is pricing their dual core chips within about $80 of their single core counterparts. Short of giving dual and single core chips a price parity, this is by far the best approach to assuring dual core adoption.
Why does Intel want to encourage dual core adoption? To guarantee a large installed user base, of course. The problem today is that the vast majority of desktop systems are single processor systems, meaning that most developers code applications for single processor systems. To encourage a mass migration to develop multithreaded applications, the installed user base has to be there to justify spending the added time and resources in developing such applications. As we just finished mentioning, Intel's approach is the quickest way to ensure that the exodus takes place.
So, with dual core CPUs priced very close to their single core counterparts, the choice is simple right?
On the Intel side of things, you're basically giving up 200MHz to have a dual core processor at virtually the same price. But things get a lot more complicated when you bring AMD into the situation. AMD hasn't officially released their dual core availability and pricing strategy, but let's just say that given AMD's manufacturing capacity, their dual core offerings won't be as price competitive as Intel's. Now, the decision is no longer that simple; you can either get a lower clocked dual core CPU, or a higher clocked single core AMD CPU for the same price - which one would you choose?
The vast majority of desktop application benchmarks will show the single core AMD CPU as a better buy than the dual core Intel CPU. Why? Because the vast majority of desktop applications are single threaded and thus, will gain no benefit from running on a dual core processor.
Generally speaking, the following types of applications are multi-threaded:
- Video Encoding
- 3D Rendering
- Photo/Video Editing
- most types of "professional" workstation applications
However, the vast majority of other applications are single threaded (or offer no performance gain from dual core processors):
- office suites
- web browsers
- email clients
- media players
- games, etc.
If you spend any of your time working with the first group of applications, then generally speaking, you'll want to go with the dual core CPU. For the rest of you, a faster single core CPU will be the better individual performance pick.
But once again, things get more complicated. Individually, single threaded applications will make no use of a CPU able to execute multiple threads. But, run more than one of these applications at the same time and all of the sudden, you're potentially dispatching multiple threads to your processor and thus, potentially, have a need for a multi-core CPU.
Facebook
Twitter
RSS
141 Comments
View All Comments
johnsonx - Monday, April 4, 2005 - link
It looks like AMD better get busy. AMD woke up Intel from it's complacent slumber, and now Intel is going to start eating AMD's lunch. AMD has completely lost the 64-bit advantage, and will now lose whatever dual-core advantage it had by designing Hammer to be dual-core from the start. Prescott may or may not have been designed for dual-core, but it sure seems to work just fine, doesn't it?AMD's problem is that it talks about what it's going to do for too long before actually doing it, as if there isn't anything Intel can do about it. Intel surely can do something about it, and definitely has. This may be an obvious consequence of being a much smaller company: AMD doesn't have the resources to get things done as quickly as Intel can (when Intel is sufficiently motivated), but that just means AMD needs to keep their mouths shut for longer. AMD has been relegated to 'me-too' status for technologies they themselves were first with...
Object lesson for AMD: Intel can beat you to any launch date you set for any technology or feature you think you've got an exclusive on. Intel can then crush you with volume and market presence. It ain't fair... welcome to life.
AMD's best bet: whatever you set your launch dates to, surprise launch everything 6 months ahead of schedule. That'll only work a couple of times, but it's better than nothing.
Klober - Monday, April 4, 2005 - link
Two separate points here:First, I suppose dual-core may not improve single threaded application performance much over a single-core CPU with HT, but shouldn't it increase performance over a single-core CPU w/o HT? I would think it would allow the OS to run on one core while the application runs on the other core, which in theory should increase performance some. Just a thought, as I'm no expert on scheduling and the resources the OS actively requires.
Second point, a small simple application that may be useful in benchmarking, particularly in multitasking benchmarks, might be Macro Scheduler by MJT Net. It takes very little in the way of resources, and is very easy to program for starting applications, switching between them, taking screenshots, clicking on options and even typing whatever you'd like wherever you'd like. I think it could be a great base for switching between applications and starting processes inside those applications, all in a very repeatable manner. Timing can be down to the 1/10,000th of a second if need be, and using a scheduler with minimal resource impact would take the human element out of the benchmarking. Maybe you've already looked into this, or something similar, but it's just a thought that may make certain benchmarking situations easier for all of you that bring us these great (p)reviews.
Googer - Monday, April 4, 2005 - link
In Soviet Russia you post all you bad jokes Here:http://forums.anandtech.com/messageview.aspx?catid...
knitecrow - Monday, April 4, 2005 - link
yo dog, where the temperature at?but seriously, in addition to the usual suspects, I think anandtech should have compared pentium D to xenon 3.2ghz just to see the performance difference.
johnsonx - Monday, April 4, 2005 - link
ok, sorry... I posted my comment before reading the encoding benchmarks, where I see you did exactly what I suggested. My bad.vaystrem - Monday, April 4, 2005 - link
"2) Open iTunes and start playing the latest album of avid AnandTech reader 50 Cent on repeat all."? Really?
johnsonx - Monday, April 4, 2005 - link
I know it's nearly double the number of benchmarks to run, but it would have been instructive to see both Pentium processors benchmarked without HT as well. Testing the dual-core pentium EE without HT would of course mimic a 3.2Ghz Pentium D, and testing the single core P4 without HT would give us a baseline single-core, single execution thread reference.Finally, it might also be instructive to benchmark current P4 at 3.2Ghz, again both with and without HT.
Easy for me to say, I know, since I'm not the one who has to do all the benches....
LeadFrog - Monday, April 4, 2005 - link
I like the theory of if it can't get any faster lets just combine a few.SLI, RAID, and Dual Core CPU's.
segagenesis - Monday, April 4, 2005 - link
One site mentioned 125W power consumption. Ow.Well, its a start... but I want to see AMDs offering first.
msva124 - Monday, April 4, 2005 - link
This looks promising, I wonder if AMD might eventually cave and implement hyper-threading in their processors, in addition to dual core. Or is that not part of the cross licensing agreeement?