AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd

[del42sa]

Klid Docu... Mluvilo se o tom ze L1 32kB je malo a proto hodnotim jeji zdvojnasobeni jako dobrej krok.

ale pozor ! Datová cache zůstává pořád stejná, tedy pouze 16kB/instrukční 64kB jako u BD, zvětšila se pouze velikosti Data Translation Lookaside Buffer (DTLB) a u některých vyšších modelů hloubka load queue a FPU chart, u Opteronů rodiny 20+h i schopnosti exekučních jednotek. Trinity se ale týká pouze ten větší TLB buffer...

http://home.dei.polimi.it/sami/architet ... ldozer.pdf

Write through mechanizmus je u BD použit právě proto, že datová L1 cache je příliš malá a data jsou tak najednou zapsaná v obou cache L1 i L2. Zvyšují se tím latence při zápisu, který je limitován rychlostí L2. Naopak snižují se tím latence při čtení, protože potřebné data jsou vždy i v rychlejší cache.


rekapitulace silných a slabých stránek BD: http://pctforum.tyden.cz/viewtopic.php? ... 0#p8268700

[yuri.cs]

Zda je vyhodnejsi zdvojnasobit L1 nebo zdvojnasobit L2.
Ja myslim ze v AMD vedi co delaji

TLB != vlastni cache

Snad to v AMD vedi taky...

[flanker]

pro zajímavost, použitá stará roadmapa a fake s takty Vishery FX který dnes obíhá internetem...

http://www.techpowerup.com/forums/showp ... stcount=14

[Maor]

já bych řekl, že ty takty jsou dost blízko, FX4170 je už teď přes 4GHz a Piledriver přijde až za 6měsíců, to mohli výrobu ještě vylepšit

[flanker]

ee, já odhaduju nárusty jen cca 100 MHz v základu (bez turba), spíš se zvedne výkon na takt, i když mi moc nevěří v tomto nikdo a sníží spotřeba.

[del42sa]

porovnání latencí:


zvláště L2 a L3 latence jsou příšerné vzhledem k vysokým taktům BD a v porovnání se "starým" Phenomem II nebo SB

[yuri.cs]

Ta tabulka z xbit je 1:1 z cpuworldu. Cili to, co nekdo natypoval. Jedine co je dane je:
00h-0fh = Orochi
10h-1fh = Trinity

Uverim, pokud mi nekdo uveritelne zduvodni a kodove oznaceni modelu: 00h-1fh a predevsim 10h-2fh.

Proc by se nekdo vubec babral s upravama stati o FPU latencich pro 10h-2fh, kdyz by slo o nevydany model nebo o neco hodne vzdaleneho.

//tez bude zajimave rozuzleni hadanky:

The following performance caveats apply when using streaming stores on AMD Family 15h cores.

• When writing out a single stream of data sequentially, performance of AMD Family 15h
processors is comparable to previous generations of AMD processors.
• When writing out two streams of data, AMD Family 15h version 1 processors can be up to three
times slower than previous-generation AMD processors. AMD Family 15h version 2 processor
performance is approximately 1.5 times slower than previous AMD processors.
• When writing out four non-temporal streams, AMD Family 15h version 1 can be up to three
times slower than previous AMD processors. AMD Family 15h version 2 processor performance
is comparable to previous AMD processors.
• Using non-temporal stores but not writing out an entire cacheline may cause performance to be up
to six times slower than previous AMD processors.

[Maor]

těch 10 PDjader nebude, bude jen 8, tak jak bylo v roadmapách

[flanker]

10 bude možná pro servery....

[del42sa]

slabá a silná místa Bulldozer architektury dle Agnera:

Bottlenecks in AMD Bulldozer

The AMD Bulldozer is a major redesign of previous microarchitectures. Some of the most
important improvements are:
• Four pipelines giving a maximum throughput of 4 instructions per clock cycle.
• Improved floating point unit with high throughput
• Better scheduling of macro-ops to the first vacant execution unit
• Some register-to-register moves are translated into register renaming
• Branch prediction is no longer tied to the code cache and there is no limitation on the
number of branches per code cache line
• AVX instruction set with non-destructive 3-operand instructions
• Efficient fused multiply-and-add instructions (FMA4)

Various possible bottlenecks are discussed in the following paragraphs.

Power saving
The power saving features are reducing the clock frequency most of the time. This often gives inconsistent results in performance tests because the clock frequency is varying. It is sometimes necessary to put a long sequence of CPU-intensive code before the code under test in order to measure the maximum performance.

Shared resources
The instruction fetch and decoding circuitry is shared between the two cores that make a compute unit. The branch predictor and the floating point units are also shared. Some operating systems are not aware of this so that they may put two threads into the same compute unit while another compute unit is idle.

Instruction fetch
The shared instruction fetch unit can fetch up to 32 bytes per clock cycle or 16 bytes per core. This may be a bottleneck when both cores are active or when frequent jumps produce bubbles in the pipeline.

Instruction decoding
The decode unit can handle four instructions per clock cycle. It is alternating between the two threads so that each thread gets up to four instructions every second clock cycle, or two instructions per clock cycle on average. This is a serious bottleneck in my tests because the rest of the pipeline can handle up to four instructions per clock.
The situation gets even worse for instructions that generate more than one macro-op each.The decoders cannot handle two double instructions in the same clock cycle. All instructions that generate more than two macro-ops are handled with microcode. The microcode sequencer blocks the decoders for several clock cycles so that the other thread is stalled in the meantime.

Out-of-order scheduling
The integer out-of-order scheduler has 40 entries, the shared floating point scheduler probably has somewhat more. This is a significant improvement over previous designs.

Execution units
The integer execution units are poorly distributed between the four pipes. Two of the pipes have all the execution units while the other two pipes are used only for memory read instructions, and on some models for simple register moves. This means that the Bulldozer can execute only two integer ALU instructions per clock cycle, where previous models can execute three. This is a serious bottleneck for pure integer code. The single-core throughput
for integer code can actually be doubled by doing half of the instructions in vector registers, even if only one element of each vector is used.
The floating point execution units are better distributed so that all four pipes can be used.
The most commonly used units are all doubled, including floating point addition,multiplication and division, as well as integer addition and boolean operations. All units are 128 bits wide. This gives a high throughput for 128-bit vector code which is likely sufficient to serve two threads simultaneously in many cases. All 256-bit vector instructions are split into two 128-bit operations so that there is little or no advantage in using 256-bit vectors.
The fused multiply-and-add instructions are very efficient.They are doing one addition and one multiplication in the same time that it otherwise takes to do one addition or one multiplication. This effectively doubles the throughput of floating point code that has an equal number of additions and multiplications. The incompatibility of the FMA4 instructions with Intel’s forthcoming FMA3 instructions is actually not AMD’s fault, as discussed on my blog.

Mixed latencies
Mixing operations with different latencies will cause less problems than on previous processors.

Dependency chains
Latencies for floating point instructions and integer vector instructions are relatively long.Long dependency chains should therefore be avoided. Accessing part of a register causes a false dependence on the rest of the register.

Jumps and branches
Jumps and branches have a throughput of one taken branch every two clock cycles. The throughput is lower if there are 32-byte boundaries shortly after the jump targets. Branch prediction is reasonably good, even for indirect jumps. The branch misprediction penalty is quite high because of a long pipeline.

Memory and cache access
The cache access is reasonably fast for all three cache levels, but cache bank conflicts are very frequent and often impossible to avoid. Cache bank conflicts turned out to be a serious bottleneck in some of my tests. The code cache has only two ways which is quite low when we consider that it has to service two threads.

Retirement
There is no evidence that retirement can be a bottleneck.

[webwalker]

del42sa: Koukám, že konečně Agner doplnil svou architekturu o Bulldozer, to mu to ale trvalo
Dobrý úlovek

[yuri.cs]

Vetsina z tohohle uz byla recena (male fetch window, 4 micro instrukce pro 2 thready, blokovani dekoderu dlouhymi microdeced instrukcema, 2 ALU, etc.).

Co je docela zajimave:
-max. dosazeny fetch rate 22B pri jednom threadu;
-nedosazitelne 2 mem. operace s L1D za cyklus;
-spokojenost s cache systemem.

Zachovat sdilenou BPU, mikrokod ROMku, L1I ale dekoder a fetch zdvojit. Plocha jadra se zvetsi o ~15%, ale bottleneck se razem uplne vypari. Kdo vi, jestli se soudruzi z AMD v tom frontendu nekdy povrtaji.

[richie08]

Bulldozer je celý koncepčně špatně, takže jeho další vylepšování nebo předělávání je bezpředmětné. Vylepšený BD se dostane na trh jen proto, že jeho vývoj je již hotový a nebo nemají adekvátní náhradu. Smysl dává jen to co udělal Intel s P4: poučit se z chyb, vzít dobré věci z neúspěšné architektury a vrátit se k vylepšování tomu co fungovalo (K8,K10).

yuri.cs: Řekl bych, že jedna dobrých věcí na BD jsou sdílené části CPU, tedy nic bych nezdvojoval, ale naopak by bylo dobré přijít se sdílenou ALU. Stačilo by kdyby jen spojili dosavadní 2+2 ALU do 4 ALU + 4 AGU a děli by se věci....k tomu silnější FPU a v pohodě by se dostali v IPC nad Phenom II, výkonově by to mohlo hodně potrápit SB i IB. Samozřejmě spotřebou by to bylo špatné stejně jako rozměry. Alespoň by to mělo VÝKON. Jenže za chvíli tu máme Haswel, takže asi by se na vylepšování BD měli vykašlat a udělat rovnou něco pořádného: 1C/4t: 6ALU+4AGU+zdvojnásobit FPU výkon, schopnost zpracování 4 threadů....možnosti tu jsou. A mezitím v krátkodobém horizontu se vrátit ke K10 a upgradnout.

[del42sa]

snad si někdo z AMD občas přečte podobné hw fóra, protože někdy má člověk dojem, že tam pracují lidi co CPU vůbec nerozumí

richie08: ano to říkám už dávno, kdyby BD měl stejnou schopnost jako T4 Ultrasparc spojit 2 integrer clustery a exekuční jednotky do jednoho (silného) threadu, respektive se chovat jako 4 jádro (4 way issue) a v případě potřeby se rozdělit na 8 threadů (2 way issue).

viz naše stará debata:

http://pctforum.tyden.cz/viewtopic.php? ... g#p8186641

http://pctforum.tyden.cz/viewtopic.php? ... 7#p8220257

[yuri.cs]

Vylepšený BD se dostane na trh jen proto, že jeho vývoj je již hotový

Tak to bez diskuze ano.

S tim frontendem je ale urcite neco spatne. 16B/thread je presne tolik, kolik ma K8. Kdyz uz nic, tak s pribyvajicim rozsirenim x86 sady se instrukce pekne prodluzujou. Taky to, ze samotny thread na modulu dosahne v testovacich podminkach 22 z 32B je prinejmensim zvlastni.

Stavet masivni cipy by urcite slo, ale kdo by si to v dnesni *green* hysterii koupil, kdyz by to zralo jako michacka? Highend by si to ospravedlnil ale zbytek? Jak ho seskalovat? Vypnout totalne HT a snizit frekvence?

[richie08]

snad si někdo z AMD občas přečte podobné hw fóra, protože někdy má člověk dojem, že tam pracují lidi co CPU vůbec nerozumí

To by ses divil v kolika velkých firmách pracují lidé na vysokých pozicích, kteří tam svými znalostmi a schopnostmi nemají vůbec co dělat. Ostatně proč myslíš že dostal Dirk Meyer a několik lidí z vývoje BD padáka?Nebuď naivní, ten downgrade co předvedli z Phenoma II myslím hovoří docela jasně

yuri.cs: Ono to stejně k masivním čipům stejně směřuje. Na 22nm a 16nm stejně budou CPU s minimálně 4mi jádry, to platí již dnes pro ARMy, a brzy bude i pro Bobcaty/Atomy. Minimum prostě bude čtyřjádro. Takže proč místo oddělěných jader nevzít souhrnně všechny ALUs a FPUs atd. a neudělat jedno masivní jádro s možností zpracování několika vláken. Má to snad samé výhody: vyšší efektivita a výkon, skvělý single výkon, spotřeba by měla být díky vyšší efektivitě snad o něco nižší, počet tranzistorů dejme tomu plusmínus stejný. Samozřejmě to potřebuje hodně invence, spoustu šikovných inženýrů by muselo žhavit lebku, také možná by tam byl jistý nárůst tranzistorů...ale díky Sun Niagara víme že to lze. Lze si představit že na ploše Phenomu II X4 by mohlo být jedno jádro s 12ALUs, 4FPUs, 12LSUs, 512kB L1 cache, 2MB L2 cache, 6MB L3, schopnost zpracování 8 vláken.

To že se dnes lepí spouta malých jader je spíš znouzectnost, protože z historického kontextu bylo vždy na čipu místo jen na jedno CPU a to ještě se museli dost držet vývojáři při zemi s implementací různých featur, protože zkrátka počet tranzistorů byl omezen výrobním procesem. Ostatně není to tak dávno co se musela L2 cache lepit k CPU externě. Zatím se to snaží zaplácnout integrací GPU a jiných jednoúčelových obvodů ať už pro video nebo pro šifrováí, ale prostor pro rozvoj CPU tu prostě je.

Bohužel, původní BD měl být podle všeho právě masivní CPU.... a co z něj nakonec udělali víme

[del42sa]

Takže proč místo oddělěných jader nevzít souhrnně všechny ALUs a FPUs atd. a neudělat jedno masivní jádro s možností zpracování několika vláken. Má to snad samé výhody: vyšší efektivita a výkon, skvělý single výkon, spotřeba by měla být díky vyšší efektivitě snad o něco nižší, počet tranzistorů dejme tomu plusmínus stejný. Samozřejmě to potřebuje hodně invence, spoustu šikovných inženýrů by muselo žhavit lebku, také možná by tam byl jistý nárůst tranzistorů...ale díky Sun Niagara víme že to lze. Lze si představit že na ploše Phenomu II X4 by mohlo být jedno jádro s 12ALUs, 4FPUs, 12LSUs, 512kB L1 cache, 2MB L2 cache, 6MB L3, schopnost zpracování 8 vláken.

tohle by nikdy nemohlo dobře fungovat, protože x86 kód nelze paralelizovat, více jak 4 ALU prostě už nedokážeš nevyužít. Už Phenom se svými 3 ALU nedokázal všechny jednotky naplno vytížit. Proto má BD jen 2 ALU.CPU není GPU. Takže 12 ALU na jeden thread je nesmysl, který by akorát žral energii, nehledě k tomu, že nemůžeš mít 12 ALU bez patřičně masivního frontendu/dekodéru. To vše akorát stojí spoustu tranzistorů bez reálného navýšení výkonu !

Stačilo by úplně, kdyby BD modul uměl pracovat jako jedno jádro s 4 way issue porty a v případě potřeby se rozdělil na současný poměr (2 way issue). A možná by ani tohle nebylo potřeba, stačilo by se zaměřit na slabé stránky BD, které už známe a nový návrh vyrobit třeba 20nm FD-SOI High-K Gate last výrobním procesem

[yuri.cs]

-512kB L1 cache by byla tak silene pomala, ze jenom to by to CPU zabilo
-kdyz by tech 12 jednotek nebylo vytizenych, tak porad by tam byla leakage a tu by tu neodstavil powergatingem jako u jadra
-wiring a scheduling x*12 homogennich jednotek by byl takova nocni mura, ze radsi ani nemyslet
-atd.

btw je nejakej wpaper s tim slucovanim klustru/core v T4?

Co ja tu mam za promo od SUNu. Tak tam stoji jenom to, ze misto 8 nasobnyho SMT (rozumne vyuzivajiciho LRU) s 2 threadama soucasne lze zredukovat na klasicky 1 nasobny (napalite prioritu 1 vybraneho threadu) a zbylych 7 threadu pobezi jenom kdyz jsou runnable. Celkem logicky 64T cip obsahuje toolset pro thread/process binding, zminene priority a grouping na urovni jader i CPUcek. Jinak by to managovani nestalo za mnoho. Plus, nepopritelna velka vyhoda je svazanost se Solariesm.

Nebo jenom blbe koukam?

[DOC_ZENITH]

To by ses divil v kolika velkých firmách pracují lidé na vysokých pozicích, kteří tam svými znalostmi a schopnostmi nemají vůbec co dělat.

JJ, nejhorší je někdo ne vysokym vlivnym postu ze kterého jej nemůže nikdo jednoduše odvolat.

Lidská vlastnost je totiž neuznávat chyby, neříkat "podělal jsem to", atd. A tito lidí když maj nápad a ten se v praxi káže jako epic fail, tak místo toho aby stahli ocas mezi půlky a šlo to do koše, tak to tlačej dál a dál jen aby prosadili svou a že oni měli pravdu a že jejich koncept je ten správný.

Ne nadarmo lidé co stáli za boomem AMD, K7 a K8 už v AMD nejsou.

Intel taky držel Netbrust alive i když měl mnohem lepší řešení, nutil lidi kupovat tu s**** protože někdo nahoře tvrdil že je to správná cesta, ta věc byla death na rozhraní 2003/2004 a přesto na tom intel dělal do roku 2006 než konečně uznal že jaksi ne... A Itanium je ještě horší story.

Nezbejvá než doufat, že ten "vizionář" co viděl v konceptu BD cestu letěl také.

Yuri - Sparc to má úplně jiné, neni totiž omezenej x86 backwards kompatibilitou někde z 80. tých let. On je totiž důvod k tomu že krom windows powered PCček se x86 prakticky nepoužívá. (ano používá jí i Mac protože má velkou produkci a je super levná).

[del42sa]

Yuri: Našel jsem jen tohle : http://www.oracle.com/technetwork/serve ... 496245.pdf

Dynamic Threading
SPARC T4 is dynamically threaded. While software can activate up to eight strands on each core at a time, hardware dynamically and seamlessly allocates core resources such as instruction, data, and L2
caches and TLBs, as well as out-of-order execution resources such as the 128-entry re-order buffer in the core. These resources are allocated among the active strands. Software activates strands by sending an interrupt to a HALTed strand. Software deactivates strands by executing a HALT instruction on each strand that is to be deactivated. No strand has special hardware characteristics. All strands have identical hardware capabilities.
Since the core dynamically allocates resources among the active strands, there is no explicit "singlethread mode" or "multi-thread mode" for software to activate or deactivate. If software effectively
halts all strands except one on a core via Critical Thread Optimization (described later in this document), the core devotes all of its resources to the sole running strand. Thus, that strand will run as quickly as possible. Similarly, if software declares six out of eight strands as non-critical, the two active strands share the core execution resources.

a pak jen nějaké studie zabývající se spekulativním multithreadingem:

http://liberty.princeton.edu/Publicatio ... bility.pdf

http://personals.ac.upc.edu/antonio/con ... _paper.pdf

http://cseweb.ucsd.edu/~jbrown/papers/sp-cmp.pdf

http://www.ece.lsu.edu/tca/papers/collins-01.pdf

The proposed scheme outperforms previous hardware-only schemes to implement the idea of combining cores for executing single-thread applications in a multi-core design by more than 10% on average on Spec2006 for all configurations. Moreover, single-thread performance is improved by 41% on average when the proposed scheme is used on a Tiny Core, and up to 2.6x for some selected applications