AMD's Quad FX: Technically Quad Core
by Anand Lal Shimpi on November 30, 2006 1:16 PM EST- Posted in
- CPUs
Multitasking Performance
When we were trying to think up new multitasking benchmarks to truly stress Kentsfield and Quad FX platforms we kept running into these interesting but fairly out-there scenarios that did a great job of stressing our test beds, but a terrible job and making a case for how you could use quad-core today.
Without a doubt, in the next two years the number of applications that see a benefit when running on four cores will increase dramatically. Even multitasking under Windows Vista will make the argument for more cores easier (simply opening a new Explorer window in Vista will eat up 10% of the CPU time of a Quad FX system), but our Vista benchmarks are not yet complete and we wanted to have something to showcase for this review.
While working on our Quad FX article we also happened to be working on a follow-up to our HDCP Graphics Card Roundup, focusing on H.264 decoding performance in Blu-ray titles. A light bulb went off and we had our benchmark: how many cores do you need to watch a high bit-rate Blu-ray movie and do something else at the same time on your PC?
The movie we used was Xmen III, encoded in H.264, and featuring bitrates in excess of 40Mbps at times. Our benchmark starts at the beginning of Chapter 18 and continues until our background tasks are complete. This particular segment ranges in bitrate from 13Mbps up to above 40Mbps, with the average falling in the 18 - 24Mbps range.
We played the movie in the foreground, while in the background we either ran our Cinebench test, encoded a DivX movie, encoded a WME9 movie or performed our 3dsmax test.
The two rendering tests are important because rendering can take a bit of time and it might be nice to entertain yourself with a movie while your rendering completes; after all, what's the point of having $1000 worth of CPUs if you can't use them for entertainment?
The two encoding tests are also important because being able to encode and decode at the same time is a fundamental requirement for a DVR, and at some point the next-generation of media center PCs will need to be able to decode high bitrate HD movies while encoding others. We chose to include both DivX and WME because DivX runs much better on Intel CPUs, while the standings are a bit closer under WME, to give you a better overall impression of how the two platforms handle these heavy multitasking scenarios.
Our first test involved us playing back the BD title while running our multi-threaded Cinebench test; we reported the Cinebench score upon its completion:
The dual core processors all fall to the bottom of the list and basically perform like single-core CPUs while decoding the Blu-ray movie. The quad-core setups do much better and perform very well, but all of the CPUs in this test were able to run without dropping any frames in the BD movie.
Making things a bit more difficult, our next test had the same movie playing back but this time we ran our DivX encoding test in the background. We reported the DivX encoding frame rate upon completion:
Performance is pretty much what you'd expect, although Intel's superior DivX encoding performance results in the Core 2 Extreme X6800 doing almost as well as the FX-74. What you don't see however is how well these systems played back the Blu-ray movie; none of the dual core setups were able to play the BD movie smoothly, not even the Core 2 Extreme X6800. The movie was basically unwatchable due to all of the pausing and stuttering.
All of the four core systems played the BD movie fairly well; although they all dropped some frames, it wasn't enough to totally ruin the experience.
Next up we tried playing our BD title while running our WME9 test, and found similar results:
Once again, none of the dual core platforms were able to play the BD title even remotely smoothly. The quad-core setups were able to play the movie while encoding, but still managed to drop some frames (not enough to ruin the experience though).
Our final multitasking test has us playing the same BD title while running our 3dsmax 8 render test:
Much to our disappointment, none of the systems could handle this workload without ruining the movie playback; even the quad-core setups had troubles. We're not talking a few dropped frames, but rather the movie playback would be completely stopped at times. It looks like we may have a scenario for either more GPU assisted H.264 decode or an 8-core Quad FX platform in the future.
88 Comments
View All Comments
Viditor - Thursday, November 30, 2006 - link
If they can...
The 680a chipset has a direct HT link to each MCP, the 680i obviously can't do that and must bridge through the SPP.
Now if only we could find a review that actually showed that...;)
Seriously, the one major benefit of Quad FX is that it can run 4 GPUs. While I appreciate all of the conjecture and speculation, it isn't really a test of the facts, is it?
defter - Friday, December 1, 2006 - link
<quote>Seriously, the one major benefit of Quad FX is that it can run 4 GPUs.</quote>How that's a benefit? You can have 8 GPUs in a same system (AMD or Intel based, it doesn't matter) with a couple of NVIDIA Quadro Plex 1000 Model II's if money isn't an issue:
http://www.nvidia.com/page/quadroplex_comparison_c...">http://www.nvidia.com/page/quadroplex_comparison_c...
JarredWalton - Friday, December 1, 2006 - link
Fact: Quad SLI (7950 GX2) works on 590 SLI and 680i.Fact: Quad SLI (8800 GTX) does not exist.
Until the second item changes, we only have the first to go on, which is that current quad SLI works - at least as much as it works anywhere - on both platforms. And the QSLI drivers are still largely broken - you can run benchmarks, but as soon as you start playing lots of games rather than just benching, problems crop up. Neverwinter Nights 2 for example doesn't even run properly with CrossFire or SLI, so let's not even worry about getting QSLI support for now.
JackPack - Thursday, November 30, 2006 - link
8800 GTX requies two slots, which means it won't fit in the 4x4 motherboard. Quad-SLI performance has already shown to be poor using two 7950 GX2 cards. Finally, how do you bridge four 8800 cards together?Viditor - Thursday, November 30, 2006 - link
Huh?
http://www.bit-tech.net/hardware/2006/11/08/nvidia...">Single slot 8800 GTX
This is only when using a single MCP, the 680a uses dual MCPs.
The 680i uses one MCP and one SPP.
By having 2 sets of bridges (one bridge per MCP).
JarredWalton - Friday, December 1, 2006 - link
Quad SLI has problems whether or not you have dual MCPs. It's driver and software related - basically the drivers don't do AFR on a lot of titles and so you end up with lower than 7900 GTX SLI performance.As for two slots, they're talking the width of the cards. They only plug into one slot, but they fill the adjacent slot. Quad 8800 GTX would require eight expansion slots right now. Given that Vista 8800 drivers aren't even out yet, I think NVIDIA has other things to do before they worry about moving beyond SLI'ed 8800 cards.
PrinceGaz - Thursday, November 30, 2006 - link
I suppose you could replace the HSF with something smaller which would fit in a single-slot, which would have to mean water-cooling.Quad-SLI performance (or lack of) is probably a driver-issue.
Don't 8800 cards have two SLI sockets therefore allowing you to chain together as many as you like (in theory)?
casket - Thursday, November 30, 2006 - link
It appears with win-xp sp2... this quad fx stinks. How about Win 2003 or Vista Ultimate? It might change things drastically.Neosis - Thursday, November 30, 2006 - link
I don't think the problems in the benchmarks are not an opperating system issue. Two processors having totally four cores are not the same as a processor having the same number of cores. Additional latencies will slow down the performance.Viditor - Thursday, November 30, 2006 - link
Actually, they probably are...Windows XP is not NUMA aware, while Vista is.
In this case there is no difference...the Kentsfield has exactly the same latency as a 2 socket dual core because the 2 dual cores on-board don't talk directly with each other.