AMD Piledriver rumours ... and expert conjecture

[Reynod]

We have had several requests for a sticky on AMD's yet to be released Piledriver architecture ... so here it is.

I want to make a few things clear though.

Post a question relevant to the topic, or information about the topic, or it will be deleted.

Post any negative personal comments about another user ... and they will be deleted.

Post flame baiting comments about the blue, red and green team and they will be deleted.

Enjoy ...

 

[gamerk316]

but we are still limited by software not able to use more core effectively

Because most tasks are not parallel in nature. If what you want to do is sequential logic, then guess what? You aren't going to scale, unless your dataset can be broken up into smaller chunks.

 

[truegenius]

""but many were, including jdwii, whose arguments now about the importance of IPC""
😱 name calling

i too have am3+, because there was no choice in my budget (lack of availability)

the thing that matters most is performance but at resonable price,
and performance=ipc or ipg or perforance per ghz x ghz x number of cores
and ipc and ghz matters more followed by core (atleast 2c)

 

[Chad Boga]

""but many were, including jdwii, whose arguments now about the importance of IPC""
😱 name calling

You do realise I am defending jdwii, don't you?

 

[-Fran-]

Palladin is wrong and it looks like you haven't even understood his disingenuous arguments.

Bulldozer has a clock speed advantage over SB, it has a core advantage, it has pricing, thermals and energy use that one could live with, so where does it fall down against SB, other than clearly on IPC.

Well, I agree in the IPC disadvantage, but you're forgetting the process advantage Intel has. It's a ridiculously big advantage so BD took the most painful kick right there and as a consequence has higher power consumption in the target speeds to be at least "competitive" with the new approach, which gives the problem of heat and stuff. They can't clock it higher, so at the end of the road, it just trails everything in the market, including it's own previous gen.

Just to add a little more to that; having "low IPC" is the result of a bad scheduling and cache on the design and construction part. Intel has an obvious advantage in process, and AMD wanted to bet on GF delivering a better 32nm after the Llano expedition... It wasn't good enough.

So, all in all, IPC is not the "only one", but process and a little more in-depth in the IPC argument, some key problems for the construction itself. So palladin is not wrong in what he states, since that's how a CPU works actually.

The cache problems could be a bad decision call or just a problem with the construction/process. The good thing, is that both of them can be fixed down the road and will have the consequence of showing higher IPC (just a little, maybe), but the most important will be the mature 32nm process IMO (higher clocks, not stupidly high consumption).

It's really entrapped in the same/similar argument and hard to tell apart, but if you want to summarize the "BD fail", IPC alone is not enough IMO.

but we are still limited by software not able to use more core effectively

Ugh, to be honest, I side with gamerk a little there... More cores won't solve what software design can't. Solving the problem of parallelism is not a trivial one, even more when most programs have to be designed from the beginning with parallelism in mind (this is thinking about current APIs and Frameworks that are not well threaded).

At some point, you can thread stuff (thinking about a single program at a time) very good, but you'll always hit the "sync wall". For a lot of parallelism, you'll need to coordinate and watch the threads for balance and overlapping (depending on how you thread, is what you must watch). That's an OS + programming problem. The more "fine tuning" you make and parallelism you want, the more difficult it gets for a CPU. Adding that to what the computer is running on a daily basis, then the OS takes the ball with the scheduling approach it chooses to use (at least in Linux you can see what you want to use and how to use it).

Balance is the key word here. Intel is sitting comfortable at 4 solid cores at the moment in the Desktop, because the Industry is not pushing more than that. It will change down the road and AMD doesn't have the leveraging power to do so, unfortunately, but we'll get there eventually, hahaha.

Cheers!

 

[truegenius]

^^
my board is is with 880g + amf+ (black 😀 )
even 7 😱 series also supports bd

 

[gamerk316]

Just for kicks, I'm going to compare a FX-8170 and i7-2600k, at stock, to highlight IPC.

For this discussion, I'm going to take a random benchmark, take the speed/performance difference of the CPU's, and calculate IPC for that benchmark. I'm assuming a CMT core is 80% efficent, a HTT Core is 10% efficent, and 100% core loading. [Big assumption there, I know]

i7 2600:
Speed: 3400
Performance: 119

BD 8150:
Speed: 3600
Performance: 76.2

Reducing to 1:

i7 2600:
Speed: 1
Performance: 1.56

BD 8150:
Speed: 1.06
Performance: 1

Solving for IPC:

i7 2600
Performance = (IPC * Clockspeed) * 4 + ((IPC * Clockspeed) * 4) * .10 [HTT cores]
1.56 = IPC*4 + IPC*.4
1.56 = 4.4IPC
IPC = 1.56/4.4
IPC = .3545

FX 8150
Performance = (IPC * Clockspeed) * 4 + ((IPC * Clockspeed) * 4) * .80 [CMT cores]
1.56 = 1.06IPC*4 + 1.06IPC*3.2
1.56 = 4.24IPC + 3.392IPC
1.56 = 7.362IPC
IPC = 1.56/7.362
IPC = .2119

Reducing to 1:
BD 8150 IPC = 1
SB i7 2600 IPC = .3545 / .2119 = 1.679

So, assuming full core loading [a huge assumption, I know], SB's IPC is ~1.68 times BD's for this particular benchmark. If not 100% loading, then the results will be skewed in favor of SB.

Conclusion: IPC MATTERS.

 

[Chad Boga]

Well, I agree in the IPC disadvantage, but you're forgetting the process advantage Intel has. It's a ridiculously big advantage so BD took the most painful kick right there and as a consequence has higher power consumption in the target speeds to be at least "competitive" with the new approach, which gives the problem of heat and stuff. They can't clock it higher, so at the end of the road, it just trails everything in the market, including it's own previous gen.

Just to add a little more to that; having "low IPC" is the result of a bad scheduling and cache on the design and construction part. Intel has an obvious advantage in process, and AMD wanted to bet on GF delivering a better 32nm after the Llano expedition... It wasn't good enough.

So, all in all, IPC is not the "only one", but process and a little more in-depth in the IPC argument, some key problems for the construction itself. So palladin is not wrong in what he states, since that's how a CPU works actually.

The cache problems could be a bad decision call or just a problem with the construction/process. The good thing, is that both of them can be fixed down the road and will have the consequence of showing higher IPC (just a little, maybe), but the most important will be the mature 32nm process IMO (higher clocks, not stupidly high consumption).

It's really entrapped in the same/similar argument and hard to tell apart, but if you want to summarize the "BD fail", IPC alone is not enough IMO.

No it is completely enough.

Your response mixes up the causes of why AMD's IPC isn't as high as they might like, with the issue of the importance of IPC to why BD lags behind SB.

That needs to be separated for starters.

Palladin's comments were about downplaying IPC because in the server world you can overcome IPC deficiency with extra cores, but that issue in server land isn't being disputed by anyone, because jdwii was only talking about desktop use.

Then blabbing on about two different CPU's where one is clocked 10 times faster than the other, is an irrelevancy to BD and SB when their clock rates are so close.

 

[gamerk316]

No it is completely enough.

Your response mixes up the causes of why AMD's IPC isn't as high as they might like, with the issue of the importance of IPC to why BD lags behind SB.

That needs to be separated for starters.

Palladin's comments were about downplaying IPC because in the server world you can overcome IPC deficiency with extra cores, but that issue in server land isn't being disputed by anyone, because jdwii was only talking about desktop use.

Then blabbing on about two different CPU's where one is clocked 10 times faster than the other, is an irrelevancy to BD and SB when their clock rates are so close.

Right on.

 

[-Fran-]

No it is completely enough.

Your response mixes up the causes of why AMD's IPC isn't as high as they might like, with the issue of the importance of IPC to why BD lags behind SB.

That needs to be separated for starters.

Palladin's comments were about downplaying IPC because in the server world you can overcome IPC deficiency with extra cores, but that issue in server land isn't being disputed by anyone, because jdwii was only talking about desktop use.

Then blabbing on about two different CPU's where one is clocked 10 times faster than the other, is an irrelevancy to BD and SB when their clock rates are so close.

That's exactly the other big cause of BD's poor showing. BD isn't supposed to be clocked near SB. That bet on GF's 32nm maturity was a lose/lose gamble. Taking head on Intel in the "process" game was the worst decision call of all IMO.

That's why I say that IPC alone can not account for BD's fail by itself. Half maybe, but oh well.

I don't want to start (again... again, again xD) the P3 vs P4 vs Athlon first gen debacle, but that's the prime example on betting on a process node. Down the road the P4 got the hertz it needed to become on par and that's it. Now Intel said "ok, screw the hertz race" and focused on better IPC and process. Insta win.

Now, I don't know how much better the 32nm process for PD will be, but the first example will come in the form of Trinity so we'll be able to extrapolate some information and project how it will fare against SB/IB and BD. The best educated guess will be "close, but still not enough".

Cheers!

 

[truegenius]

example
i3 can beat fx8 in offline low threaded gaming, but can't in threaded tasks like compressing a file using 7zip lzma2 compression method using multithreading.

 

[earl45]

, but you're forgetting the process advantage Intel has. It's a ridiculously big advantage so BD took the most painful kick right there

From what I understand Intel has always had a big process lead over AMD, this argument and that way of thinking is so dead. With Intels process lead we as consumers got Athlon 64 and The first FX cpu's
do I need to say anymore?

 

[-Fran-]

, but you're forgetting the process advantage Intel has. It's a ridiculously big advantage so BD took the most painful kick right there

From what I understand Intel has always had a big process lead over AMD, this argument and that way of thinking is so dead. With Intels process lead we as consumers got Athlon 64 and The first FX cpu's
do I need to say anymore?

When AMD sold their fabs, that advantage became ridiculously big projecting that to this day. It's like when comparing 2 fast cars in the street. In the first 50mts (or say, 1/10 mile), they'll be close, but you know the other has an advantage and when they're reaching the first kilometer (or mile), they're very far away from each other that the advantage becomes ridiculous.

Cheers!

 

[palladin9479]

No one is arguing more cores are useful. But its important to remember, within the confines of a SINGLE PROCESS, it is not always easy to make the code parallel to the point where you see a benefit of more cores. Games tend to be one such example.

More cores works great when dealing with hundreds of processes, even if non of them can scale. I've always held BD is a great design for a server CPU, where this condition holds true.

More cores works great for multiple processes, but thats no guarentee that a SINGLE process can scale to any degree.

My point is that your only measuring a single item in a controlled environment with everything else turned off.

This is not what happens in reality, not even close. I wasn't joking about that 939 threads on my internet accessible work PC (only for Email / Internet, my real work happens on a controlled isolated network). The only two applications I had running where Firefox and Outlook, everything else was a system service or management process. Gone are the days of using a boot disk to load DOS and running Doom / Quake / Hexen with 100% of your systems power. "Games" now share the system with everything else you have running, I and I hope to heck everyone here has a good AV solution and security suite running at a minimum.

Here at my home, my home PC has 679 threads, 61 process's and 15775 handles open. All I have open is Waterfox (64-bit firefox build) with ~15 tabs. When I'm playing an MMO I got a lot more things open, including Vent and several folders with maps and webpages. Single player games I'm more focused on and I'm still running a ton of things in the background.

That is what I'm talking about, all those things require CPU time on top of your game and all system events. I think people really underrate the sheer amount of things happening in the background on your computer, modern PC's are a miracle of technology. I used overly large numbers on purpose, and I stated so. They were to make it easily to distinguish the difference between actual performance and the myth that is "IPC", or at least the way it's been used in the last few years. It's not a performance metric, it's an efficiency metric used to determine the processing width and prefetch / prediction systems.

So I'll say it again, when your counting instructions per cycle (IPC), which instructions are you counting exactly? Can anyone give me an exact count on the number of instructions per cycle that any of the current modern CPU's can do? Does anyone here even know how man cycles it takes a SB to execute a single ADD, MUL, MOV or CMPEXCHNG? The same for the K10 or the BD uArch? Does anyone even know the exact instructions being used in those games your waiving around?

What I hear is a bunch of people who want to paint their body in blue paint and run at the guys (gals) wearing green paint while swinging swords and maces, yelling a battle cry (FOR INNNNTEEEEELLLLLL!!!!!)

I would so totally pay to see that actually happen ... LARPers gotta luv em.

 

[gamerk316]

example
i3 can beat fx8 in offline low threaded gaming, but can't in threaded tasks like compressing a file using 7zip lzma2 compression method using multithreading.

Due to lack of scaling. Hence why when you are limited to just a few cores, the stronger IPC of the i3 pulls it ahead. Once you go beyond 2 core scaling, the FX8 starts to pull ahead, simply due to more total horsepower.

 

[gamerk316]

My point is that your only measuring a single item in a controlled environment with everything else turned off.

This is not what happens in reality, not even close. I wasn't joking about that 939 threads on my internet accessible work PC (only for Email / Internet, my real work happens on a controlled isolated network). The only two applications I had running where Firefox and Outlook, everything else was a system service or management process. Gone are the days of using a boot disk to load DOS and running Doom / Quake / Hexen with 100% of your systems power. "Games" now share the system with everything else you have running, I and I hope to heck everyone here has a good AV solution and security suite running at a minimum.

Here at my home, my home PC has 679 threads, 61 process's and 15775 handles open. All I have open is Waterfox (64-bit firefox build) with ~15 tabs. When I'm playing an MMO I got a lot more things open, including Vent and several folders with maps and webpages. Single player games I'm more focused on and I'm still running a ton of things in the background.

That is what I'm talking about, all those things require CPU time on top of your game and all system events. I think people really underrate the sheer amount of things happening in the background on your computer, modern PC's are a miracle of technology. I used overly large numbers on purpose, and I stated so. They were to make it easily to distinguish the difference between actual performance and the myth that is "IPC", or at least the way it's been used in the last few years. It's not a performance metric, it's an efficiency metric used to determine the processing width and prefetch / prediction systems.

So I'll say it again, when your counting instructions per cycle (IPC), which instructions are you counting exactly? Can anyone give me an exact count on the number of instructions per cycle that any of the current modern CPU's can do? Does anyone here even know how man cycles it takes a SB to execute a single ADD, MUL, MOV or CMPEXCHNG? The same for the K10 or the BD uArch? Does anyone even know the exact instructions being used in those games your waiving around?

What I hear is a bunch of people who want to paint their body in blue paint and run at the guys (gals) wearing green paint while swinging swords and maces, yelling a battle cry (FOR INNNNTEEEEELLLLLL!!!!!)

I would so totally pay to see that actually happen ... LARPers gotta luv em.

1: Low level OS threads tend to be very highly optimized. Their performance impact on benchmarks is negligable. You can chalk maybe a 5% difference in performance up to differences in the OS, but nothing more.

2: Benchmarks are run on the same OS config, so there shouldn't be any significant impact when comparing two CPU's against eachother.

3: As I said in my posts: IPC varies depending on the instructions used. Hence why you have to calculate IPC per program. Its not a flat number. But you can look at a variety of benchmarks, and generalize where the CPU is strong/weak.

4: We don't need the raw IPC numbers, we just need to see the performance difference. In my above example, SB is 1.6x as fast as BD [assuming 100% core loading]. In other benchmark that uses different CPU instructions, that number could be significantly different. Hence the need for a wide range of benchmarks.

 

[truegenius]

""paint their body in blue paint and run at the guys (gals) wearing green paint""
-mine is black with a little of green

ppgpc (IPC) (performance per ghz per core)
but ipc sounds more attractive

 

[earl45]

When AMD sold their fabs, that advantage became ridiculously big projecting that to this day. It's like when comparing 2 fast cars in the street. In the first 50mts (or say, 1/10 mile), they'll be close, but you know the other has an advantage and when they're reaching the first kilometer (or mile), they're very far away from each other that the advantage becomes ridiculous.

Cheers!

See when the selling of the fab's was going on we were all told how great this would be for AMD
opening the fab to other customers meant more money for AMD, and GF would put AMD business
first, What happened here?
The ever changing story.

 

[palladin9479]

Just for kicks, I'm going to compare a FX-8170 and i7-2600k, at stock, to highlight IPC.

For this discussion, I'm going to take a random benchmark, take the speed/performance difference of the CPU's, and calculate IPC for that benchmark. I'm assuming a CMT core is 80% efficent, a HTT Core is 10% efficent, and 100% core loading. [Big assumption there, I know]

http://images.anandtech.com/graphs/graph4955/41709.png

i7 2600:
Speed: 3400
Performance: 119

BD 8150:
Speed: 3600
Performance: 76.2

Reducing to 1:

i7 2600:
Speed: 1
Performance: 1.56

BD 8150:
Speed: 1.06
Performance: 1

Solving for IPC:

i7 2600
Performance = (IPC * Clockspeed) * 4 + ((IPC * Clockspeed) * 4) * .10 [HTT cores]
1.56 = IPC*4 + IPC*.4
1.56 = 4.4IPC
IPC = 1.56/4.4
IPC = .3545

FX 8150
Performance = (IPC * Clockspeed) * 4 + ((IPC * Clockspeed) * 4) * .80 [CMT cores]
1.56 = 1.06IPC*4 + 1.06IPC*3.2
1.56 = 4.24IPC + 3.392IPC
1.56 = 7.362IPC
IPC = 1.56/7.362
IPC = .2119

Reducing to 1:
BD 8150 IPC = 1
SB i7 2600 IPC = .3545 / .2119 = 1.679

So, assuming full core loading [a huge assumption, I know], SB's IPC is ~1.68 times BD's for this particular benchmark. If not 100% loading, then the results will be skewed in favor of SB.

Conclusion: IPC MATTERS.

Umm no. Stop

There isn't 100% core loading, note even close. Just look at the i3 numbers which has 50% of the processor capacity that the I5/I7 has.

Stop with all the single player timed loop demo bench's, their almost all single threading only and tend to be compiled with the Intel compiler. The I5 is a four core CPU with three ALU's and 1 FPU per core. The BD has two ALU's and 1 FPU per "core" but shared the L2 cache and the decoded with another core. The two FPU's can bond together to execute a single 256-bit instruction or two separate 128-bit instructions.

This gives the SB a theoretical 12 integer micro-ops per cycle (less for actual x86 instruction) and four SIMD instructions per cycle. The BD would have 16 integer micro-ops per cycle and eight SIMD instructions per cycle.

The BD has by far the greater processor power. Where Intel is crushing AMD is in processor utilization, Intel's superior branch prediction / caching mechanism allows them to keep all twelve of those ALU's (four FPUs) busy with work. AMD's current sharing concept is introducing inefficiencies into their processor, rarely are all 16 of those ALU's busy and even more rare is all eight of the SIMD FPU's being busy. This is why you can get better "benchmarking" performance out of an 8xxx series BD by disabling every other "core". It removes the arbitration issues and allows the remaining 8 ALU's and four FPU's to not be stalled out, but then two ALU's per core is no competition for SB's three ALU's per core.

If your going to criticize something then at least criticize the right things. And never again should you attempt to use "frames rendered per second while playing a game" to understand IPC / CPU potential. If I ever attempted to do that I would be laughed at by both my boss's and my peers. There are special tools designed specifically to measure and understand those concepts. Take a long read over at Agner's site, start with his optimization guides and look at some of his tools. People will learn more about how to measure and understand a processor's potential from there then they would pounding out angry / insulting responses while painting their face in various shared of Blue and Green. This isn't about blue vs green, it's about understanding some very key principles that differentiate processor performance and processor utilization.

 

[palladin9479]

""paint their body in blue paint and run at the guys (gals) wearing green paint""
-mine is black with a little of green

ppgpc (IPC) (performance per ghz per core)
but ipc sounds more attractive

Haha reading some of the responses I could only think of scenes from brave heart where they paint themselves blue and run screaming towards the "enemy". So that's what I'm going to refer all "Intel is the bestest EVAR!!!", "AMD is the bestest EVAR", "Intel / AMD SUCKS MONKEY B***Z!!!!!" type responses as. So many of the Pro-one-side-or-the-other take each others posts out of context then apply Internet logic to it when generating a response. It's become more a battle of who can make the wittier response while ignoring as much of what the other guy said as possible.

We can all agree that Intel has a more efficient CPU design. Why do the blue painted people then feel the burning need to announce to all the world how great their blue deity is while denouncing the green deity and calling anyone who disagrees heretics? It's become amusing to watch.

 

[noob2222]

Just for kicks, I'm going to compare a FX-8170 and i7-2600k, at stock, to highlight IPC.

For this discussion, I'm going to take a random benchmark, take the speed/performance difference of the CPU's, and calculate IPC for that benchmark. I'm assuming a CMT core is 80% efficent, a HTT Core is 10% efficent, and 100% core loading. [Big assumption there, I know]

http://images.anandtech.com/graphs/graph4955/41709.png

______ CUT _______

Conclusion: IPC MATTERS.

This is where math and simple logic get flawed. NO PROGRAM TESTS PURE IPC. Closest we have to IPC testing is synthetics such as sisoftware sandra. IPC as you call it changes from program to program, so instead of dealing with pure ipc, we are back to the entire discussion of software optimizations. If you want to review it, go back about 10 pages or so, not going to bring it back up.

Sure this program works great with intel, but is it fully utilizing AMD's hardware code?

If not, can you really call this IPC since only half of the cpu core was actually used? [strike]SSE3, SSE4, MMX[/strike]

Granted this is full cpu [strike]IP[/strike]C, but IPC not = to /8

Pretty much in today's standards, IPC[strike]lock[/strike] is a dead term other than comparing like cpus, IE SB to IB, Phenom to Phenom II, BD to PD.

 

[noob2222]

Haha reading some of the responses I could only think of scenes from brave heart where they paint themselves blue and run screaming towards the "enemy". So that's what I'm going to refer all "Intel is the bestest EVAR!!!", "AMD is the bestest EVAR", "Intel / AMD SUCKS MONKEY B***Z!!!!!" type responses as. So many of the Pro-one-side-or-the-other take each others posts out of context then apply Internet logic to it when generating a response. It's become more a battle of who can make the wittier response while ignoring as much of what the other guy said as possible.

We can all agree that Intel has a more efficient CPU design. Why do the blue painted people then feel the burning need to announce to all the world how great their blue deity is while denouncing the green deity and calling anyone who disagrees heretics? It's become amusing to watch.

 

[jdwii]

These crazy exaggerated clockspeed discrepancies being used in theoretical discussions involving IPC, is a continuation of the woeful behaviour which saw gullible and/or young posters on forums all around the world getting sucked into buying an AM3+ motherboard before Bulldozer came out.

We all saw how well that worked, but hey, some people need to be sacrificed, to meet other people's ideological obsessions.

Thank god some one got what i was saying!

 

[jdwii]

I wonder how many people waited and bought the Z77 MoBos... Hell, even waited for IB.

What you said there, works both ways. But I'm sure you'll twist it and keep the "all the people buying AMD is stupid" mantra. Your sarcasm is getting very annoying.

---

Anyway, instead of talking and screaming about what a single core can do for your lives (IPC), why not think about what palladin said for a moment. IPC is just another metric, but by itself means squat.

Cheers!

To give you guys the truth i think cycles per instruction is a little more important, But IPC Plus CPI is what gives the Performance per clock metric. Not to mention Clock speed but STOP STOP STOP saying that IPC is just a metric its extremely important as is clock speed but again Intel is clocking their CPU's almost as high as Amd so Amd is running out of headroom so what else do they need to do to get extra performance. I'll give you guys a hint its not Moar cores. Most programs use 4 cores or less and Intel is giving us 4 cores for the price of Amd's 8.

And more cores doesn't always help in servers their is times where the 12 core Opteron beats the 16 core BD.

 

[gamerk316]

This is where math and simple logic get flawed. NO PROGRAM TESTS PURE IPC. Closest we have to IPC testing is synthetics such as sisoftware sandra. IPC as you call it changes from program to program, so instead of dealing with pure ipc, we are back to the entire discussion of software optimizations. If you want to review it, go back about 10 pages or so, not going to bring it back up.

Sure this program works great with intel, but is it fully utilizing AMD's hardware code?

If not, can you really call this IPC since only half of the cpu core was actually used? [strike]SSE3, SSE4, MMX[/strike]

http://media.bestofmicro.com/M/S/310564/original/sandra multimedia.png

Granted this is full cpu [strike]IP[/strike]C, but IPC not = to /8

Pretty much in today's standards, IPC[strike]lock[/strike] is a dead term other than comparing like cpus, IE SB to IB, Phenom to Phenom II, BD to PD.

As I said, several times: I measured IPC for a specific program. As I also noted, IPC varies depending on workload; it is NOT a flat value. I also noted up front I was assuming 100% core loading, which is almost certainly not true.

My entire point was to show that for a given benchmark, where the performance and processor speed are known, you can mathematically calculate IPC for that benchmark. Heck, you could factor CPU load too, to make an even more accurate calculation. In any case, do that across a variety of different CPU bound tests, and you get an idea how much IPC affects the results.

In terms of pure processing power at 100% load in non-CPU bound programs, BD is significantly more powerful then SB. Problem is, more often then not, that condition I just listed is not true, so the higher IPC of SB overcomes core count and an increased number of CPU cycles BD offers.

 

[jdwii]

No it is completely enough.

Your response mixes up the causes of why AMD's IPC isn't as high as they might like, with the issue of the importance of IPC to why BD lags behind SB.

That needs to be separated for starters.

Palladin's comments were about downplaying IPC because in the server world you can overcome IPC deficiency with extra cores, but that issue in server land isn't being disputed by anyone, because jdwii was only talking about desktop use.

Then blabbing on about two different CPU's where one is clocked 10 times faster than the other, is an irrelevancy to BD and SB when their clock rates are so close.

+1 On that now if Sandy was clocked at 1.0Ghz and BD was clocked at 3.2Ghz this would be a different story! I'm so sick of Amd and amd fans downplaying Single core performance.

And like i keep saying Intel is not giving us 1 core when Amd is giving us 8 their giving us 4 Powerful cores when amd is giving us 8 mediocre cores(Around the same price range) which have about 50% the performance per core of Intel maybe a little more. Since when all 8 cores are active is usually(At best) can only give 10% better performance then the 4 core from intel but since this really ever happens it doesn't get that chance.