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.
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?
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.
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)
I find this very misleading...
. Wow, very cool to hear this :thumbsup: thanks for taking the time to weigh in and confirm the observation (or rather, mine confirms yours ) 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
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
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.
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
Until they produce a product capable of delivering that, it doesn't matter. Still, FPU throughtput will suffer.
Facebook
Twitter