Official Improvements of Piledriver Cores.

[SickBeast]

I'm not believing AMD's hype and PR BS any more.

I will read reviews of Piledriver and that's it.

Intel was able to tweak the P4 into a decent chip, but even with the refresh I was not interested. I'm not the least bit interested in Piledriver and its 8 "virtual" cores. I would take a powerful dual core over it any day of the week.

 

[sandorski]

So you begin to actually contribute to the thread instead of saying useless one-liners?

Funny how you make a statement then go and hide, not backing it up in any way.

:\

 

[LOL_Wut_Axel]

You're aware that's still wrong, right?

http://en.wikipedia.org/wiki/Instructions_per_cycle
I'd implore you to read the link you yourself posted earlier in the thread.

IPC is workload dependent, ISA dependent, and is affected by fab process and the entirety of the CPU architecture itself. It's just a small piece of the puzzle that you've misrepresented and assumed it's a good representative of the whole shibang (shimove shimove).

I'm not saying that it's not important or that AMD wasn't wrong in attempting to keep IPC the same, I'm just saying you should have an idea of what you're talking about before you assume others don't.

You're aware that doesn't change any of what I said as being factual, at all, right?

IPC is workload dependent to some degree, sure, and your point is...?
ISA affects IPC to some degree, sure, but your point is...? Intel and AMD have been very similar when it comes to the ISA for a long time now.
Fab process and foundry? That affects things like clock speeds, leakage, and yields.

I'm still waiting for your answer on how those things affect my statements. IPC IS the measure of the raw speed of a CPU architecture.

 

[pelov]

Fab process and foundry? That affects things like clock speeds, leakage, and yields.

Which in turn affect your design thus affecting your IPC.

And by "some degree" you mean anything from 0-15%+ on a tick, right? It depends on the workload a whole lot more than "some degree" but by a whole lot. That's why the term IPC is so generic and gets tossed around to a point where it means nothing (like in this very thread) instead of its actual incredibly convoluted and complex meaning that shouldn't weigh too heavily when discussing processor performance unless you're talking about a single application, because, again, the generic "IPC" doesn't mean much unless you do something like what's posted below. Consider, too, that it's IPC, the last two words being "per clock," thus it's heavily affected by attainable clock speeds (another reason why fabs matter).

I'm not picking on you because you made a mistake about what IPC actually is and what affects it. Hell, I do that too on occasion and mistakenly put IPC instead of single-threaded performance (Bad pelov!!!) but you're just the loudest one here so I figure if we're gonna talk about it we might as well get the damn term correct.

And if you've been paying attention to my previous replies on this thread, or other threads regarding the BD matter, I actually agree with you that the chase for clock speeds at the cost of IPC -- yes, even despite the fab advantage (which does make a difference) -- is a step backwards considering the die size and core count and subsequently the neutering of potential clock speed gains should have been seen from the beginning. So quit beating a dead horse, and if you do at least use a proper bat.

 

[blckgrffn]

You're aware that doesn't change any of what I said as being factual, at all, right?

IPC is workload dependent to some degree, sure, and your point is...?
ISA affects IPC to some degree, sure, but your point is...? Intel and AMD have been very similar when it comes to the ISA for a long time now.
Fab process and foundry? That affects things like clock speeds, leakage, and yields.

I'm still waiting for your answer on how those things affect my statements. IPC IS the measure of the raw speed of a CPU architecture.

IN WITH THE INEVITABLE CAR ANALOGY:

Talking just about IPC (alone) is like talking about peak horsepower without discussing peak torque curves or RPM - or application.

ie, out of context sounds nice but isn't especially useful.

And since when did posts need to add "value" to threads? That subjective bar got tossed long, long ago...

Dammit, and beaten by pelov with a nice reply. You aren't allowed to post new stuff while I am typing.

 

[deimos3428]

That's why the term IPC is so generic and gets tossed around to a point where it means nothing (like in this very thread) instead of its actual incredibly convoluted and complex meaning that shouldn't weigh too heavily when discussing processor performance unless you're talking about a single application, because, again, the generic "IPC" doesn't mean much unless you do something like what's posted below. Consider, too, that it's IPC, the last two words being "per clock," thus it's heavily affected by attainable clock speeds (another reason why fabs matter).

I just wanted to say thanks for spelling that out (literally), because for the longest time I thought it meant "Inter-process communication" and I couldn't figure out what you guys were on about at all.

 

[LOL_Wut_Axel]

Which in term affect your design thus affecting your IPC.

And by "some degree" you mean anything from 0-14% on a tick, right?

I'm not picking on you because you made a mistake about what IPC actually is and what affects it. Hell, I do that too on occasion and mistakenly put IPC instead of single-threaded performance (Bad pelov!!!) but you're just the loudest one here so I figure if we're gonna talk about it we might as well get the damn term correct.

And if you've been paying attention to my previous replies on this thread, or other threads regarding the BD matter, I actually agree with you that the chase for clock speeds at the cost of IPC -- yes, even despite the fab advantage (which does make a difference) -- is a step backwards considering the die size and core count and subsequently the neutering of potential clock speed gains should have been seen from the beginning. So quit beating a dead horse, and if you do at least use a proper bat.

Those are from improvements made to the architecture itself and not it being on a different process node and having 3D transistors. Simply being on a new process node and having new transistors won't make the architecture itself magically faster. Those improvements are things that didn't make it to Sandy Bridge because of time. It doesn't have anything to do with the process node.

Tom's Hardware found a 3.7% avg. difference in performance, so that's that.

 

[LOL_Wut_Axel]

IN WITH THE INEVITABLE CAR ANALOGY:

Talking just about IPC (alone) is like talking about peak horsepower without discussing peak torque curves or RPM - or application.

ie, out of context sounds nice but isn't especially useful.

And since when did posts need to add "value" to threads? That subjective bar got tossed long, long ago...

Dammit, and beaten by pelov with a nice reply. You aren't allowed to post new stuff while I am typing.

About 99 out of every 100 car analogies posted on message boards end up being horrible. This is one of them.

Also, as has been demonstrated time and time again, IPC doesn't just "sound nice". It's the most important factor when looking at desktop CPU performance. It's the reason why Netburst and the Pentium 4 failed and the reason why Bulldozer and FX are failing right now.

I've already discussed why it's important, so I won't go into that yet again.

 

[pelov]

Those are from improvements made to the architecture itself and not it being on a different process node and having 3D transistors Simply being on a new process node and having new transistors won't make the architecture itself magically faster. Those improvements are things that didn't make it to Sandy Bridge because of time. It doesn't have anything to do with the process node.

Tom's Hardware found a 3.7% avg. difference in performance, so that's that.

Thus they affect IPC because that's what happened, right? And what's that about trigate + process + node? Am I seeing this correctly? You're assuming that my point was that tri-gate and a new node inherently increases IPC rather than allows for leg room, lower leakage, lower TDP and more transistors to play around with to increase IPC? If that's the case I'm not sure whether I should put you on ignore or concede to being trolled the fuck out.

The average depends on the workloads tested. That's exactly what I mean by IPC being a relatively empty term unless we're application specific, but even then there are a variety of other factors to take into account. Using the term IPC is all fine and dandy so long as we understand that it's a rough guesstimate of a very broad term representing a whole lot of variables but that's something you don't seem to grasp.

 

[guskline]

I love Ancalagon 44's last sentence of his post. I'm holding pat on my 1100 Thuban @ 4 Ghz. Maybe if Piledriver releases with modest improvement it might make me jump. Sadly, Bulldozer didn't. What it did do is convince me to try the 2500k Sandy Bridge.

 

[blckgrffn]

About 99 out of every 100 car analogies posted on message boards end up being horrible. This is one of them.

Also, as has been demonstrated time and time again, IPC doesn't just "sound nice". It's the most important factor when looking at desktop CPU performance. It's the reason why Netburst and the Pentium 4 failed and the reason why Bulldozer and FX are failing right now.

I've already discussed why it's important, so I won't go into that yet again.

So, you're in a computer org class now or what? What is your technical expertise backing this up?

Since you didn't get it, a car analogy is supposed to be a joke and a potential pressure release valve/out for a thread.

 

[LOL_Wut_Axel]

Thus they affect IPC because that's what happened, right? And what's that about trigate + process + node? Am I seeing this correctly? You're assuming that my point was that tri-gate and a new node inherently increases IPC rather than allows for leg room, lower leakage, lower TDP and more transistors to play around with to increase IPC? If that's the case I'm not sure whether I should put you on ignore or concede to being trolled the fuck out.

The average depends on the workloads tested. That's exactly what I mean by IPC being a relatively empty term unless we're application specific, but even then there are a variety of other factors to take into account. Using the term IPC is all fine and dandy so long as we understand that it's a rough guesstimate of a very broad term representing a whole lot of variables but that's something you don't seem to grasp.

Not equal more performance, that's for sure. And process is not something that goes separate node; they're not separate things. It's process node, not process + node.

Intel had more than enough room to include those improvements in Sandy Bridge while still being able to hit their power targets. There just wasn't enough time, so it was included with Ivy Bridge instead, along with the improvements in power consumption and heat due to the new transistors and process node. Architectural improvements are made years in advance, and by the time Intel came up with those small improvements for SB it was too late to make it into production, so it's put on IB instead.

Also, your whole mumbo jumbo about IPC makes it seem like it's something that varies a lot--you can have 50% more in one application than the other--and that's patently false. The results on Tom's Hardware comparing CPU architecture show that most of the results were very consistent. Yes, there could be small deviations 1/10 times, but that doesn't change anything like you make it seem. IPC is extremely important when it comes to determining how much total performance you can extract out of a CPU or CPU series, so it's very relevant.

 

[pelov]

Not equal more performance, that's for sure. And process is not something that goes separate node; they're not separate things. It's process node, not process + node.

No. I'll let you do the research here but it should be quite obvious

Also, your whole mumbo jumbo about IPC makes it seem like it's something that varies a lot--you can have 50% more in one application than the other--and that's patently false.

I said 15%+ but somehow you mumbo jumbo'd it into 50% more so you can argue that the straw man's hat definitely doesn't fit his head, despite the fact that you made them both. So no, I agree with you and you should quit arguing with yourself.

I think if we've learned anything on this thread it's that you have absolutely no idea what IPC means but seem convinced that it's the most important thing when designing a desktop CPU and want everyone to know it. Also that it's incredibly annoying.

"You said this number that you never said and it's totally wrong because nobody's said it except me but it's totally wrong therefore you're wrong."

 

[Atreidin]

Not equal more performance, that's for sure. And process is not something that goes separate node; they're not separate things. It's process node, not process + node.

Intel had more than enough room to include those improvements in Sandy Bridge while still being able to hit their power targets. There just wasn't enough time, so it was included with Ivy Bridge instead, along with the improvements in power consumption and heat due to the new transistors and process node. Architectural improvements are made years in advance, and by the time Intel came up with those small improvements for SB it was too late to make it into production, so it's put on IB instead.

Also, your whole mumbo jumbo about IPC makes it seem like it's something that varies a lot--you can have 50% more in one application than the other--and that's patently false. The results on Tom's Hardware comparing CPU architecture show that most of the results were very consistent. Yes, there could be small deviations 1/10 times, but that doesn't change anything like you make it seem. IPC is extremely important when it comes to determining how much total performance you can extract out of a CPU or CPU series, so it's very relevant.

Yes, you CAN have IPC vary a lot. Some applications use certain instructions more than others, and different instructions take a different amount of cycles to complete. Not to even mention that you can have one instruction do the work of several, and take a different amount of time doing so. Your understanding of IPC is lacking. It is not a set number. Each program has its own IPC measurement. You can try to take an average but there will always be cases that vary a lot from it.

 

[Makaveli]

I love Ancalagon 44's last sentence of his post. I'm holding pat on my 1100 Thuban @ 4 Ghz. Maybe if Piledriver releases with modest improvement it might make me jump. Sadly, Bulldozer didn't. What it did do is convince me to try the 2500k Sandy Bridge.

I hope for AMD's sake and for the rest of us this is true. I have fond memories of my Opteron 170 which is now doing HTPC duty.

 

[Vesku]

Should probably save Piledriver speculation for when Trinity shows up.

 

[LOL_Wut_Axel]

No. I'll let you do the research here but it should be quite obvious



I said 15%+ but somehow you mumbo jumbo'd it into 50% more so you can argue that the straw man's hat definitely doesn't fit his head, despite the fact that you made them both. So no, I agree with you and you should quit arguing with yourself.

I think if we've learned anything on this thread it's that you have absolutely no idea what IPC means but seem convinced that it's the most important thing when designing a desktop CPU and want everyone to know it. Also that it's incredibly annoying.

"You said this number that you never said and it's totally wrong because nobody's said it except me but it's totally wrong therefore you're wrong."

No, it seems to me it's you that doesn't have an idea of what he's talking about. One: you mentioned ISA as being an important factor, when in terms of ISA Intel and AMD have been very similar for years. Two: you think process and node are two separate things. Three: you think the uArch improvements in IB couldn't be fit into SB when it was simply a too-late-to-integrate-into-production issue (hint: Nehalem and Westmere have the exact same IPC, so that alone debunks the myth you're spreading about Intel not being able to fit the small uArch improvements in their "tocks").

You also say IPC is nearly meaningless, which couldn't be farther from the truth. If IPC is meaningless, can you please explain how instead of chasing IPC it's a better idea to chase very high clock speeds? That idea seemed to work very well for Netburst and Bulldozer.

 

[pelov]

And if you've been paying attention to my previous replies on this thread, or other threads regarding the BD matter, I actually agree with you that the chase for clock speeds at the cost of IPC...

 

[Olikan]

Should probably save Piledriver speculation for when Trinity shows up.

but speculation is the best part of this forum

 

[LOL_Wut_Axel]

Which is funny, because that contradicts what you just said earlier, which is "IPC doesn't mean much".

So which one is it?

 

[Makaveli]

This is starting to get abit long here boys.

Can you just agree to disagree and kiss and makeup so we can go back to talking about piledriver!

 

[pelov]

It doesn't mean much to those who have no idea what it means in the first place. From henceforth you will be known as Mr. CPU Architecture

It's been fun joking with you but we've diverged completely off topic. So let's steer the ship back in the right direction:

I answered my question I posed here earlier in this thread about Llano's size-per-core with some clever googling. It turns out it's 11mm2 without the L2, which means AMD saved a decent bit of space by opting to go with the modular approach in Bulldozer and consequently Trinity.

http://www.ilsistemista.net/index.p...n-whats-wrong-with-amd-bulldozer.html?start=1

And a bit more info with this jpeg. Note how the core sizes don't shrink linearly when compared to the cache sizes

 

[AtenRa]

Pelov, I believe this will be helpful

 

[pelov]

That is awesome info. Thanks a bunch

So for only ~3mm2 more, AMD was able to fit two integer cores within a single module when compared to SB. That's far better than I thought it would be but then you have to wonder just where all that extra dead space went? I'm not certain it's all attributed to cache if you consider the overall die sizes but it does explain why the 1.2B number was considered to be too "light."

 

[ShadowVVL]

So is amd releasing a improved bobcat based apu or a single module version of trinity ?

I plan on building a htpc for movies and music.