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
mlittl3 - Tuesday, April 5, 2005 - link
#90,Please, oh, please read Anand's blog from now on. He did just as you are suggesting a couple of days ago before the article was posted/written. He asked the readership for multitasking scenarios and he but those in the article.
Read his blogs. They are awesome.
Keep up the good work, Anand and Anandtech staff, and even though you don't have to give into the naysayers about lack of gaming benchmarks, thanks for being understanding and giving the readers what they want.
That is the sign of true journalistic integrity. :)
suryad - Tuesday, April 5, 2005 - link
As always great work Anand, and for all the users griping about the multitasking testing setup, well maybe Anand would be open to a set of multitasking suggestions his readers most regularly do. Maybe we can all offer suggestions and they will be tested for the second look probably sometime in the future on dual cores and hopefully AMD will have their bad boys out off the cage by then.Also benches on Linux would be great...64 bit and 32 bit.
Surya
Anand Lal Shimpi - Tuesday, April 5, 2005 - link
kjohnsonI'll let my actions speak for themselves, I've got gaming in Part II and surprisingly enough, it's no different than what I said in Part I - gaming performance of the dual core Pentium D is identical to a single core Pentium 4 of the same clock speed.
The multitasking tests in Part I were largely determined by responses to a "how do you multitask" question I posted in my blog on Friday. Out of the 65 responses, hardly any mentioned gaming as a multitasking scenario, so given my limited time with the system I decided to focus on what the readers asked for. That's also why I split the article into multiple parts, I knew that more performance testing would be desired but a desire for information would also be there on day one.
Insinuating that Intel somehow strong armed me into excluding certain benchmarks is just ignorant of how things work, at least at AnandTech. It's a great way to get attention but it's way off base. Intel told me when the system was shipping and when the NDA lifted, no more, no less. I spent all weekend putting together benchmarks that I thought the readership would like to see, not simply re-run benchmarks that we already had results of.
I've been doing this for 8 years, and the one thing I've always known is that it doesn't matter who is first to publish an article, but it is the article that does the best job and is the most thorough that matters. Trading integrity for exclusivity never makes sense, thinking it does requires a very short term memory and no sense of how things pan out in the long run. Being that in 3 weeks AnandTech will celebrate its 8th year anniversary, I don't think you can argue that type of thinking is characteristic of myself or anyone at this site.
But I'm not here to try and correct anyone's misconceptions of myself or this site, I'm here to deliver what the readers want and what will help you all make the best, most accurate purchasing decisions. In doing so I've taken every last comment to heart, as I always do, and I'm doing my best to incorporate your requests into Part II...just as I did in Part I.
As I mentioned in my blog, I'm an open book with nothing to hide, if there are questions of integrity or ethics fire away and I'll be more than happy to answer them.
Take care,
Anand
Amagus - Tuesday, April 5, 2005 - link
Wow that Inquirer article basically insinuates that Anand (it's obvious who he's referring to) was bought out because part I of a preview (!!) didn't contain any gaming benchmarks. I wouldn't stand for that.blwest - Tuesday, April 5, 2005 - link
Nice article, as always. I wonder how memory bandwidth increases/decreases will effect the performance of the already bandwidth hungry intel processors.michael2k - Tuesday, April 5, 2005 - link
#83, #85Gaming wasn't addressed because gaming, by itself, won't see huge improvements with dual core*
If you run IRC, AIM, FireFox, and BitTorrent while you game, then yes, you will see a performance increase, but not over a single core CPU running only the game by itself. A fast single core CPU will be much, much, better for a game. Or if you run WoW and EQ on two monitors, you will see a benefit.
*Drastic rewrites of OpenGL and DirectX will see benefits with dual core. For example, if front and back buffers were handled by different CPUs, or if you can split the screen into to sections and have one half processed by one CPU and the other half by another. Another performance technique might be to let one CPU deal with vertex culling, occlusion, and decomposition, while the other CPU deals with shadow calculations, or something suitably complex. But that requires the game to be written for dual core, and won't appear on games already on the market.
kjohnson - Tuesday, April 5, 2005 - link
Here's why this article does not mention any gaming benchmarks:http://www.theinquirer.net/?article=22332.bdchambers79 - Tuesday, April 5, 2005 - link
I just thought I'd say, I often run the Persistance of Vision Raytracer (www.povray.org) in the background on my computer for several hours (or days... hehe) at a time. While it's running, I am able to do little more than edit text. However, I also like to code and play games.So, what I would like to see would be POV-Ray running in the background, with MS Dev Studio or GCC running multiple times in the foreground; or, POV-Ray in the background with a game (NOT necessarily Doom3, guys, though it would be a good benchmark) in the foreground (perhaps in a window, so you can see POV's results). Or, for those truly masochistic souls, POV, DevStudio and Doom3 all running at the same time (though that's less likely to occur in RL) :)
BLHealthy4life - Tuesday, April 5, 2005 - link
I didn't read every single post here, but i do hope that it's ben mentioned that there were wasn't one single game run on this system. Surely this will be done in part two??fitten - Tuesday, April 5, 2005 - link
#80, that kind of change won't happen withough redigning the memory interface (of either) which would mean that current motherboards wouldn't be able to use the parts (which at least AMD is claiming will be possible).