AMD CPU speculation... and expert conjecture

[juanrga]

At task accelerated with OpenCL.
Why compare APU+HSA with CPU which doesn't even have iGPU?

I did mean HSA enabled applications.

Comparing a HSA enabled APU to one of the faster Intel CPUs offers an idea of the potential of the technology. It is not very different from those reviews that compare OpenCL applications in 3770k/4770k against a FX-8350 (which doesn't even have a iGPU).

 

[GOM3RPLY3R]

Spoiler

((EDIT: Spent 5 minutes editing the post, and lost everything. I hate the new forums more and more the more I'm here...))

You still haven't explained how it is that the 8350 with 8 cores exceeds the 3470/3570 performance in crysis 3, even though Intel has "dramatically superior" IPC.

Clockspeed.

Single Core Performance = clockspeed * IPC. Improving one is as good as improving the other. If one architecture has half the clock but double the IPC, they would perform the same.

Hence why the 3470 beats the 8150, but not the 8350. 15% IPC gains and 400 MHz worth of clock can easily account for the extra 6 FPS the 8350 gains over the 8150. Also explains why the 3470 beats the 8150, but not the 8350. Based on your "more cores" theory, both the 8150 and 8350 should be beating the 3470.

The simple solution would be to normalize clocks for the purposes of looking at scaling. Normalize all CPU clocks to, say, 3.5GHz, so IPC and Cores should be the only two things affecting the benchmark results. IPC favors Intel, Cores favor AMD. If you see all the Intel chips grouped at the top, then my theory holds.

Any takers?

Spoiler

Well, the issue I see with the logic is simple:

If IPC were the only culprit and clockspeed a direct correlation, then why does a 6 core SB-E with lower IPC than IB hold pace and exceed the higher IPC and higher clocked IB architecture?

I am not saying IPC plays no role, it clearly will in some way for anything...however, the point I am making is, it's far from the only variable at work here. More cores have a correlation too, you're just not acknowledging that.

EDIT: Let's stop comparing separate manufacturer architectures for a moment...because it's like comparing apples and oranges and saying they both make juice, but one takes more fruit to make the same amount of juice.

The comparison is naturally flawed because we have no baseline to bridge between the 2 separate uarch's.

So, in Intel architecture, clockspeed makes a correlation, but Intel does not exceed max CPU burden comfortably until you get to a 6 core CPU. Even 4 core CPUs with HTT do not break below 80+% usage average per core. The only Intel CPUs that do are 6 core w/HTT, and even then, they typically have 2-3 HTT modules running and average 50% core usage across the board (counting physical core resources not HTT modules)

In AMD architecture, The FX 6300 is about the point where you start to see CPU utilization fall below a 90% aggregate average for core usage under load. This correlates with the Intel data because the i7 Quads with HTT always have 4 cores loaded highly and 2-3 HTT modules running near their max capability. The FX 8350 and possibly 8320 (hard to say definitively without data) are likely the only 2 AMD CPUs that do not function at 80+% load on all cores running this software.

Based on this information, I can definitively say, you need 6 cores or more from either manufacturer to get below a 90-95% average resource consumption per core under load. To be at a point where the CPU actually has headroom (<80% core resources consumed average) then you need to look at an 8 core AMD or a 6 core Intel.

Clockspeed effects frame rates in an expected non-linear scaling manner, though the biggest FPS jump seen comes when going from 2 to 4 cores (24 FPS) and then from 4 to 6 cores (20 FPS) inside Intel architecture. In AMD, the jump from 4 to 6 to 8 cores scales less considerably, but are still significant jumps in FPS over something that could be achieved via clockspeed.

This tells me 2 things, the engine is sensitive to IPC/clockspeed, but more sensitive to having enough resources to run all the threads concurrently as those jumps were always more significant then jumps in clockspeed (even taking OC'ed CPU info from other forums into consideration, a 20% jump in clockspeed is less significant than the jump from 2 to 4 or 4 to 6 cores for Intel).

I really do agree with you here. It is probably the way that the CPU's are built in correlation to their IPC. It's either:

A. Lower IPC will improve performance (which, kind of is, you know, out of the bulletin)

or B. The SB-E chips physical design and possible other attributes that are added can cause a usual increase in performance. Simply, it was built more towards efficiency, as that's what anyone would do upon improving something.

Then we come to our answer, which is your statement:

The comparison is naturally flawed because we have no baseline to bridge between the 2 separate uarch's.

In which right here, you are right, and I am telling you they you're completely wrong.

On a simple manner, creating a baseline is very hard. It requires many tests, tries and failures before becoming your baseline. Of course this is with something very complex with our world of CPU technology: "IPC, CLOCKSPEED, CORE AMOUNT, ARCHITECTURE..." and so on.
---------------------------------------------------------------------------------------------------------------
There is a easy (on paper) way to solve your statement.

Let's take a break and have a mind teaser.

Student A, B, and C are taking a 3 times test:

Student A scored 90 on her first test, but only 85 on her next test, however 100 on the last. Thus her average would be: 92 (91.6 repeated rounded ; all results are rounded to the nearest unit).

Student B took the test and got 70, 75, and 60 on his. Avg: 68

Student C: 40, 50, 35 on his. Avg: 42

Obviously, the average of all three students averages will be: 67

Thus we have are median score on a rating of 0-100.

Percentile Explanation:

So then, if someone does better, you need to do this. The percent of increase or decrease is dependent on the number to the top and bottom. So 67 is 33 away from 100, out top, so 33 = +100% for the top, and for the bottom, 67 = -100%, which will be out percentile. For example, a few years ago, I was in the 90th percentile for height growth, now I am in the 70th, meaning if that average number didn't change, I'm growing less than before. IRL most percentiles are use with 50 as the median, but for this it'll be different, since it's easier this way.

Student A, getting an average of 92, will be positive, but how much?

So with 33 being our positive of 100%, and 25 being the difference from the median, we'll do some math.

Simply, you can divide 33 from 25, even though you can cross multiply and then do a multi-step equation.

33 / 25 = 0.7575 repeated. Lets round to the thousandth, so 75.8%

This means that Student A, is + 75.8%0 (above average = +, and below = -).
Student B: + 3.0%
Student C (will use 67 since he's negative): - 37.3%
--------------------------------------------------------------------------------------------------
There you have it. Simply, just use the stock CPU settings, plug and play basically, and run their test scores (from trusted sources), to see their average median. So then, if any CPU does better or worse, you can use this theory on percentile to see if they are doing better or worse. And obviously, if one does better than the other, you can tell by if its a better number. If it's negative, the lower percent, the better. If positive, the higher the better.

 

[juanrga]

A crazy idea

I read somewhat that one of main limitations of BD/PD modules was the single decode per module. If I understood this well, the decode switches between cores within a module which means cannot feed both cores in one clock. For a ten clock period, the situation would look like (A denotes first core working, B denotes second core working and _ denotes a core is not being feed)

A_
_B
A_
_B
A_
_B
A_
_B
A_
_B

Now Steamroller has twice decoders, which means each core can be feed in one clock

AB
AB
AB
AB
AB
AB
AB
AB
AB
AB

Each core in Steamroller module is being twice more efficient than in bulldozer/piledriver module, earning twice more instructions. To get the same number of A and B (10 each) one would use two bulldozer/piledriver modules

A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B

I know this is an oversimplification but could this partially explain why 4C/8C Piledriver are being replaced by 2C/4C Steamroller?

wow!... an actual AMD uarch probably related Steamroller post, in a AMD uarch "expert" Steamroller thread ????? ... naa! i think "juanrga" is derailing the thread lol

elas!.. NO decode is not the main problem... it can be, depends on the software(compiler)... the problem with decode its the same as "If" a single core per "decode engine", that is if it were there only 1 integer core would be the same problem, i.e., in x86 the "complex" decode pipe blocks the others upon more complex instructions to decode, that is, upon more than 1 MacroOp( 2 microOPs, execute + memory), the 4 decode pipe acts like if it were only 1... the same thing happens with intel uarchs.(edt)

*IF* (not easy due to the "strong dependency model" of x86, which "a priori" sees every instruction dependent on another)... it was possible that upon decoding "complex" instructions the "complex decode pipe" doesn't block the others, the "same 4 decode" pipes would act like more 2 decode engines(or more) than else...

I think that is what happens with "Steamroller", it has the same 4 decode pipes of BD/PD, only perhaps instructions from one thread don't block instructions from the other thread, that is, Steamroller must have 2 "complex" decode pipes on those 4, that assume "non-dependent" instructions by checking the "contexts", and relax the dependency checking.

Yes... steamroller most probably will have the same 4 decode pipes of BD/PD... only arranged in a different fashion.

The question of "Vertical Multi-Threading" is not the culprit either, actually it is what makes it clearly superior to any intel uarch, that VMT works upon 2 "open contexts", that is, its incredible fast "internally changing the thread contexts" ( otherwise if it were OS dependent it would be slower than a Pentium I (quite slow) lol).. and the operation is inherently "asynchronous" (quite difficult).

VMT work like this.. .contexts can change from 1 cycle to another

AA or BB ... of course A_ or B_ or _ _ can happen... ( but there NEVER is AB or BA, that is SMT and no context changing needed) (edt)... but can happen also in STM (simultaneous multithreading = hyperthreading)... or in single cores... caches misses always leads to "bubbles & stalls".

So it is not VMT the problem, since its not only decode that is VMT... its fetch, branch, dispatch including the "FlexFPU frontend". The decode problem can be fixed by relaxing the "dependency" checking and constrains upon decoding complex operations (2 "independent" complex operations, forcingly upon 2 thread contexts) .. MOAR = brute force, always leads to disappointing results.

VMT is so nice... and since a "module" is an optimized 2 cores sharing... that is, another CPU core "jumped inside" another core to make a module, that in the future i see a "module" jumping inside another module (sharing) to make a 4 core/thread module lol

I also see VMT use in a "Horizontal" way... so Horizontal Multi-Threading using the same "asynchronous open contexts" of the VMT( in an horizontal way) and each Cluster ( integer core) have more than 1 thread context, yet not being SMT(simultaneous multi-threading) but an evolution of the CMT (cluster multi-threading) concept.

[ UPDATE: in actually the scheme of of BD/PD is... A ->B -> A ->B -> ... its "interleaving", its one thread one cycle the other thread the other cycle, being the beauty of VTM that you have more fine grain control on the execution, i.e., it can be A->A->A->A->B ->B -> B -> B ... or any granularity between 1 and 4 instructions...

SteamRoller changes this to A-A ->B-B->A-A-> ... that is the "minimal granularity" passes to be " 2 instructions" in any combination up to 4( can be AAAA or BBBB)... it simplifies it, and probably wastes less power on context switches, and has no adverse effect on performance...

So the advantage of VMT over SMT is exactly the possibility of sharing resources having a fine-grain control, upon cache misses or other events, one thread never clogs the other , contrary to SMT/Hyperthreading that had to have resources augmented since Nehalem, since it was often that with SMT/HT turned off, the performance was greater than with SMT/HT on!

On VMT this is way much better (ok it doesn't approach the performance of 2 separated cores... but NOTHING will...)... if a thread just grabs all resources (and even waiting on instructions and or data can grab resources, that is, doing nothing can grab resources lol) then the VMT control can simply switch to another, it leads to much more efficient utilization of resources ]

Yeah, there are rumours I am going to be banned by posting on-topic, he he.

By the above

A_
_B
A_
_B
...

I did mean your "A ->B -> A ->B -> ..."

Now I need time to decode what do you mean by "A-A ->B-B->A-A-> ..."

There is 3 basic ways of Multithreading

2 threads in the same engine

Interleaving Multi-Threading; requires good control and very fast "context switches"... first it was used by the Cray vector processors i think... it means the pipeline starts with one thread, let say A, and then next clock cycle it changes to thread B. Usually it means the all pipeline is synchronous, the context tracking is only at the beginning, after is pretty much SMT.

This is A->B->A-B->A... but in Cray example its only at fetch, after fetch, pretty much FIFO logic dominates... first in first served.

AMD is different because it separates the pipeline in different "thread control" domains.... so its not exactly A->B->A->B etc...different "domains down the pipeline can have different forms of control.. its asynchronous... and this enters;

Block Multi-Threading; its the possibility of changing the granularity of a 2 thread engine as example. Instead of being 1 instruction from one thread, and next cycle one instruction from the other thread, it can be 2 or 3 or more from one thread, then jumps to the other thread for another block of instructions from the other thread (can be 2 3 4 or 5 ), then jumps back to the first thread again for another "BLOCK" of instructions from this one, and on and on.. understand ?

This permits much finer control, usually permits to change threads on an "event", meaning if a priority is established it can change threads, if one thread becomes a resource hog it can be blocked from grabbing more resources... usually this form of multithreading with "blocks" of instructions is also called "switch on event multi-threading"(is used by SPARC).

Again AMD is different because it uses several different domains of control, each of which can have different "events" associated... permitting so a better control over the behavior of several threads down the same pipeline

Simultaneous Multi-Threading(SMT) aka Hyperthreading; its the simpler and more widely used form of multithreading down a same pipeline, derives from wide issue RISC uarches, it feels better with wider and and fatter full of resources designs, it has "loose" control, pretty much FIFO logic, which is pretty simple... only Intel uses it in a CISC arch (like x86)... which is not the wisest, since its complexity, with usually instructions faster and slower than others, if one one instruction stalls and if first-in than it must be first out... but if it stalls , pretty much all pipeline work stalls (Nehalem and P4 earlier even worst, suffered heavily on this)...

The AA->BB->AA->BB, means the "granularity" of the "block of instructions on AMD scheme is 2 instructions form the same thread, and then jumps to the other for more 2, and on and on. But this is only the "basic" granularity most likely at "fetch", because stated and shown in all diagrams not all pipeline is VTM, and different domains can have different "events" of control, and so change granularity wisely to avoid bubbles ( the A_ or B_ ).

So AMD AFAIK, is the most advanced form of multithreading down a single pipeline, it dominates so well the "art" of very fast "context switch" that it even implements several domains of control down a pipeline... which is called "vertical Multi-threading".

And the beauty of "fast context switches" is that it can be used in a horizontal way, that is to share a "execution core" Integer or FPU or even SIMD... ,as well or better than to share a fetch or a decode engine, meaning the "module" implementation of AMD is to grow in number on threads with time, it was designed with that intention(strong suspicion). It may not be fake that "die shot" (image) that was presented here, to me it shows clearly a 4 thread module.... and if the "fast context switch" on that "open way" that is used in VTM, is used and enlarged for Horizontal( several threads on advanced ways be it "speculative multithreading" (spMT) or "dataflow approaches" ... bot of which are the things that can complement better HTM - Hardware Transactional Memory, and intelligent versioning caches).

*IF* ALL is as good as it seems don't be surprised to see in the future you'll see 8 threads per module, meaning comparing with BD/PD which has 8 threads/cores (2 per module), the new chip (that could even be smaller on smaller on smaller FAB processes) could have 32 "good" threads on a single piece of silicon.... and 5 modules is not to discard, so 40 threads in a single piece of silicon below the the 300mm² LOL... ( a MCM could have 80)

THIS IS REAL **HIGH PERFORMANCE**... no intent to be polemic or pick on intel fanboys... in actual intel designs i can't see one that can compete with this. Of course it needs software "compiled" to take advantage of those so many threads, but i think that is where the HSA compiler toolchain, which is the principal work of the HSA foundation do far, can enter!...

Intel simply can't compete with the actual designs (they need to invent something much better fast), this is even better to make a many core with real CPU cores and "control"( which MIC doesn't have, isn't a CPU), and HUGE FlexFPUs, meaning large vector AVX style crunching much better than Intel PhyX MIC (perhaps that is why they "stole" Gustafson from Intel lol)...

Of course none of this shows in the "popular new football game" of computer aficionados, ( rigged to the bone like if the federation league headquarters would be on Old Trafford Manchester lol), called benchmark review, NEW SOFTWARE is needed, BETTER SOFTWARE is needed... nothing that scares the HPC (**HIGH Performance Computing**) community.... but boy!, the single thread approach of the current x86 client/desktop PC world is so awkwardly stupidly OBSOLETE, that there is no point to pick a decent arguing... oh! well!...

Thanks by this useful reply. I would say that by "A" and "B" I didn't mean threads but cores within a module.

 

[juanrga]

Nope. It is not well-threaded because above benchmarks show how a i5 (4 threads) gives more FPS than six core i7 (12 threads). In a well-threaded game the 12 threads i7 would be faster than any other chip there including the (8-threads) FX-8350.

NO IT WOULDN'T. That's the point you're missing.

Look, I really can't simplify it any more then this (and I'm going to oversimplify, assuming no OS overhead, zero scheduling time, and perfectly parallel threads):

You have two CPU's, one is a dual core chip, and one that is a single core chip that is twice as fast. You have two parallel threads you want to run, which take up exactly 100% load on one core of the dual core chip (50% of the core on the single core chip).

In this situation, both CPU's would perform EXACTLY the same. Why? Because both would finish their work in the same exact amount of time, despite the presence of two totally independent parallel threads being run on the dual core CPU. In this case, the increased IPC+Clock of the single core CPU is good enough to let it finish in the same amount of time.

But this was not the case I was considering. I was considering something like this

where "moar cores" imply more performance because the engine is designed to go wide.

E.g. a dual core is loaded near the 100% and then a quad core gets its cores loaded above the 94% giving more performance, not two cores near 100% and two cores unused (which would give the same performance than the dual).

That is what I did mean by "well-threaded", although I would like to see an engine loading the 8 cores above the 90%.

 

[szatkus]

At task accelerated with OpenCL.
Why compare APU+HSA with CPU which doesn't even have iGPU?

I did mean HSA enabled applications.

Comparing a HSA enabled APU to one of the faster Intel CPUs offers an idea of the potential of the technology. It is not very different from those reviews that compare OpenCL applications in 3770k/4770k against a FX-8350 (which doesn't even have a iGPU).

I know you did. But it's only part of puzzle made by AMD. HSA is a great technology, but only for some computation. We still need performance of single thread.

 

[noob2222]

No need for the new boards until the new APUs hit...I can assure you by Q4 this year, you will see the new boards and APUs. Asus already has a FM2+ A87 chipset MB prototype they displayed at E3

well, i just recently heard kaveri might be delayed. aside from that i would rather see fm2+ motherboards come out ASAP, so i could build a richland system sooner and upgrade later without buying a new motherboard, im still on the fence whether i want to wait for kaveri or get a richland. But oh well' i can't move heaven and earth so that's that.
But still it seems a little silly to delay the socket if it won't affect everything else concerned except future upgradability

If I had to guess, AMD did get some pretty bad publicity for releasing 990fx am3+ motherboards with no cpus even though it was compatible with phenom II.

unfortunately its the bad people who make thing like what your wanting to do not good for a company image. as you stated, it makes sense to want an upgrade path.

 

[hcl123]

At task accelerated with OpenCL.
Why compare APU+HSA with CPU which doesn't even have iGPU?

I did mean HSA enabled applications.

Comparing a HSA enabled APU to one of the faster Intel CPUs offers an idea of the potential of the technology. It is not very different from those reviews that compare OpenCL applications in 3770k/4770k against a FX-8350 (which doesn't even have a iGPU).

What you missed is that there isn't HSA ( Heterogeneous System Architecture) without an heterogeneous PE (processing element) present... otherwise it doesn't make sense talk about HSA.

OpenCL IS NOT HSA.

OpenCL is only a way to do better multithreading with good aligned and well behaved data sets... OpenCL on the CPU alone misses *LARGE* part of its potential. But it depends on the SOFTWARE how it was designed, CPU here, AMD or Intel or other is agnostic. Matter of fact should be the other way around... OpenCL almost exclusively on a (i)GPU... large well behaved well aligned data sets are typical of embarrassingly parallel work loads, that should feel very much at home on an iGP, so for this CPU counts for almost nothing.

Of course with this a $100 iGP beating to absolute ridiculity a $1000 CPU, is something that the "powers of marketing" don't want you to be aware, that is why Luxmark has been co-opted for the next season of the "premier league football championship" for morons only lol

In the end what you want, is to discuss SOFTWARE and craved it into the responsibility of a single PE (processing element), in this case a CPU (to too much delight of the power of marketing, i'm sure)... and blindly hope that flies ( or intentional or by deep ignorance).

 

[hcl123]

A crazy idea

I read somewhat that one of main limitations of BD/PD modules was the single decode per module. If I understood this well, the decode switches between cores within a module which means cannot feed both cores in one clock. For a ten clock period, the situation would look like (A denotes first core working, B denotes second core working and _ denotes a core is not being feed)

A_
_B
A_
_B
A_
_B
A_
_B
A_
_B

Now Steamroller has twice decoders, which means each core can be feed in one clock

AB
AB
AB
AB
AB
AB
AB
AB
AB
AB

Each core in Steamroller module is being twice more efficient than in bulldozer/piledriver module, earning twice more instructions. To get the same number of A and B (10 each) one would use two bulldozer/piledriver modules

A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B

I know this is an oversimplification but could this partially explain why 4C/8C Piledriver are being replaced by 2C/4C Steamroller?

wow!... an actual AMD uarch probably related Steamroller post, in a AMD uarch "expert" Steamroller thread ????? ... naa! i think "juanrga" is derailing the thread lol

elas!.. NO decode is not the main problem... it can be, depends on the software(compiler)... the problem with decode its the same as "If" a single core per "decode engine", that is if it were there only 1 integer core would be the same problem, i.e., in x86 the "complex" decode pipe blocks the others upon more complex instructions to decode, that is, upon more than 1 MacroOp( 2 microOPs, execute + memory), the 4 decode pipe acts like if it were only 1... the same thing happens with intel uarchs.(edt)

*IF* (not easy due to the "strong dependency model" of x86, which "a priori" sees every instruction dependent on another)... it was possible that upon decoding "complex" instructions the "complex decode pipe" doesn't block the others, the "same 4 decode" pipes would act like more 2 decode engines(or more) than else...

I think that is what happens with "Steamroller", it has the same 4 decode pipes of BD/PD, only perhaps instructions from one thread don't block instructions from the other thread, that is, Steamroller must have 2 "complex" decode pipes on those 4, that assume "non-dependent" instructions by checking the "contexts", and relax the dependency checking.

Yes... steamroller most probably will have the same 4 decode pipes of BD/PD... only arranged in a different fashion.

The question of "Vertical Multi-Threading" is not the culprit either, actually it is what makes it clearly superior to any intel uarch, that VMT works upon 2 "open contexts", that is, its incredible fast "internally changing the thread contexts" ( otherwise if it were OS dependent it would be slower than a Pentium I (quite slow) lol).. and the operation is inherently "asynchronous" (quite difficult).

VMT work like this.. .contexts can change from 1 cycle to another

AA or BB ... of course A_ or B_ or _ _ can happen... ( but there NEVER is AB or BA, that is SMT and no context changing needed) (edt)... but can happen also in STM (simultaneous multithreading = hyperthreading)... or in single cores... caches misses always leads to "bubbles & stalls".

So it is not VMT the problem, since its not only decode that is VMT... its fetch, branch, dispatch including the "FlexFPU frontend". The decode problem can be fixed by relaxing the "dependency" checking and constrains upon decoding complex operations (2 "independent" complex operations, forcingly upon 2 thread contexts) .. MOAR = brute force, always leads to disappointing results.

VMT is so nice... and since a "module" is an optimized 2 cores sharing... that is, another CPU core "jumped inside" another core to make a module, that in the future i see a "module" jumping inside another module (sharing) to make a 4 core/thread module lol

I also see VMT use in a "Horizontal" way... so Horizontal Multi-Threading using the same "asynchronous open contexts" of the VMT( in an horizontal way) and each Cluster ( integer core) have more than 1 thread context, yet not being SMT(simultaneous multi-threading) but an evolution of the CMT (cluster multi-threading) concept.

[ UPDATE: in actually the scheme of of BD/PD is... A ->B -> A ->B -> ... its "interleaving", its one thread one cycle the other thread the other cycle, being the beauty of VTM that you have more fine grain control on the execution, i.e., it can be A->A->A->A->B ->B -> B -> B ... or any granularity between 1 and 4 instructions...

SteamRoller changes this to A-A ->B-B->A-A-> ... that is the "minimal granularity" passes to be " 2 instructions" in any combination up to 4( can be AAAA or BBBB)... it simplifies it, and probably wastes less power on context switches, and has no adverse effect on performance...

So the advantage of VMT over SMT is exactly the possibility of sharing resources having a fine-grain control, upon cache misses or other events, one thread never clogs the other , contrary to SMT/Hyperthreading that had to have resources augmented since Nehalem, since it was often that with SMT/HT turned off, the performance was greater than with SMT/HT on!

On VMT this is way much better (ok it doesn't approach the performance of 2 separated cores... but NOTHING will...)... if a thread just grabs all resources (and even waiting on instructions and or data can grab resources, that is, doing nothing can grab resources lol) then the VMT control can simply switch to another, it leads to much more efficient utilization of resources ]

Yeah, there are rumours I am going to be banned by posting on-topic, he he.

By the above

A_
_B
A_
_B
...

I did mean your "A ->B -> A ->B -> ..."

Now I need time to decode what do you mean by "A-A ->B-B->A-A-> ..."

There is 3 basic ways of Multithreading

2 threads in the same engine

Interleaving Multi-Threading; requires good control and very fast "context switches"... first it was used by the Cray vector processors i think... it means the pipeline starts with one thread, let say A, and then next clock cycle it changes to thread B. Usually it means the all pipeline is synchronous, the context tracking is only at the beginning, after is pretty much SMT.

This is A->B->A-B->A... but in Cray example its only at fetch, after fetch, pretty much FIFO logic dominates... first in first served.

AMD is different because it separates the pipeline in different "thread control" domains.... so its not exactly A->B->A->B etc...different "domains down the pipeline can have different forms of control.. its asynchronous... and this enters;

Block Multi-Threading; its the possibility of changing the granularity of a 2 thread engine as example. Instead of being 1 instruction from one thread, and next cycle one instruction from the other thread, it can be 2 or 3 or more from one thread, then jumps to the other thread for another block of instructions from the other thread (can be 2 3 4 or 5 ), then jumps back to the first thread again for another "BLOCK" of instructions from this one, and on and on.. understand ?

This permits much finer control, usually permits to change threads on an "event", meaning if a priority is established it can change threads, if one thread becomes a resource hog it can be blocked from grabbing more resources... usually this form of multithreading with "blocks" of instructions is also called "switch on event multi-threading"(is used by SPARC).

Again AMD is different because it uses several different domains of control, each of which can have different "events" associated... permitting so a better control over the behavior of several threads down the same pipeline

Simultaneous Multi-Threading(SMT) aka Hyperthreading; its the simpler and more widely used form of multithreading down a same pipeline, derives from wide issue RISC uarches, it feels better with wider and and fatter full of resources designs, it has "loose" control, pretty much FIFO logic, which is pretty simple... only Intel uses it in a CISC arch (like x86)... which is not the wisest, since its complexity, with usually instructions faster and slower than others, if one one instruction stalls and if first-in than it must be first out... but if it stalls , pretty much all pipeline work stalls (Nehalem and P4 earlier even worst, suffered heavily on this)...

The AA->BB->AA->BB, means the "granularity" of the "block of instructions on AMD scheme is 2 instructions form the same thread, and then jumps to the other for more 2, and on and on. But this is only the "basic" granularity most likely at "fetch", because stated and shown in all diagrams not all pipeline is VTM, and different domains can have different "events" of control, and so change granularity wisely to avoid bubbles ( the A_ or B_ ).

So AMD AFAIK, is the most advanced form of multithreading down a single pipeline, it dominates so well the "art" of very fast "context switch" that it even implements several domains of control down a pipeline... which is called "vertical Multi-threading".

And the beauty of "fast context switches" is that it can be used in a horizontal way, that is to share a "execution core" Integer or FPU or even SIMD... ,as well or better than to share a fetch or a decode engine, meaning the "module" implementation of AMD is to grow in number on threads with time, it was designed with that intention(strong suspicion). It may not be fake that "die shot" (image) that was presented here, to me it shows clearly a 4 thread module.... and if the "fast context switch" on that "open way" that is used in VTM, is used and enlarged for Horizontal( several threads on advanced ways be it "speculative multithreading" (spMT) or "dataflow approaches" ... bot of which are the things that can complement better HTM - Hardware Transactional Memory, and intelligent versioning caches).

*IF* ALL is as good as it seems don't be surprised to see in the future you'll see 8 threads per module, meaning comparing with BD/PD which has 8 threads/cores (2 per module), the new chip (that could even be smaller on smaller on smaller FAB processes) could have 32 "good" threads on a single piece of silicon.... and 5 modules is not to discard, so 40 threads in a single piece of silicon below the the 300mm² LOL... ( a MCM could have 80)

THIS IS REAL **HIGH PERFORMANCE**... no intent to be polemic or pick on intel fanboys... in actual intel designs i can't see one that can compete with this. Of course it needs software "compiled" to take advantage of those so many threads, but i think that is where the HSA compiler toolchain, which is the principal work of the HSA foundation do far, can enter!...

Intel simply can't compete with the actual designs (they need to invent something much better fast), this is even better to make a many core with real CPU cores and "control"( which MIC doesn't have, isn't a CPU), and HUGE FlexFPUs, meaning large vector AVX style crunching much better than Intel PhyX MIC (perhaps that is why they "stole" Gustafson from Intel lol)...

Of course none of this shows in the "popular new football game" of computer aficionados, ( rigged to the bone like if the federation league headquarters would be on Old Trafford Manchester lol), called benchmark review, NEW SOFTWARE is needed, BETTER SOFTWARE is needed... nothing that scares the HPC (**HIGH Performance Computing**) community.... but boy!, the single thread approach of the current x86 client/desktop PC world is so awkwardly stupidly OBSOLETE, that there is no point to pick a decent arguing... oh! well!...

Thanks by this useful reply. I would say that by "A" and "B" I didn't mean threads but cores within a module.

Yes that is CMT (cluster multithreading ) where "one thread = one cluster which is a CPU core"...

But this doesn't apply to SMT(simultaneous multithreading) and so to Intel.. so for the sake of comparativeness when you talk A or B you must talk "threads" not cores.

Imagine "Horinzontal Multithreading"... you have now a cluster = core which is each a "2 ALU exec pipes" + "2 AGU(mostly) exec pipes".

Now divide that in 2 sub-clusters, somehow kind of independent in operations from each other... then you will have " 2 new clusters" for each former one, one "2 ALU" and the other "2 AGU (+some ALU + MOV)".

Now you can have 2 threads in a single former core and IS NOT SMT, each thread sees all resources for itself as if its alone in a core(which is = 2 sub-cluster now) ( is so because its incredibly fast switched, like the vertical VTM for a fetch or branch or decode), its "switched on event= block Multithreading" on clusters , in this case sub-clusters.. .and you can say its CMT (cluster multithreading) all along to.

What you have with each "core" now dived into "2 PE (sub-clusters)" , one part about "memory operations almost exclusively", and other part about "pure Integer ALU exec" is a DAE (decoupled access/execute) architecture...

Its old
http://en.wikipedia.org/wiki/Decoupled_architecture
http://courses.engr.illinois.edu/ece512/papers/smith.1982.isca.pdf
http://personals.ac.upc.edu/jmanel/papers/euromicro98.pdf

And AMD found that if well implemented can have plenty of advantage over a "traditional approach" (up to 113% better in one test approach)...

http://www.xbitlabs.com/news/cpu/display/20120207135832_Engineers_Show_Way_to_Improve_Performance_of_AMD_Fusion_Chips_by_20.html

http://news.ncsu.edu/releases/wmszhougpucpu/

CPU-Assisted GPGPU on Fused CPU-GPU Architectures”

Authors: Yi Yang, Ping Xiang, Huiyang Zhou, North Carolina State University; Mike Mantor, Advanced Micro Devices

Presented: Feb. 27, 18th International Symposium on High Performance Computer Architecture, New Orleans

Abstract: This paper presents a novel approach to utilize the CPU resource to facilitate the execution of GPGPU programs on fused CPU-GPU architectures. In our model of fused architectures, the GPU and the CPU are integrated on the same die and share the on-chip L3 cache and off-chip memory, similar to the latest Intel Sandy Bridge and AMD accelerated processing unit (APU) platforms. In our proposed CPU-assisted GPGPU, after the CPU launches a GPU program, it executes a pre-execution program, which is generated automatically from the GPU kernel using our proposed compiler algorithms and contains memory access instructions of the GPU kernel for multiple threadblocks. *The CPU pre-execution program runs ahead of GPU threads because (1) the CPU pre-execution thread only contains memory fetch instructions from GPU kernels and not floating-point computations, and (2) the CPU runs at higher frequencies and exploits higher degrees of instruction-level parallelism than GPU scalar cores. We also leverage the prefetcher at the L2-cache on the CPU side to increase the memory traffic from CPU. As a result, the memory accesses of GPU threads hit in the L3 cache and their latency can be drastically reduced. Since our pre-execution is directly controlled by user-level applications, it enjoys both high accuracy and flexibility. Our experiments on a set of benchmarks show that our proposed preexecution improves the performance by up to 113% and 21.4% on average.

... it can also be applied for typical CPU workloads as i described... in that "Decoupled Architectures"... and so AMD when having "4 thread per module" implementation" or "2 thread per core", i'm NOT talking about "weak threads", but "each thread most probably more performant than in an actual BD/PD core" and so "more performant than on intel CPU cores also"... and this on the same basic config of 2 ALU + 2 AGU of today.

Yes... many will say i'm dreaming, its not possible... but i assure you its possible, the traditional approach is just that, TRADITIONAL & OBSOLETE... its time for something new and better.

So "independent" of the performance on any particular benchmark, which is typical and dependent on the SOFTWARE of that benchmark alone, not really generalizable... when i say AMD has with its "decoupled BD uarch" far better *potential* uarch than anything Intel so far... i'm not saying by fanboyism, and hope the long explanations helps as arguments (lol)

... what happens most of times is ppl parrot marketing slogans, that have little representativity of reality... but i think its a sign of times, not that one company is better than another... real science, innovation and some risk taking is gone... its time for marketing... its time for the "ism" aficionados to beat each other to dead over ridiculous 10, 20 or 30% differences, and its driven by marketing..

 

[rmpumper]

Can you please stop quoting mile long posts?

 

[griptwister]

So, Kaveri is looking to be delayed till Q1 2014 due to late manufacturing of the hardware. I'm quite bummed. SteamRoller better be good if they're going to make us wait this long for it. (especially "if" all the speculation is true)

http://www.digitimes.com/news/a20130716PD202.html

 

[8350rocks]

Spoiler

((EDIT: Spent 5 minutes editing the post, and lost everything. I hate the new forums more and more the more I'm here...))

You still haven't explained how it is that the 8350 with 8 cores exceeds the 3470/3570 performance in crysis 3, even though Intel has "dramatically superior" IPC.

Clockspeed.

Single Core Performance = clockspeed * IPC. Improving one is as good as improving the other. If one architecture has half the clock but double the IPC, they would perform the same.

Hence why the 3470 beats the 8150, but not the 8350. 15% IPC gains and 400 MHz worth of clock can easily account for the extra 6 FPS the 8350 gains over the 8150. Also explains why the 3470 beats the 8150, but not the 8350. Based on your "more cores" theory, both the 8150 and 8350 should be beating the 3470.

The simple solution would be to normalize clocks for the purposes of looking at scaling. Normalize all CPU clocks to, say, 3.5GHz, so IPC and Cores should be the only two things affecting the benchmark results. IPC favors Intel, Cores favor AMD. If you see all the Intel chips grouped at the top, then my theory holds.

Any takers?

Spoiler

Well, the issue I see with the logic is simple:

If IPC were the only culprit and clockspeed a direct correlation, then why does a 6 core SB-E with lower IPC than IB hold pace and exceed the higher IPC and higher clocked IB architecture?

I am not saying IPC plays no role, it clearly will in some way for anything...however, the point I am making is, it's far from the only variable at work here. More cores have a correlation too, you're just not acknowledging that.

EDIT: Let's stop comparing separate manufacturer architectures for a moment...because it's like comparing apples and oranges and saying they both make juice, but one takes more fruit to make the same amount of juice.

The comparison is naturally flawed because we have no baseline to bridge between the 2 separate uarch's.

So, in Intel architecture, clockspeed makes a correlation, but Intel does not exceed max CPU burden comfortably until you get to a 6 core CPU. Even 4 core CPUs with HTT do not break below 80+% usage average per core. The only Intel CPUs that do are 6 core w/HTT, and even then, they typically have 2-3 HTT modules running and average 50% core usage across the board (counting physical core resources not HTT modules)

In AMD architecture, The FX 6300 is about the point where you start to see CPU utilization fall below a 90% aggregate average for core usage under load. This correlates with the Intel data because the i7 Quads with HTT always have 4 cores loaded highly and 2-3 HTT modules running near their max capability. The FX 8350 and possibly 8320 (hard to say definitively without data) are likely the only 2 AMD CPUs that do not function at 80+% load on all cores running this software.

Based on this information, I can definitively say, you need 6 cores or more from either manufacturer to get below a 90-95% average resource consumption per core under load. To be at a point where the CPU actually has headroom (<80% core resources consumed average) then you need to look at an 8 core AMD or a 6 core Intel.

Clockspeed effects frame rates in an expected non-linear scaling manner, though the biggest FPS jump seen comes when going from 2 to 4 cores (24 FPS) and then from 4 to 6 cores (20 FPS) inside Intel architecture. In AMD, the jump from 4 to 6 to 8 cores scales less considerably, but are still significant jumps in FPS over something that could be achieved via clockspeed.

This tells me 2 things, the engine is sensitive to IPC/clockspeed, but more sensitive to having enough resources to run all the threads concurrently as those jumps were always more significant then jumps in clockspeed (even taking OC'ed CPU info from other forums into consideration, a 20% jump in clockspeed is less significant than the jump from 2 to 4 or 4 to 6 cores for Intel).

I really do agree with you here. It is probably the way that the CPU's are built in correlation to their IPC. It's either:

A. Lower IPC will improve performance (which, kind of is, you know, out of the bulletin)

or B. The SB-E chips physical design and possible other attributes that are added can cause a usual increase in performance. Simply, it was built more towards efficiency, as that's what anyone would do upon improving something.

That makes no sense for an older architecture with lower IPC and less clockspeed to be better at something that doesn't take advantage of it's only advantage...2 more cores! Core counts matter when you look at apples to apples, same architectures...you cannot deny that AMD and Intel architectures both see FPS increases adding cores up to 8 physical cores.

Then we come to our answer, which is your statement:

The comparison is naturally flawed because we have no baseline to bridge between the 2 separate uarch's.

In which right here, you are right, and I am telling you they you're completely wrong.

On a simple manner, creating a baseline is very hard. It requires many tests, tries and failures before becoming your baseline. Of course this is with something very complex with our world of CPU technology: "IPC, CLOCKSPEED, CORE AMOUNT, ARCHITECTURE..." and so on.
---------------------------------------------------------------------------------------------------------------
There is a easy (on paper) way to solve your statement.

Let's take a break and have a mind teaser.

Student A, B, and C are taking a 3 times test:

Student A scored 90 on her first test, but only 85 on her next test, however 100 on the last. Thus her average would be: 92 (91.6 repeated rounded ; all results are rounded to the nearest unit).

Student B took the test and got 70, 75, and 60 on his. Avg: 68

Student C: 40, 50, 35 on his. Avg: 42

Obviously, the average of all three students averages will be: 67

Thus we have are median score on a rating of 0-100.

Percentile Explanation:

So then, if someone does better, you need to do this. The percent of increase or decrease is dependent on the number to the top and bottom. So 67 is 33 away from 100, out top, so 33 = +100% for the top, and for the bottom, 67 = -100%, which will be out percentile. For example, a few years ago, I was in the 90th percentile for height growth, now I am in the 70th, meaning if that average number didn't change, I'm growing less than before. IRL most percentiles are use with 50 as the median, but for this it'll be different, since it's easier this way.

Student A, getting an average of 92, will be positive, but how much?

So with 33 being our positive of 100%, and 25 being the difference from the median, we'll do some math.

Simply, you can divide 33 from 25, even though you can cross multiply and then do a multi-step equation.

33 / 25 = 0.7575 repeated. Lets round to the thousandth, so 75.8%

This means that Student A, is + 75.8%0 (above average = +, and below = -).
Student B: + 3.0%
Student C (will use 67 since he's negative): - 37.3%
--------------------------------------------------------------------------------------------------
There you have it. Simply, just use the stock CPU settings, plug and play basically, and run their test scores (from trusted sources), to see their average median. So then, if any CPU does better or worse, you can use this theory on percentile to see if they are doing better or worse. And obviously, if one does better than the other, you can tell by if its a better number. If it's negative, the lower percent, the better. If positive, the higher the better.

Look, you're getting way out into left field...if this was Wrigley Field, you might already be lost in the Ivy on the wall out there....

I put the conclusions we could logically arrive at based on the data...and you're trying to extrapolate results from it that are tangential at best, and irrelevant at worst.

The question at this point, is not AMD vs Intel, I think that's where you missed the boat...

The question is, do more cores make a difference in these highly threaded games?

The answer is, in anything but a RTS title...overwhelmingly YES!!! They do make a difference.

 

[juanrga]

At task accelerated with OpenCL.
Why compare APU+HSA with CPU which doesn't even have iGPU?

I did mean HSA enabled applications.

Comparing a HSA enabled APU to one of the faster Intel CPUs offers an idea of the potential of the technology. It is not very different from those reviews that compare OpenCL applications in 3770k/4770k against a FX-8350 (which doesn't even have a iGPU).

I know you did. But it's only part of puzzle made by AMD. HSA is a great technology, but only for some computation. We still need performance of single thread.

Steamroller will increase CPU performance up to Ivy Bridge levels, which is more than enough for the average user. HSA is an extra boost for lots of applications: browsers, games, video editing, image manipulation, spreadsheets...

What you missed is that there isn't HSA ( Heterogeneous System Architecture) without an heterogeneous PE (processing element) present... otherwise it doesn't make sense talk about HSA.

OpenCL IS NOT HSA.

I think you are confounding me with szatkus. He is who said that HSA = OpenCL.

Both 8350rocks and me said to him that HSA is something much more important. In this same thread, I recommended to szatkus the tomshardware article explaining the differences between HSA and OpenCL.

A crazy idea

I read somewhat that one of main limitations of BD/PD modules was the single decode per module. If I understood this well, the decode switches between cores within a module which means cannot feed both cores in one clock. For a ten clock period, the situation would look like (A denotes first core working, B denotes second core working and _ denotes a core is not being feed)

A_
_B
A_
_B
A_
_B
A_
_B
A_
_B

Now Steamroller has twice decoders, which means each core can be feed in one clock

AB
AB
AB
AB
AB
AB
AB
AB
AB
AB

Each core in Steamroller module is being twice more efficient than in bulldozer/piledriver module, earning twice more instructions. To get the same number of A and B (10 each) one would use two bulldozer/piledriver modules

A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B

I know this is an oversimplification but could this partially explain why 4C/8C Piledriver are being replaced by 2C/4C Steamroller?

<snip>

Thanks by this useful reply. I would say that by "A" and "B" I didn't mean threads but cores within a module.

Yes that is CMT (cluster multithreading ) where "one thread = one cluster which is a CPU core"...

But this doesn't apply to SMT(simultaneous multithreading) and so to Intel.. so for the sake of comparativeness when you talk A or B you must talk "threads" not cores.

But I was not comparing with Intel. I was comparing BD/PD modules to Steamroller modules.

Meanwhile, I found an article that discuss the effect of doubling the decode within a module, and obtains the same conclusion I got above: twice decodes working in parallel offer a theoretical limit of doubling performance. Of course, the average improvement in performance will be far from doubling "since it's rare that a 4-issue front end sees anywhere near full utilization". However, this was one of the main bottlenecks of the BD/PD arch and I am happy that was being eliminated.

 

[Cazalan]

Meanwhile, I found an article that discuss the effect of doubling the decode within a module, and obtains the same conclusion I got above: twice decodes working in parallel offer a theoretical limit of doubling performance. Of course, the average improvement in performance will be far from doubling "since it's rare that a 4-issue front end sees anywhere near full utilization". However, this was one of the main bottlenecks of the BD/PD arch and I am happy that was being eliminated.

SR will likely see the largest variance of % performance increase in the history of AMD architecture evolutions.

I would expect benchmarks where Bulldozer/Piledriver scaled very well like Media encoding, compression apps, rendering to not see much improvement. In these apps the decoder has all the micro-ops already in the cache, and you don't see the backend (execution) being starved for work. There will be some minor increases due to cache changes and probable clock speed increase. You may see only 5% here.

In productivity apps, games(hopefully) and general multitasking you'll see a much bigger improvement. These are scenarios where the instruction decoder couldn't keep up with the more varying instruction workload, and the backend is starved. These apps are where you'll see the 25-30% improvements.

In general SR should act more like a true 4C/4T processor, than a 2M/4T processor.

In retrospect I still hate that they went to this module design. It limits your overclockability and TDP scalability by having the cores tightly coupled. Like the cache and FPU have to run at the higher of the 2 clock speeds, even when the B core is down clocked. They could have scaled up Jaguar cores for higher IPC and clock speed.

 

[Cazalan]

One more hour till the AMD earnings call. AMD is ticking up so a majority must think something positive will come out of it.

http://biz.yahoo.com/cc/3/139173.html

 

[cowboy44mag]

Meanwhile, I found an article that discuss the effect of doubling the decode within a module, and obtains the same conclusion I got above: twice decodes working in parallel offer a theoretical limit of doubling performance. Of course, the average improvement in performance will be far from doubling "since it's rare that a 4-issue front end sees anywhere near full utilization". However, this was one of the main bottlenecks of the BD/PD arch and I am happy that was being eliminated.

SR will likely see the largest variance of % performance increase in the history of AMD architecture evolutions.

I would expect benchmarks where Bulldozer/Piledriver scaled very well like Media encoding, compression apps, rendering to not see much improvement. In these apps the decoder has all the micro-ops already in the cache, and you don't see the backend (execution) being starved for work. There will be some minor increases due to cache changes and probable clock speed increase. You may see only 5% here.

In productivity apps, games(hopefully) and general multitasking you'll see a much bigger improvement. These are scenarios where the instruction decoder couldn't keep up with the more varying instruction workload, and the backend is starved. These apps are where you'll see the 25-30% improvements.

In general SR should act more like a true 4C/4T processor, than a 2M/4T processor.

In retrospect I still hate that they went to this module design. It limits your overclockability and TDP scalability by having the cores tightly coupled. Like the cache and FPU have to run at the higher of the 2 clock speeds, even when the B core is down clocked. They could have scaled up Jaguar cores for higher IPC and clock speed.

+1 I know that all the speculation is Kaveri APUs will feature 4C processors, but I wonder if that will carry over to Steamroller FX? Will Steamroller FX be 4C or will they still offer 8C processors? With all the improvements of Steamroller over Piledriver an 8C Steamroller FX processor should be amazing, possibly even a "game changer".

I know that there are a lot of Intel fans that are still saying a lot of people over-hyped BD (and therefore Steamroller is being over-hyped as well), but really I can excuse AMD for rushing BD (I think eveyone knows that PD is what BD should have been), but you guys also have to remember that Intel just did the same thing with Haswell. For Intel, that is unacceptable. They have a huge R&D budget, and for a fourth generation Intel processor the "gains" made are a joke.

That leads to Intel's biggest ace in the hole. Everyone talks about their R&D department and the huge budget they have and the talent they have, but their most important departments are their PR department and their Marketing Department. I wish that I could get a couple guys or gals from their PR & Marketing Department to come to my ranch for a few days and do their magic. I have over 60 horses at my ranch so what manure I can't spread I give away to local farmers and pay to have hauled off. If I could get Intel's Market Department magic on my side I could be selling 10lb bags of it for $100 If ANYONE can make a worthless pile of ... manure seem like the greatest thing man has ever discovered- its Intel's Marketing Department:lol:

 

[Cazalan]

+1 I know that all the speculation is Kaveri APUs will feature 4C processors, but I wonder if that will carry over to Steamroller FX? Will Steamroller FX be 4C or will they still offer 8C processors? With all the improvements of Steamroller over Piledriver an 8C Steamroller FX processor should be amazing, possibly even a "game changer".

The current roadmaps don't have any 8+ core SR in sight for 2013/2014. Perhaps in 2015 they will make a comeback or they could just skip to EC.

We'll probably see an 8 core Jaguar first for servers.

 

[GOM3RPLY3R]

Spoiler

Spoiler

((EDIT: Spent 5 minutes editing the post, and lost everything. I hate the new forums more and more the more I'm here...))

You still haven't explained how it is that the 8350 with 8 cores exceeds the 3470/3570 performance in crysis 3, even though Intel has "dramatically superior" IPC.

Clockspeed.

Single Core Performance = clockspeed * IPC. Improving one is as good as improving the other. If one architecture has half the clock but double the IPC, they would perform the same.

Hence why the 3470 beats the 8150, but not the 8350. 15% IPC gains and 400 MHz worth of clock can easily account for the extra 6 FPS the 8350 gains over the 8150. Also explains why the 3470 beats the 8150, but not the 8350. Based on your "more cores" theory, both the 8150 and 8350 should be beating the 3470.

The simple solution would be to normalize clocks for the purposes of looking at scaling. Normalize all CPU clocks to, say, 3.5GHz, so IPC and Cores should be the only two things affecting the benchmark results. IPC favors Intel, Cores favor AMD. If you see all the Intel chips grouped at the top, then my theory holds.

Any takers?

Spoiler

Well, the issue I see with the logic is simple:

If IPC were the only culprit and clockspeed a direct correlation, then why does a 6 core SB-E with lower IPC than IB hold pace and exceed the higher IPC and higher clocked IB architecture?

I am not saying IPC plays no role, it clearly will in some way for anything...however, the point I am making is, it's far from the only variable at work here. More cores have a correlation too, you're just not acknowledging that.

EDIT: Let's stop comparing separate manufacturer architectures for a moment...because it's like comparing apples and oranges and saying they both make juice, but one takes more fruit to make the same amount of juice.

The comparison is naturally flawed because we have no baseline to bridge between the 2 separate uarch's.

So, in Intel architecture, clockspeed makes a correlation, but Intel does not exceed max CPU burden comfortably until you get to a 6 core CPU. Even 4 core CPUs with HTT do not break below 80+% usage average per core. The only Intel CPUs that do are 6 core w/HTT, and even then, they typically have 2-3 HTT modules running and average 50% core usage across the board (counting physical core resources not HTT modules)

In AMD architecture, The FX 6300 is about the point where you start to see CPU utilization fall below a 90% aggregate average for core usage under load. This correlates with the Intel data because the i7 Quads with HTT always have 4 cores loaded highly and 2-3 HTT modules running near their max capability. The FX 8350 and possibly 8320 (hard to say definitively without data) are likely the only 2 AMD CPUs that do not function at 80+% load on all cores running this software.

Based on this information, I can definitively say, you need 6 cores or more from either manufacturer to get below a 90-95% average resource consumption per core under load. To be at a point where the CPU actually has headroom (<80% core resources consumed average) then you need to look at an 8 core AMD or a 6 core Intel.

Clockspeed effects frame rates in an expected non-linear scaling manner, though the biggest FPS jump seen comes when going from 2 to 4 cores (24 FPS) and then from 4 to 6 cores (20 FPS) inside Intel architecture. In AMD, the jump from 4 to 6 to 8 cores scales less considerably, but are still significant jumps in FPS over something that could be achieved via clockspeed.

This tells me 2 things, the engine is sensitive to IPC/clockspeed, but more sensitive to having enough resources to run all the threads concurrently as those jumps were always more significant then jumps in clockspeed (even taking OC'ed CPU info from other forums into consideration, a 20% jump in clockspeed is less significant than the jump from 2 to 4 or 4 to 6 cores for Intel).

I really do agree with you here. It is probably the way that the CPU's are built in correlation to their IPC. It's either:

A. Lower IPC will improve performance (which, kind of is, you know, out of the bulletin)

or B. The SB-E chips physical design and possible other attributes that are added can cause a usual increase in performance. Simply, it was built more towards efficiency, as that's what anyone would do upon improving something.

That makes no sense for an older architecture with lower IPC and less clockspeed to be better at something that doesn't take advantage of it's only advantage...2 more cores! Core counts matter when you look at apples to apples, same architectures...you cannot deny that AMD and Intel architectures both see FPS increases adding cores up to 8 physical cores.

Then we come to our answer, which is your statement:

The comparison is naturally flawed because we have no baseline to bridge between the 2 separate uarch's.

In which right here, you are right, and I am telling you they you're completely wrong.

On a simple manner, creating a baseline is very hard. It requires many tests, tries and failures before becoming your baseline. Of course this is with something very complex with our world of CPU technology: "IPC, CLOCKSPEED, CORE AMOUNT, ARCHITECTURE..." and so on.
---------------------------------------------------------------------------------------------------------------
There is a easy (on paper) way to solve your statement.

Let's take a break and have a mind teaser.

Student A, B, and C are taking a 3 times test:

Student A scored 90 on her first test, but only 85 on her next test, however 100 on the last. Thus her average would be: 92 (91.6 repeated rounded ; all results are rounded to the nearest unit).

Student B took the test and got 70, 75, and 60 on his. Avg: 68

Student C: 40, 50, 35 on his. Avg: 42

Obviously, the average of all three students averages will be: 67

Thus we have are median score on a rating of 0-100.

Percentile Explanation:

So then, if someone does better, you need to do this. The percent of increase or decrease is dependent on the number to the top and bottom. So 67 is 33 away from 100, out top, so 33 = +100% for the top, and for the bottom, 67 = -100%, which will be out percentile. For example, a few years ago, I was in the 90th percentile for height growth, now I am in the 70th, meaning if that average number didn't change, I'm growing less than before. IRL most percentiles are use with 50 as the median, but for this it'll be different, since it's easier this way.

Student A, getting an average of 92, will be positive, but how much?

So with 33 being our positive of 100%, and 25 being the difference from the median, we'll do some math.

Simply, you can divide 33 from 25, even though you can cross multiply and then do a multi-step equation.

33 / 25 = 0.7575 repeated. Lets round to the thousandth, so 75.8%

This means that Student A, is + 75.8%0 (above average = +, and below = -).
Student B: + 3.0%
Student C (will use 67 since he's negative): - 37.3%
--------------------------------------------------------------------------------------------------
There you have it. Simply, just use the stock CPU settings, plug and play basically, and run their test scores (from trusted sources), to see their average median. So then, if any CPU does better or worse, you can use this theory on percentile to see if they are doing better or worse. And obviously, if one does better than the other, you can tell by if its a better number. If it's negative, the lower percent, the better. If positive, the higher the better.

Look, you're getting way out into left field...if this was Wrigley Field, you might already be lost in the Ivy on the wall out there....

I put the conclusions we could logically arrive at based on the data...and you're trying to extrapolate results from it that are tangential at best, and irrelevant at worst.

The question at this point, is not AMD vs Intel, I think that's where you missed the boat...

The question is, do more cores make a difference in these highly threaded games?

The answer is, in anything but a RTS title...overwhelmingly YES!!! They do make a difference.

I feel that you are misunderstanding something here. This isn't about AMD vs Intel, this is making an easily solution to see both that if IPC vs Cores will work better. Obviously, there is not one CPU out there where if you add cores, it wont improve.

The point from this is to make a very averaged and overall performance statement based on overall performance results. This is to see, "Okay, the X CPU compared to Y is better, and when you overclock it A, it has a better performance percent index (ppi, is what I call this system here), than CPU B."

Basically, it's giving the interpretation of how good it would do if someone did every kind of thing from gaming to video editing, coding, and so on. Now yes, no one does EVERYTHING, however, giving these CPUs a general score, will help see if it improved overall from a Core / IPC increase. They can also be sub-divided into what category (gaming, video rendering, multi-threaded apps, etc.), and be judged better then.

It's really to benefit the Computer Community as a whole, giving them straight results that show how the performance of our machines is coming along, and if someone wants to do something specific, say play games, they can say, "Okay, this CPU X has a better performance increase than CPU Y." So on and so forth.

Don't be so quick to judge, take time to think it out first.

 

[cowboy44mag]

+1 I know that all the speculation is Kaveri APUs will feature 4C processors, but I wonder if that will carry over to Steamroller FX? Will Steamroller FX be 4C or will they still offer 8C processors? With all the improvements of Steamroller over Piledriver an 8C Steamroller FX processor should be amazing, possibly even a "game changer".

The current roadmaps don't have any 8+ core SR in sight for 2013/2014. Perhaps in 2015 they will make a comeback or they could just skip to EC.

We'll probably see an 8 core Jaguar first for servers.

That's a little disappointing. I know that if Steamroller is as good as I think it will be a 4C Steamroller FX will be a very good processor (equal to but greater than an 8C Piledriver), but an 8C Steamroller FX would be awesome.

 

[Cazalan]

Finally finished listening to the earnings report.

Those Kaveri delay rumors are pretty much guaranteed true now. There was absolutely ZERO mention of Kaveri or Steamroller.

The entire call basically revolved around Jaguar and the console wins. Which is good for AMD's bottom line but for those waiting for SR the wait will be even longer now.

To get their operating costs down they must be cutting into R&D and that's delaying the higher end cores.

 

[hcl123]

So, Kaveri is looking to be delayed till Q1 2014 due to late manufacturing of the hardware. I'm quite bummed. SteamRoller better be good if they're going to make us wait this long for it. (especially "if" all the speculation is true)

http://www.digitimes.com/news/a20130716PD202.html

I think there will be 2 kaveris, one for "mobile" ( down to ultra-thins ).. and one for mainstream/desktop.

The first will be low power 28nm "bulk", and is incredibly "late" compared with 28nm TSMC that debuted almost 2 years ago... the other one will be 28nm FD-SOI (that comparatively as Glofo announced is like half node shrink compared with 28nm bulk).

So i think is this last one, the one that is supposedly late... but after all Glofo (officially) announced that 28nm FD-SOI would only be ready for full production ramp-up in 2014... and though porting a bulk design to FD-SOI is quite straightforward ( its all planar both processes and a share the same BEOL (edt) and some MEOL), i think also AMD will take advantage of the shrink to beef up something, specially if not exclusively the FlexFPU.

 

[hcl123]

Spoiler

At task accelerated with OpenCL.
Why compare APU+HSA with CPU which doesn't even have iGPU?

I did mean HSA enabled applications.

Comparing a HSA enabled APU to one of the faster Intel CPUs offers an idea of the potential of the technology. It is not very different from those reviews that compare OpenCL applications in 3770k/4770k against a FX-8350 (which doesn't even have a iGPU).

I know you did. But it's only part of puzzle made by AMD. HSA is a great technology, but only for some computation. We still need performance of single thread.

Steamroller will increase CPU performance up to Ivy Bridge levels, which is more than enough for the average user. HSA is an extra boost for lots of applications: browsers, games, video editing, image manipulation, spreadsheets...

What you missed is that there isn't HSA ( Heterogeneous System Architecture) without an heterogeneous PE (processing element) present... otherwise it doesn't make sense talk about HSA.

OpenCL IS NOT HSA.

I think you are confounding me with szatkus. He is who said that HSA = OpenCL.

Both 8350rocks and me said to him that HSA is something much more important. In this same thread, I recommended to szatkus the tomshardware article explaining the differences between HSA and OpenCL.

A crazy idea

I read somewhat that one of main limitations of BD/PD modules was the single decode per module. If I understood this well, the decode switches between cores within a module which means cannot feed both cores in one clock. For a ten clock period, the situation would look like (A denotes first core working, B denotes second core working and _ denotes a core is not being feed)

A_
_B
A_
_B
A_
_B
A_
_B
A_
_B

Now Steamroller has twice decoders, which means each core can be feed in one clock

AB
AB
AB
AB
AB
AB
AB
AB
AB
AB

Each core in Steamroller module is being twice more efficient than in bulldozer/piledriver module, earning twice more instructions. To get the same number of A and B (10 each) one would use two bulldozer/piledriver modules

A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B
A_ A_
_B _B

I know this is an oversimplification but could this partially explain why 4C/8C Piledriver are being replaced by 2C/4C Steamroller?

<snip>

Thanks by this useful reply. I would say that by "A" and "B" I didn't mean threads but cores within a module.

Yes that is CMT (cluster multithreading ) where "one thread = one cluster which is a CPU core"...

But this doesn't apply to SMT(simultaneous multithreading) and so to Intel.. so for the sake of comparativeness when you talk A or B you must talk "threads" not cores.

But I was not comparing with Intel. I was comparing BD/PD modules to Steamroller modules.

Meanwhile, I found an article that discuss the effect of doubling the decode within a module, and obtains the same conclusion I got above: twice decodes working in parallel offer a theoretical limit of doubling performance. Of course, the average improvement in performance will be far from doubling "since it's rare that a 4-issue front end sees anywhere near full utilization". However, this was one of the main bottlenecks of the BD/PD arch and I am happy that was being eliminated.

Its the same thing comparing with BD/PD. One of the main mistakes of AMD was claiming 2 cores per module when the performance of 2 threads in a module wasn't anywhere comparable to 2 cores. I think its possible that with "vertical mulrithreading", as i described, theoretically achieve 90% the performance of 2 cores - ( real world perhaps a little above 80%)...

In any case is better talk about threads not cores.

Twice the decode doesn't mean twice the performance in *ANY* circumstance. Not even 2 full cores means twice the performance, there is the cache and interconnect contraints... and synchronization for multi threading software to account for.

Only "vectorization" and full "embarrassingly parallel" data sets on a embarrassingly parallel processing element ( like a GPGPU) can break the Amdahl's Law, its called the Gustafson Law. This last means "data" must be very well aligned and very close to the ALU pipes, on huge "register files" like GP/GPUs, that in Tahiti as example, has 12MB of "memory"... only the point, of that, 8 MB are register files, and other 2 MB are scratchpad memory(register extension)... only ~2 MB are "normal" caches...

This topology is kind of impossible for CPUs... in those its better much smaller RFs, and so much faster RFs, because the data is inherently sequential.

To me the "decode" been the "uber problem" is a marketing slogan (any CPU, or GPU for that matter, is already full of tradeoffs).... simply x86 as not much more than this, its "plateaud"....CPU work is inherently very repetitive on small loops of instructions with relative small data sets, so the best way to overcame decode constraints is wit a "decoded cache" AFTER the decode engine, and if "tracing" the merrier... which Intel solved by having a " straight decoded L0"(after decode) since the SandyBridge.

Yet was not because of that performance doubled, it was like more 10 to 15% to 20% (depends on SOFTWARE)...

Performance can only double OR MUCH MORE if you break the "strong dependency model" of x86... one way and easy to achieve that is "full vectorizing an parallelizing" the workload (another more difficult is SpMT (speculative multithreading) or "dataflow approaches" with HTM (hardware transactional memory)), this means SOFTWARE must be designed for the effect (which is only mildly on benchmarks at description, with no representativity with the software ppl use).

So i think AMD can achieve the same effect of a "decoded cache" with buffers... Jaguar already has them for the "fetch" section, SR can have additional (loop caching) ones before dispatch and after decode.

This mitigates the sharing of those " vertical domains", and i think is specially this AMD is after, 30% more ops is if account 2 threads on the same "module", count only 1 thread per module and is half of that, they are after "greater parallelism"... but who cares about uper duper stupid obsolete single-thread performance, right ?? ... only an idiot (marketing contents creating mases of them)...

... continue with that single-thread approach and is NO POINT AT ALL making CPU chips with more than 4 cores, its not rigged that a $1000 "exterme" CPU can lose for the 4 cores $300 brethren (like since SNB compared with SNB-E), the benchmark code has only 4 threads or less (like most PC world software), so running it on a 6 cores (and more threads) is no benefice at all... and is the higher clock/turbo that mandates then

I hope this "illustrates" the stupidity well.

 

[hcl123]

In retrospect I still hate that they went to this module design. It limits your overclockability and TDP scalability by having the cores tightly coupled. Like the cache and FPU have to run at the higher of the 2 clock speeds, even when the B core is down clocked. They could have scaled up Jaguar cores for higher IPC and clock speed.

The contrary, the cluster approach, by permitting to divide the workload in "separated" type of instructions and data, is the "feature" (edt) that more helps "clock cycle" (since long, academia simulations shown this)... on AMD module only the FP code "type" is off the CPU code paths.

But its already clever, prone to achieve higher clocks AS DEMONSTRATED... and prone to future enhancements... and no its NOT BD/PD that is P4, matter of fact BD has less pipeline stages than SB/HW, 15 compared to 17 for SB/Hasfail. Only they toke the possibility of separated code paths to streamline the CPU cores further (they went a little too far i think).

 

[noob2222]

Finally finished listening to the earnings report.

Those Kaveri delay rumors are pretty much guaranteed true now. There was absolutely ZERO mention of Kaveri or Steamroller.

The entire call basically revolved around Jaguar and the console wins. Which is good for AMD's bottom line but for those waiting for SR the wait will be even longer now.

To get their operating costs down they must be cutting into R&D and that's delaying the higher end cores.

I think the issue is slo glo. seems they still haven't got good yields on the 28nm and amd is paying per wafer not per working chip. AMD is at their mercy right now as far as 28nm soi timing.

seems samsung may be the way amd needs to head ~2015 and get some low power 14nm parts. If GF is still fighting 28nm, I don't see them getting 14 till 2016 or later.

http://www.macrumors.com/2013/07/14/apple-reportedly-signs-deal-with-samsung-for-14-nm-a9-chips-starting-in-2015/

 

[juanrga]

SR will likely see the largest variance of % performance increase in the history of AMD architecture evolutions.

I would expect benchmarks where Bulldozer/Piledriver scaled very well like Media encoding, compression apps, rendering to not see much improvement. In these apps the decoder has all the micro-ops already in the cache, and you don't see the backend (execution) being starved for work. There will be some minor increases due to cache changes and probable clock speed increase. You may see only 5% here.

In productivity apps, games(hopefully) and general multitasking you'll see a much bigger improvement. These are scenarios where the instruction decoder couldn't keep up with the more varying instruction workload, and the backend is starved. These apps are where you'll see the 25-30% improvements.

In general SR should act more like a true 4C/4T processor, than a 2M/4T processor.

In retrospect I still hate that they went to this module design. It limits your overclockability and TDP scalability by having the cores tightly coupled. Like the cache and FPU have to run at the higher of the 2 clock speeds, even when the B core is down clocked. They could have scaled up Jaguar cores for higher IPC and clock speed.

And media encoding, compression apps, rendering... would benefit a lot of from HSA.

+1 I know that all the speculation is Kaveri APUs will feature 4C processors, but I wonder if that will carry over to Steamroller FX? Will Steamroller FX be 4C or will they still offer 8C processors? With all the improvements of Steamroller over Piledriver an 8C Steamroller FX processor should be amazing, possibly even a "game changer".

I know that there are a lot of Intel fans that are still saying a lot of people over-hyped BD (and therefore Steamroller is being over-hyped as well), but really I can excuse AMD for rushing BD (I think eveyone knows that PD is what BD should have been), but you guys also have to remember that Intel just did the same thing with Haswell. For Intel, that is unacceptable. They have a huge R&D budget, and for a fourth generation Intel processor the "gains" made are a joke.

That leads to Intel's biggest ace in the hole. Everyone talks about their R&D department and the huge budget they have and the talent they have, but their most important departments are their PR department and their Marketing Department. I wish that I could get a couple guys or gals from their PR & Marketing Department to come to my ranch for a few days and do their magic. I have over 60 horses at my ranch so what manure I can't spread I give away to local farmers and pay to have hauled off. If I could get Intel's Market Department magic on my side I could be selling 10lb bags of it for $100 If ANYONE can make a worthless pile of ... manure seem like the greatest thing man has ever discovered- its Intel's Marketing Department:lol:

Server roadmap shows that AMD is either replacing 4/8 piledriver cores series by 4 steamroller cores or eliminating 4/6/8 piledriver cores series and releasing the new Warsaw CPUs with only 12/16 piledriver cores. I suspect that Warsaw will be replaced by a future 6 steamroller cores CPU/APU.

I doubt that AMD will be releasing a FX 8 steamroller cores series. Note that kaveri 4 cores single-thread performance would be as an i5-3350P, whereas multi-thread performance would be like a FX-6300, more or less.

Moreover, kaveri comes with HSA support: about 500% increase in performance in parallel workloads. A hypothetical FX with 16 steamroller cores wouldn't be so fast in those workloads.

About AMD/Intel. Both showed their results for Q2 2013. AMD got better results than analysts waited. Intel got poor results than analysts waited. AMD stock ^^^ as AMD gains confidence, Intel stock vvv as Intel loses confidence.

Moreover, Intel marketing dept. is having hard times. Recently they launched a news offensive about how Intel next mobile chip outperformed the fastest ARM processor... but experts showed that the Antutu benchmark used had been cheated. A corrected version of the Antutu benchmarks showed, a pair of days ago, that Intel mobile chips are very far from the performance of fastest ARM processors.

Does not this resemble what Intel did with Sysmark and AMD?

 

[Cazalan]

About AMD/Intel. Both showed their results for Q2 2013. AMD got better results than analysts waited. Intel got poor results than analysts waited. AMD stock ^^^ as AMD gains confidence, Intel stock vvv as Intel loses confidence.

Till today when the stock is on a free fall (-14%). The analysts didn't sound to impressed. They've known about the XBone/PS4 wins for a while and it's already been factored into their higher share price. They need another big win like Google/Facebook looking for a custom APU.

The complete lack of any mention of Kaveri/Steamroller troubled me. In January they at least mentioned that Richland was shipping to select OEMs.