Intel Dual Core Performance Preview Part I: First Encounter
by Anand Lal Shimpi on April 4, 2005 2:44 PM EST- Posted in
- CPUs
Scheduling and Responsiveness
In a single processor system (without Hyper Threading), the OS can only send one instruction thread to the CPU for execution at a time. But, you can run two applications at the same time and they can both be using up CPU time. In order to understand how this is possible, you have to understand a bit about how scheduling works.
As its name implies, the OS' scheduler schedules tasks. It takes the unlimited number of tasks that are requested of the OS, and schedules them to get done in the quickest way possible (in theory) on limited hardware resources.
When running a single application, the job of the scheduler is simple - the single active application gets all of the CPU's time for as long as it needs it. But what happens when you switch away from that active application and try to click on the Start Menu? Your usage experience would be pretty poor if you had to wait until your active application was done with its tasks before the scheduler would take the time to handle your Start Menu request. Imagine that your active application was 3ds max and you were rendering a scene that was going to take hours to complete. Would you be willing to wait hours for your Start Menu to appear?
Modern day OSes understand that this linear approach to scheduling isn't very practical, so they support pre-emptive multitasking, meaning that one task can pre-empt another before it is finished executing, and steal CPU time so that it may get some work done as well. In the previous example, the Start Menu request would pre-empt the 3D rendering process and your menu would pop up and the 3D rendering would resume immediately following that. Given that microprocessors these days are so fast, this rotation through tasks sent to the CPU occurs seamlessly to the end user, or at least it does most of the time.
There are times when the scheduler's work is not as transparent as it should be. In some cases, especially in Windows, processes will not always be able to pre-empt one another. If you're running two time-consuming, CPU intensive tasks, you may not notice, but if you're running one and trying to open a file or just click on a menu at the same time, then the hiccup is far more noticeable. The end result is usually a significantly delayed reaction to your input, such as a menu taking multiple seconds to appear instead of being an instantaneous response to your clicking. Anyone who runs more than one application at a time has undoubtedly encountered this type of a situation. Luckily, there are solutions.
Intel's Hyper Threading was one way around the problem. By fooling the scheduler into thinking that it can dispatch two threads simultaneously, situations like the one above were usually avoided assuming that the CPU had the appropriate resources free. Dual core is another solution to the problem, a far more robust one, since you literally have twice the processor resources.
The result of using a HT enabled or dual core system is better responsiveness when multitasking, but how do you quantify that? Unfortunately, it is extremely difficult to quantify response time in these situations. Even if we could easily quantify the response time improvements, is a snappier system when multitasking worth more than another 15% more performance in single threaded applications? How about 25%? It's a very different way of looking at the impact of a CPU to overall system performance, but it is an issue that we will have to tackle a lot more moving forward.
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?