AMD's Quad FX: Technically Quad Core
by Anand Lal Shimpi on November 30, 2006 1:16 PM EST- Posted in
- CPUs
Final Words
AMD is going to have a very tough sell with Quad FX; although the CPUs are priced competitively, if the ASUS L1N64-SLI WS ends up just shy of the $400 mark it's a platform that is simply too expensive at no benefit to the end user. When only running one or two CPU intensive threads, Quad FX ends up being slower than an identically clocked dual core system, and when running more threads it's no faster than Intel's Core 2 Extreme QX6700. But it's more expensive than the alternatives and consumes as much power as both, combined.
There is the upgrade path argument, that eventually you will be able to put a total of eight cores in this Quad FX platform, but we can't help but wonder if the market for someone who wants a non-workstation 8-core setup for desktop use is a very small one. Although to AMD's credit we were able to create a scenario where even four cores won't cut it, making a case for the need for 8-core setups in the future. But the promise of eight cores in the future doesn't do a great job of justifying the Quad FX purchase today.
For those users who won't migrate to eight cores, once AMD's new micro-architecture debuts next year with native quad-core support, this expensive Quad FX platform will be notably slower than cheaper single socket systems. Quad FX is simply a very niche product, and in the era of power efficiency and performance per watt, AMD has released the proverbial SUV of high end desktops.
AMD hopes to sell more Quad FX processors than any FX processor in the past, which to us means that either AMD sees much more opportunity in this platform than we do, or that the previous FX processors simply didn't sell very well. Either way you slice it, there's only one AMD CPU we're really interested in and we won't get it until the middle of next year. Luckily for AMD, Intel doesn't appear to be doing anything huge between now and then either, so it looks like the CPU wars will cool down for a while after a heated few months.
Prepare to revisit this discussion in less than a year's time, and next time AMD will hopefully be much better prepared, armed with a new architecture and a cooler, smaller 65nm process. Until then, there's always Quad FX but you're better off with Kentsfield.
Facebook
Twitter
RSS
88 Comments
View All Comments
Nighteye2 - Thursday, November 30, 2006 - link
I'm interested in that as well. NUMA will be an important part of 4x4 performance - so why isn't NUMA used in the benchmark, or at least mentioned. NUMA is the advantage of having 2 sockets - having NUMA disabled in this benchmark by using an OS that does not support it unfairly cripples the 4x4 performance.Viditor - Thursday, November 30, 2006 - link
Agreed...I think that one of the reasons that AMD delayed release of this so long is that they wanted to show it on Vista instead of WinXP. It seems to me that there would be a substantial difference between the 2...
Viditor - Thursday, November 30, 2006 - link
As a follow up on just how important NUMA is for 4x4, check out http://babelfish.altavista.com/babelfish/trurl_pag...">this review which actually compares the 2...There is a DRASTIC difference between performance on XP and Vista!
Accord99 - Friday, December 1, 2006 - link
Most of the difference is running in 64-bit mode. The extra bandwidth didn't help the FX-74 in the megatasking bench. They didn't do any game benchmarks but based on past reviews of NUMA, the FX-74 will probably keep on losing to the FX-62 in games.Viditor - Friday, December 1, 2006 - link
I'm not sure I agree...there's a 22.5% increase in performance there, and I haven't seen anything like that on the 64 bit version of 3DS Max before...
Not to mention that Vista isn't known as a real speed demon (quite the opposite) for these apps...
What the 64bit version does is allow for larger scene use and stability, not so much faster rendering.
photoguy99 - Friday, December 1, 2006 - link
Sorry totally wrong -
64-bit can make a big difference in performance depending on the app. Remember you can process 64 bits of data in a typical instruction instead of 32, so theoretically twice as much pixel data at a time for rendering.
Some apps may not show the full benefit it depends on how they are coded and compiled, but it's definitely a real potential for speedup.
Bottom line is 64-bit could easily account for a bigger performance increase than NUMA.
Kiijibari - Friday, December 1, 2006 - link
You see that he refers already to 3DS MAX .. I have not investigated this, but if he refers to it, then I trust him on that one ...
Futhermore I miss synthetical Sandra Mem bandwidth benches .. these should easily show what is going on there ...
Anyways a 4x4 review without mentioning the XP - NUMA problem is just not worth reading it ... Sorry Anand ...
cheers
Kiijibari
Anand Lal Shimpi - Friday, December 1, 2006 - link
The performance deficit seen when running latency sensitive single and dual threaded applications exists even in a NUMA-aware OS (I've confirmed this under Vista). I'm still running tests under Vista but as far as I see, running in a NUMA-aware OS doesn't seem to change the performance picture at all.Take care,
Anand
Kiijibari - Saturday, December 2, 2006 - link
Hi Anand,first of all, thanks for your reply.
Then, if there is really no performance difference, then I would double check the BIOS, if you have really disabled node interleave.
Furthermore there seems to be a BIOS bug, with the SRAT ACPI tables, which are necessary for NUMA. It would be nice, if you can dig up some more information about that topic.
Clearly, that would be not your fault, but AMD's.
cheers
Kiijibari
Anand Lal Shimpi - Saturday, December 2, 2006 - link
From what I can tell the Node Interleave option in the BIOS is doing something. Disabling it (enabling NUMA) results in lower latencies than leaving it enabled, but still not as slow as running with a single socket.CPU-Z offers the following latencies for the three configurations:
2S, NUMA On: 168 cycles
2S, NUMA Off: 205 cycles
1S: 131 cycles
From my discussions with AMD last week, this behavior is expected. I will do some more digging to see if there's anything else I'm missing though.
Take care,
Anand