Intel Dual Core Performance Preview Part II: A Deeper Look
by Anand Lal Shimpi on April 6, 2005 12:23 PM EST- Posted in
- CPUs
Multitasking Performance
As we discovered in the first article, multitasking performance requires a slightly different approach to benchmarking methodology. While for single application performance in which we test with a system that's in a very clean state with nothing but the benchmark and drivers loaded, for our multitasking tests, we have the system configured as what a real system would be. That means tons of programs and lot's of tasks running in the background. If you missed Part I, here's a quick recap of what our system configuration is like for our multitasking tests; the following applications were installed:
Daemon Tools
Norton AntiVirus 2004 (with latest updates)
Firefox 1.02
DVD Shrink 3.2
Microsoft AntiSpyware Beta 1.0
Newsleecher 2.0
Visual Studio .NET 2003
Macromedia Flash Player 7
Adobe Photoshop CS
Microsoft Office 2003
3ds max 7
iTunes 4.7.1
Trillian 3.1
DivX 5.2.1
AutoGK 1.60
Norton Ghost 2003
Adobe Reader 7
What's important about that list is that a handful of those programs were running in the background at all times, primarily Microsoft's AntiSpyware Beta and Norton AntiVirus 2004. Both the AntiSpyware Beta and NAV 2004 were running with their real-time protection modes enabled, to make things even more real world.
Multitasking Scenario 1: DVD Shrink
For this test, we used DVD Shrink, one of the simplest applications available to compress and re-encode a DVD to fit on a single 4.5GB disc. We ran DVD Decrypt on the Star Wars Episode VI DVD so that we had a local copy of the DVD on our test bed hard drive (in a future version of the test, we may try to include DVD Decrypt performance in our benchmark as well). All of the DVD Shrink settings were left at default, including telling the program to assume a low priority, a setting that many users check in order to be able to do other things while DVD Shrink is working.
Next, we did the following:
1) Open Firefox and load the following web pages in tabs (we used local copies of all of the web pages):
We kept the browser on the AT front page.
2) Open iTunes and start playing the latest album of avid AnandTech reader 50 Cent on repeat all.
3) Open Newsleecher.
4) Open DVD Shrink.
5) Login to our news server and start downloading headers for our subscribed news groups.
6) Start backup of Star Wars Episode VI - Return of the Jedi. All default settings, including low priority.
DVD Shrink was the application in focus. This matters because by default, Windows gives special scheduling priority to the application currently in the foreground (we will test what happens when it's not in the foreground later in this article). We waited until the DVD Shrink operation was complete and recorded its completion time. Below are the results:
The results here aren't too surprising. With dual core, you can get a lot more done at once, so the Pentium D 2.8 cuts the DVD Shrink encode time by about half when compared to the Athlon 64 3500+.
There is one element that caught us off guard, however. When looking at these numbers, we noticed that they were unusually high compared to the numbers from our first article. Yet, we ran and re-ran the numbers and had fairly consistent results. Even running the CPUs at the same speeds as in our first article yielded lower performance than what we saw in that piece. Comparatively, the processors all performed the same with reference to each other, but the DVD Shrink times were all noticeably higher. So, we started digging, and what we uncovered was truly interesting.
106 Comments
View All Comments
stephenbrooks - Wednesday, April 6, 2005 - link
#55 yes, that would be my best bet on what Anand was implying. AMD's 90nm process is impressive on power efficiency.bdchambers79 - Wednesday, April 6, 2005 - link
Hmm... if permormance isn't the only metric for dual-core AMD, then perhaps power also plays a role? What if they could craft a 2.2gHz monster that had the same power draw as a 2.0gHz a64? Such a beast, besides being a processing power-house, would show extreme overclock potential.cHodAXUK - Wednesday, April 6, 2005 - link
'The move down to 90nm really cut down AMD’s power consumption a lot, to the point where the 90nm Athlon 64 3500+ actually consumes less power under full load than the Pentium 4 630 at idle.'ROFL, I expect the old Prescott space heater gags to start again after this review :)
Crassus - Wednesday, April 6, 2005 - link
Hey Anand,on page 13 top diagramm it says "Thanks to DVD Shrink behaving and running with a low priority, our gameplay was largely unaffected on the Athlon 64. The performance dropped less than 3% in Doom 3. ..." yet the graph shows the A64 at the bottom far behind the Pentiums. Is the graph messed up or the comment?
Great article though and thatnk you for listening to your readers.
Thanks also for the NCQ-page. I still wonder if you want to pick up where you left off some months ago and look into RAID in more detail, possible measuring the impact of NCQ on the benefits of SMT or vice versa and CPU-load issues with simple RAID5 setups on dual-core?
Cheers, Crassus
Lonyo - Wednesday, April 6, 2005 - link
#50 and JeffLet's just say that the dual core Athlon 64 running at 2.2GHz won't be compared to a dual core Pentium D running at 2.8GHz.
AMD's dual core will be quite impressive, even more so than Intel's. Don't look at performance as the only vector to measure though...
....PRICE.
I think you were spot on. 2.2GHz DC Athlon is almost certain NOT to compare to PD2.8GHz.
The article is comparing 3 systems with the same price processor.
The comments from Anand suggest that the 2.2GHz AMD DC will blow the 2.8GHz PD away, but at a higher price.
The 1.8GHz AMD DC is more likely to be comparable (and possible faster, if the 2.2GHz Athlon really is amazing). But who knows?
coldpower27 - Wednesday, April 6, 2005 - link
Tomshardware was able to overclock the Pentium EE 3.2GHZ Dual Core to 3.8GHZ, and 4GHZ on some exotic form of cooling.coldpower27 - Wednesday, April 6, 2005 - link
Rumors indicate AMD's aiming for a launch at 1.8GHZ - 2.2GHZ frequencies for the Athlon 64 Dual Cores, I would guess, that most likely that these Dual Cores are based on the San Diego cores, as they each have access to 1MB of cache with a die surface area slightly larger then Clawhammer.Another guess would be they would use the 2.2GHZ Dual Cores as their FX flagship and have the 1.8GHZ/2.0GHZ variants as their mainstream line.
However with AMD saying 2H 2005 for their Dual Cores, we won't have to wait too long then for Intel's new version of Dual Core in 1H 2006 on the 65nm process.
Maybe the 2.2GHZ Athlon 64 Dual Core is much more expensive then the 2.8GHZ Pentium D? Or it competes with Intel's Pentium D 3.2GHZ.
defter - Wednesday, April 6, 2005 - link
Great review! It is refreshing to see different kinds of benchmarks.The problem with dual core Athlon64 is that it won't be launched until 2006 according to the AMD's roadmap: http://www.amd.com/us-en/Processors/ProductInforma... (dual core Athlon64 FX will be launched in H2 2005, but no regular dual core Athlon64 is scheduled for 2005)
And in 2006, Intel will have 65nm dual core chips available...
PrinceXizor - Wednesday, April 6, 2005 - link
For those saying that Intel will have ANOTHER dual core system out because of the delay by AMD...remember...this was a technology PREVIEW. There is no released hardware yet.Its going to be interesting to see what the benefits of AMD's built from the ground up to be multi-core approach vs. Intel's patch job (I still have utmost respect for Intel, they created one fine "patch job" under a severe time constraint, sometimes it does pay to be a behemoth ;)) will be.
P-X
NetMavrik - Wednesday, April 6, 2005 - link
Don't take this post the wrong way, I am not knocking Intel's HyperThreading, but I think most people have actually forgotten what it is. It is not a feature of the Pentium 4, but a bandaid approach to keep their now 31 stage pipeline busy doing something. The reason that a 3.8GHz P4 doesn't run circles around a 2.6GHz A64 is that horribly designed 31 stage pipeline. AMD can't implement some form of HyperThreading because it doesn't have a bunch of processor stages sitting around doing nothing like a P4 does without HyperThreading.