Dual Core Linux Performance: Two Penguins are Better than One
by Kristopher Kubicki on July 1, 2005 5:55 AM EST- Posted in
- Linux
Multitasking Scenario 4: DVD Burning
Thanks to NeroLINUX, we can now run the first benchmark we did in reverse. We will be paying particular attention to the buffer for NeroLINUX. If the burn continually empties the buffer, then the system is playing catch-up to the burner. We will count the number of times the buffer dies and graph this separately. We used a NEC 3520A burner and a 4.5GB ISO image for the burn.
- Open FireFox 1.0.4 and load all 5 web pages.
- Open XMMS and start playing a Nine Inch Nails CD ripped to Ogg
- Open Thunderbird for news
- Login to our news server and start downloading headers for our subscribed news groups
- Begin an ISO burn with NeroLINUX and start timing
There seems to be a very linear correlation between the number of buffer dumps and the speed at which the discs burned. We really only saw the buffer even come in danger of decreasing at the beginning of the burn and when Thunderbird took a little too long to process something coming in from the news server.
Even though the processors we used in this analysis are more than capable, the additional tasks of FireFox and Thunderbird proved just a tad too much for the chips to handle at all once. This benchmark is a great illustration of where dual core (or dual socket) goes so wonderfully well on the desktop. The additional overhead to run XMMS, FireFox and the other applications is not very substantial, but when FireFox decides to chew up resources while the only CPU is managing the write buffer on a DVD burn, the results can be quite dramatic.
Facebook
Twitter
RSS
69 Comments
View All Comments
jamori - Wednesday, July 6, 2005 - link
For the web browsing multitasking scenario..."Even with additional instances of FireFox, the import times are much faster than the Windows counterpart of this benchmark. "
maybe i'm missing something, but the SLOWEST time on Windows is only about 30s slower than the FASTEST time on linux. The X2 4200+ is 45s slower in linux...
Also:
The chart for the compile while gaming (gaming benchmark 2) is pointless since it doesn't show -j3 for the single core processors. Even on single core processors, there is some benefit to be had in situations where job1 is waiting on the disk, job2 can finish its compile and in turn wait on the disk while job1 uses the CPU.
For instance: the way it is (with the -j1 setting) the equivalently clocked 4200+ and 3500+ perform about the same. What's to say they won't with -j3 as well?
rbochan - Wednesday, July 6, 2005 - link
Comment: I enjoyed the article...it may or may not be biased, but coupled with the community's comments enabled me to get the sense of relative performance I was hoping for.My Environment: I currently have an Athlon 3800+ configuration, 1 GB 2-2-2-5 Corsair Memory, and write Fortran77 programs to do simulation. Recently changing last year's GCC compiler to Intel's 9.0 auto-parallelizing compiler yielded a 31% decrease in run time. I do simulations that need to be done dozens of times a week that take about 15 hours apiece. These are heavy in floating point calculations with some trigonometric functions as well. This is done for fun (I am retired).
My Question: I am planning (in about 6 to 8 months) to upgrade to either a Four Dual-Core Opteron system (fastest chips then available) or a Four Processor Itanium-2 System. This is strictly for the simulation (number crunching) application. Comparisons in this arena are even more difficult to come by than those in this article. You guys do not seem short on opinion and I would appreciate yours...plus any references you would suggest to help figure out which way to go.
Thanks.
snorre - Tuesday, July 5, 2005 - link
#54, I agree. Kristopher Kubicki has been biased towards Intel ever since he joined Anandtech, and there have always been some issues with all the articles he has been involved in.Why are there no 64-bit large-scale benchmarks, requiring 4GB+ of RAM ?
And why didn't he include Athlon 64-X2 4400+, 4600+ or 4800+ ?
And please also include some real SMP benchmarks instead of all these stupid multitasking benchmarks that nobody cares about anyways.
DrMrLordX - Sunday, July 3, 2005 - link
#49, the real problem is that Kubicki's articles never have the detail of benchmarks carried out under Windows XP. We get fewer benchmarks and less hardware tested. Sure, there aren't as many programs under Linux available, perhapss, but that's no reason for him to cut out all single-app tests. People will frequently be running one single-threade or multithreaded app on dual-core CPUs, and they will also be running only two apps at once. Neither such scenario is represented well in this benchmark.This article does not provide enough information to draw conclusions about which CPU will be best under Linux.
sMashPiranha - Saturday, July 2, 2005 - link
Seemed a little Intel biased, but who doesn't have a bias? Informative nonetheless.tommy2q - Saturday, July 2, 2005 - link
someone needs to be firedsprockkets - Saturday, July 2, 2005 - link
funny, the web page says 51 comments, last comment by ElFenix on Jul 1,2005 at 11:50pm when my comment above is 51 at 12:03 AM on Jul 2sprockkets - Saturday, July 2, 2005 - link
for Steinberg Wave lab, how about Audacity? GLAME?Doesn't Nerolinux use the command line cdrecord and such anyhow?
ElFenix - Friday, July 1, 2005 - link
just a couple minor nits to pick, and this goes back to my whole 'you guys really need to hire an articles editor' thing that i've been harping on for 2 or 3 yearson page 8, it says haplessly, where you should probably have happily. haplessly isn't a very positive word.
and, as someone else has already pointed out, the manchester is not the $558 processor in this round up.
if you get in a faster core (maybe a 1 meg l2 cache version), could you please update the article? thanks.
JarredWalton - Friday, July 1, 2005 - link
4400+ would have been nice, but it's hard to get all the CPUs we'd like for every article. The 4800+ is in a league of its own as far as price, so including that would dictate that we also include the P4XE 840. Delaying articles for a few weeks while we try to get CPUs sorted out is not very useful either..There will be future articles, so don't get too worried.