juanrga :
hcl123 :
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!...