Perhaps you meant to say compare it Phenom or Thuban (i.e. a non-CMT CPU)?
As consumers apples-to-apples comparisons matter less than real-world performance, the question is how much of that 80-90% is due to the FXs higher clocks? Presumably someone has compared a Phenom II quad to a Vishera 2M at the same clockspeed and turbos off.
It blows my mind too, but for the opposite reason: The FX 8350 actually has equal IPC to a Core2Quad? Because even the first batch of Denebs were supposedly slightly slower clock for clock compared to C2Q, and Bulldozer was far slower than Deneb clock for clock, but Piledriver improved it a wee bit - but to my understanding, still not at Deneb levels. And yet, here it is well within Core2Quad levels or slightly better. What is it with gaussian that makes Piledriver suddenly look Deneb/C2Q level in single-thread performance? How would you characterize the computations or various other processing gaussian does?I was expecting the FX-8350 to do rather well in this app, what I was not expecting was that it is basically on-par with having the same IPC as a 6yr old QX6700 Blows my mind.
It blows my mind too, but for the opposite reason: The FX 8350 actually has equal IPC to a Core2Quad? Because even the first batch of Denebs were supposedly slightly slower clock for clock compared to C2Q, and Bulldozer was far slower than Deneb clock for clock, but Piledriver improved it a wee bit - but to my understanding, still not at Deneb levels. And yet, here it is well within Core2Quad levels or slightly better. What is it with gaussian that makes Piledriver suddenly look Deneb/C2Q level in single-thread performance? How would you characterize the computations or various other processing gaussian does?
But we've already seen so many single-thread and clock-for-clock comparisons made since BD appeared. That can't be it alone. The consensus was clear - clock for clock, far slower than Deneb. We've had review site upon review site test this, and they weren't testing MT applications when they said this. They were using single-threaded ones of course.its all about instruction throughput, when you just have one thread on a module PD beats hound (Llano) in general IPC. once you start running two thread per module you become decode/instruction limited in a big way and about 1/2 the IPC gain from bulldozer disappears.
Great job IDC, although that old version of Gaussian you're using is most propably running x87 code which modern AMD processors are very bad at (you can use AMDs excellent CodeXL to profile apps), your multitasking gauassian graph shows what this chip is capable of, its a multitasking throughput monster for the price.
I'm sorry, I may have misunderstood your point, but I think what you are trying to say is that your graph shows Deneb actually has better IPC than a QX6700, because the QX6700 isn't the highest IPC family of C2Q, not the C2Q family that Deneb was compared to when released? That would make sense, because that would mean IDC's result in gaussian still correspond to the general finding that IPC in BD and PD are still < Deneb/Thuban. Did I understand you right?take a look here
QX6580 = Q6600 at 3GHz, Q9650 runs at the same clock (it's the 45nm Core 2 with 12mb l2) and PII 940 = 3GHz (but using DDR2), 945 uses DDR3
http://www.hardware.fr/articles/778-14/moyenne.html
Of course, this does not need to be said. In the real world, however, applications follow a general trend, so you will find, for example, very few examples of a Phenom II having more IPC than Nehalem, Sandy Bridge or Ivy Bridge. I do not know of any, but the possibility exists if someone wanted to optimize solely for Phenom II, but that would be crazy.As i have said soo many times, IPC is not constant in the same Processor. IPC is 99% application depended.
It will almost always goes down as the clocks go higher (I don't mean starting from 1Mhz, I mean from whatever your stock is, as that's an already reasonably significant clock speed), because we aren't increasing the performance of every single part of the CPU when we overclock the "core" (as opposed to "uncore", or even when core/uncore is unified such as in Ivy - although rumor has it it will be decoupled again in Haswell and consequently OC headroom will increase? Sorry, I digress). Most significant is even if the execution units, for example, become fast enough to accommodate more instructions per second (not talking of cycle here), and theoretically get 20% more work done (20% OC, for example), they won't get the chance to actually get all of that 20% increase, because the registers and caches are still the same size and can still only hold the same amount of data and still suffers the same hit-rate, and no matter how much you OC you can't remove cache misses (if you were to be really pessimistic about it, say for an arch with very little of this infra to begin with (cache starved), you could say you are just making the cache misses happen faster and more frequently). Scaling well with clockspeed means the balance of transistors spent for the caches (sizes + latencies) is favorable to the higher frequency, and is a design goal (not just caches, I just chose them as the most obvious and most easily understood/appreciated example). Those with barely enough of them to begin with suffer from scaling (Phenom I probably, but this also suffered from poor headroom in the first place, so it doesn't really matter as overclocking the original Phenom BE's were rather pointless)Also, IPC is Frequency depended in a lesser percentage, the same Processor doesnt have the same IPC (same application) at 2GHz and at 4GH
Of course, this does not need to be said. In the real world, however, applications follow a general trend, so you will find, for example, very few examples of a Phenom II having more IPC than Nehalem, Sandy Bridge or Ivy Bridge. I do not know of any, but the possibility exists if someone wanted to optimize solely for Phenom II, but that would be crazy.
And this is just as true with BD/PD. The trend found is that BD performs much lower clock-for-clock than Deneb (let's talk ST to avoid useless CMT arguments).
I find this very misleading...hence the VRMS heatsink will be forced at an equivalent 40°C ambiant temp that will add to the 50°C due to the VRM dissipation , the whole
thing will reach untouchable temp at high loading.
I just wanted to chime in about VRM cooling affecting overclocks. Even though I don't have an FX (undecided), but when I lowered the fans on my Cogage Arrow so that some air would flow over the large VRM heatsink I could reduce both the CPU-NB voltage (which reduced temps dramatically) and core voltage. I left my PC folding for the day and if I don't find that it has crashed then I think we can confirm the theory that certain Asus AMD motherboards need better cooling for the VRMs (I have a Sabertooth 990FX).
It blows my mind too, but for the opposite reason: The FX 8350 actually has equal IPC to a Core2Quad? Because even the first batch of Denebs were supposedly slightly slower clock for clock compared to C2Q, and Bulldozer was far slower than Deneb clock for clock, but Piledriver improved it a wee bit - but to my understanding, still not at Deneb levels. And yet, here it is well within Core2Quad levels or slightly better. What is it with gaussian that makes Piledriver suddenly look Deneb/C2Q level in single-thread performance? How would you characterize the computations or various other processing gaussian does?
No,
You have to compare 8x single Bulldozer Cores (Half Module) against 8 CMT Bulldozer Cores (4x Modules)
An example is to use 2x Modules CMT (4 Threads) against 4x Modules (4 Threads) No CMT.
This is the only way to see how the CMT design works.
AMD’s Bulldozer CMT Scaling
Compering 8 K10 cores(8 threads) against 4 Bulldozer Modules (8 threads) makes no apples to apples comparison.
I have some data on that for this app.
At 4GHz, loading two modules with one thread each results in a compute time per thread of 330 seconds.
Loading both of those threads onto one module results in a compute time per thread of 376 seconds.
In this application the "CMT tax" is quite small, 330/376 = 0.88x, or roughly 14% loss (1/0.88) in scaling efficiency for the FX-8350.
Compare this to the "HT tax" on the 3770k, at 4GHz loading two physical cores results in a compute time per thread of 218 seconds. (ridiculously faster than the FX8350)
But load both threads onto a physical + virtual core pairing and the compute time per thread balloons to 397 seconds.
In this application the "HT tax" is quite large, 218/397 = 0.55x, or roughly 82% loss in (1/0.55) scaling efficiency for the FX-8350
(100% loss in scaling efficiency would be tantamount to the performance you would expect in putting two threads onto just one single-threaded core)
edit: I see the powers that be have managed to torpedo your URL's again given enough time I have every confidence we'll eventually find ourselves censoring anandtech.com too and righteously proclaiming "mission accomplished" over the spammers in the process
Loading both of those threads onto one module results in a compute time per thread of 376 seconds.
(...)
But load both threads onto a physical + virtual core pairing and the compute time per thread balloons to 397 seconds.
People calling all kind of names the BD architecture, from inefficient to sucks etc but they have never understood that BD was designed for Multitasking/Multithreading and Throughput and not high IPC.
It's not that they don't understand. It's that they don't care because it doesn't matter - single thread performance is what matters more - it improves performance of lightly threaded apps, and improves performance of highly threaded apps as well, simply because you had more performance to start with.People calling all kind of names the BD architecture, from inefficient to sucks etc but they have never understood that BD was designed for Multitasking/Multithreading and Throughput and not high IPC.
So lets see,
FX8350 two threads single Module = 376 secs
Core i7 single core + HT = 397 secs
Now, since one BD module almost same size as one SB core (at 32nm), from the above measurements we can conclude (for that application) that as far a throughput goes, BD is better than SB.
People calling all kind of names the BD architecture, from inefficient to sucks etc but they have never understood that BD was designed for Multitasking/Multithreading and Throughput and not high IPC.
Edit: well, I have to find a way to invade those torpedoes
IDC,
Would you have power consumption data for those measurements?
80-90% is still less than 100%, so I'm still correct.You have to compare it against a 8 (legacy) core based Bulldozer to see how it performs. Most of the time, CMT performs at 80-90% of a legacy Multi Processor(MP) design.
80-90% is still less than 100%, so I'm still correct.
It's not that they don't understand. It's that they don't care because it doesn't matter - single thread performance is what matters more - it improves performance of lightly threaded apps, and improves performance of highly threaded apps as well, simply because you had more performance to start with.
"Throughput per die area" or "Throughput per core size", as you are proposing, is not a useful metric for anybody, not even for server guys. Performance/watt is. Pure performance is. Performance/dollar is. In all of these three metrics, in most of the scenarios (single-thread, lightly-threaded, multi-threaded, only exception is probably embarrassingly parallel), Intel CPUs (and sometimes, even Deneb/Thuban) score higher than BD.
You see the problem? You can point invent metrics where AMD wins, but unless it is something really solid like pure performance, performance/watt, or performance/dollar, most people will continue not giving two bleeps about the BD arch, and continue to say it sucks.
Until they produce a product capable of delivering that, it doesn't matter. Still, FPU throughtput will suffer.Thats what AMD was saying all along too about CMT.