Vlákno názorů k článku Příchod Zenu 5 se přiblížil. Vzorek procesoru Ryzen 8000 se objevil na internetu od Pavka - Ano, Zen5 pro desktopy bude mít stále 8...

1) ALU = Arithmetic Logic Unit
Aritmetická .... protože dělá výpočty
Logická .......... protože rozhoduje podmíněné skoky-větvení

Zastaralé procesory od 8088 až po Intel Raptor Cove mají univerzální ALU (Raptor třeba 5x ALU, kde dvě z nich umí i vyhodnocovat větvení (branch). Stejně to má i Zen 2, který má 4x ALU a dvě z nich umí větvení).

Takže větvení se mezi ALU funkce odjakživa počítá (jinak by to historicky nedávali na ALU jednotky a nijak to v názvu nerozlišovali). To že to ve schématech označují jako "Branch Unit", není proto že by to nebyla ALU funkce, ale protože to nějak musí od ALU odlišit, když je to jednoúčelová jednotka. Navíc některé z těch INT jednotek nastavují flag jestli výsledek odčítání (instrukce CMP) byl menší/větší/roven nule, takže pracují v úzké spolupráci s Branch unit (resp ji krmí svými výsledky, protože v C++ se IF/FOR/WHILE se přeloží do assembleru jako dvojce instrukcí CMP + JMPGT třeba, CMP provede rozdíl dvou čísel a nastaví flag, JMPGT pak skočí tam podle toho co je v GT flagu).

Každopádně hlavní myšlenka je taková, že 4x ALU + 1x Branch v Zen 4 je ekvivalent 5x ALU v Raptor Cove. IPC záleží na součtu ALU + Branch, nikoliv jen na ALU. A taky IPC Zen 4 i Raptoru je od sebe jen pár procent. Branch instrukcí je nějakých 20% takže u Intelu stejně ta pátá ALU je vytížena výhraně Branch instrukcemi. V Applu a ARMu na to přišli dávno že je dobré to mít zvlášť, v AMD to Keller navrhnul hybridně, že 4. ALU taky umí Branch a vypomůže když ta dedikovaná Branch jednotka nestíhá. ARM místo hybridní ALU/Branch jednotky radši dal 2x Branch ikdyž ta jedna byla vytížená jen částečně.

Já to označuji jako INT + branch = ALU, protože je to pro inženýry logičtější, než poněkud zmatené ALU + Branch = ALU. Ale whatever, jde o princip a ne o zkratky.

.
.
.
2) Prediktory:

Jo jasně, ale já se nebavil o prediktorech větvení programu, ale o prediktorech uvnitř dekodéru, což je úplně něco jiného a vůbec to spolu nesouvisí. Prostě 2. instrukce x86 může začínat na 2. bajtu nebo až na 16. bajtu a aby dekodér nemusel brute force prohledávat všechny možnosti (což nelze dělat sériově, takže by musel mít 15 paralelních dekodérů místo toho druhého, celkově 16), tak se využije faktu že existují různá komba instrukcí (typicky zrovna CMP + JMP) a při detekci CMP na prvním dekoderu se predikuje JMP instrukce na druhém, tedy se ušetří brute force prohledávání.

Jak spolehlivá ta predikce je netuším, ale nikdy nebude 100% to je jisté. Jinak by AMD a Intel nemuseli mít brutálně velké microOP buffery, kde si syslí velmi draze dekodované x86 instrukce.

Navíc bych řekl, a to je čistě můj logický úsudek, že čím víc instrukcí je potřeba dekodovat paralelně, tím je těžší takové komba predikovat úspěšně. U dvojtého dekoderu úspěšné předpovězené kombo CMP + JMP znamená 100% úspěšnost predikce. U dekoderu pro 6 instrukcí jako má Raptor tyto dvě instrukce pokryjí jen 33% instrukcí a zbývajících 66% bude velký problém odhadovat, protože tam může být cokoliv. Respektive bude potřeba lepší a objemější prediktory zatímco RISCový ARM na tohle nemusí utratit ani jeden tranzistor a vyplýtvat jedinou minutu času inženýra. CISC je prostě slepá cesta.

AMD svého času používala překlad z x86 do RISC86, uměla to tuším jejich K6 jakožto vynález zděděný koupí NexGenu. Ale byly to vnitřní instrukce, ikdyž to ještě nebyly mOP. Ostatně K5 byla RISCový AMD AM29000 kam připlácli x86 dekodér. Škoda že AMD neudělao RISC86-64 (místo CISC AMD64) to by totiž mohlo fungovat velice dobře.Ikdyž pořád by to byl uzavřený duopol.

"Každopádně hlavní myšlenka je taková, že 4x ALU + 1x Branch v Zen 4 je ekvivalent 5x ALU v Raptor Cove. IPC záleží na součtu ALU + Branch, nikoliv jen na ALU. A taky IPC Zen 4 i Raptoru je od sebe jen pár procent. Branch instrukcí je nějakých 20% takže u Intelu stejně ta pátá ALU je vytížena výhraně Branch instrukcemi."

To si myslím, že moc nesedí se skutečností. Pro Zen4 nejsou určující jen tyhlety počty jednotek, ale také například míň silné load/store jednotky a výrazně méně hluboký ReOrder Buffer.
To, že přesto dosáhne podobného IPC je navzdory počtu jednotek. A je to pravděpodobně proto, že má velmi efektivní prefetching a branch prediction, díky kterým z určitého počtu jednotek je schopen vydupat takto vysoké IPC. Implikace je, že je v tomhle jádro AMD zřejmě efektivnější a možná pokročilejší proti Golden Cove/Raptor Cove Intelu, které na takové IPC potřebuje víc jednotek a větší out-of-order struktury. Ale tak jednoduché to samozřejmě není, je tam spousta různých faktorů a věcí.

Výkon a IPC závisí stručně řečeno na mnohem více věcech. Například: Cortex-X4 s 8 ALU bude mít nejspíš nižší IPC než jádra Apple s jen šesti.

Jinak to, že podle vás branch patří mezi ALU instrukce, nedělá z jednotky branch ALU, samozřejmě, když neumí nic jiného. Těmi logickými instrukcemi se jinak myslí základní operace jako AND, OR a ta dále (aritmetické jsou asi jasné)...

"AMD svého času používala překlad z x86 do RISC86, uměla to tuším jejich K6 jakožto vynález zděděný koupí NexGenu. Ale byly to vnitřní instrukce, ikdyž to ještě nebyly mOP. Ostatně K5 byla RISCový AMD AM29000 kam připlácli x86 dekodér."

To si myslím že mluvíte o prostě tom kalsickém schématu, kdy procesor překládá instrukce své standardní ISA na microOpy. V té době se to ozančovalo a popisovalo všelijak, takže je třeba dávat pozor, aby si z člověk ze sarých článků neudělal zavádějící dojem, ale mikorarchitektury K5, K6, Pentium Pro a všechno od té doby jsou od té doby vesměs stejná koncepce. A také všechny novější Power a ARMy, dekódování na microOpy je už takový standard, kterým se setřely rozdíly mezi RISC a CISC.

1) Load, Store jednotky nemají na IPC vliv, protože OoO Rename provádí tzv. eliminaci Load/Store párů, takže třeba Intel má obrovské množství LSU, ale IPC tomu moc neodpovídá.

Co se stane když kompilátoru nestačí 16 registrů pro proměnné uvnitř x86 CPU? (třeba 64-bit ARM má 32 registrů, takže dvojnásobek) Ty co zrovna nepotřebuje tak uloží do RAM nebo na zásobník a pak si je načte zpět (tedy load-store dvojce). 486 udělá přesně to ji kompilátor nařídí, jenže moderní OoO CPU má 200 registrů a ROB okno na 300 instrukcí, takže logicky dokáže detekovat tohle dočasné uschovávání a v Rename si namapuje architekturální registry na ty svoje fyzické kterých má stovky a ty zbytečné load-store vyhází pryč. Tím se obchází omezení staré x86 ISA (hlavně 32-bit x86 měl jen pouhých 8 registrů) a taky to šetří energii.

Takže LSU/AGU jednotky toho o IPC řeknou méně než počet ALU.

2) IPC = ALU + Branch
Důvod je jednoduchý, Branch instrukce nelze přeskočit ani eliminovat tak jako L/S. Prostě INT výpočty a Branch instrukce tvoří integrální základ výpočetního výkonu (scalar INT IPC).

Navíc Branch jednotka potřebuje pro svou funkci nutně INT výpočet, který nastaví Flag podle toho jestli vypočtená hodnota byla větší/menší/rovna. To tady nikdo nikdy nedělal v assembleru alespoň základy ze střední školy???
.
.
.
.

3) IPC s počtem ALU (myšleno ALU + Branch) samozřejmě úzce souvisí. Ze směšných 2xALU v propadáku jménem Bulldozer prostě vysoké IPC nikdo nezíská, protože ani ten nejlepší OoO od Applu by přes ty 2 jednotky těch 8 instrukcí nikdy neprotlačilo ikdyby mělo ROB s milionem instrukcí. To je myslím každému jasné.

Každopádně lze obecně tvrdit, že 8+3 =11xALU ekvivalent Cortex X4 bude mít vždy vyšší IPC než jaký koliv 6xALU stroj (tedy 5xALU Raptor nebo 4+1 Zen4), protože prostě má 11x ALU což je 2,2x víc ALU jednotek jejichž vytíženost je vždy větší než 50% i v první generaci. Apple 6+2 je 8xALU stroj v 5. generaci, takže ten má vytížení ALU na max a už dva roky se čeká nová širší generace. Navíc IPC toho 6+2=8xALU Apple M2 je o 47% vyšší než 5xALU, což téměř přesně odpovídá tomu že má o 50% víc ALU. Je to hrubý metr a ne vždy sedí, uznávám, ale je to ten nejlepší jaký je k dispozici při pohledu na schema architektury.

Taky se dá predikovat, že pokud Zen 5 a Meteor Lake nebudou 8+3 (tedy také kolem 11x ALU) tak je druhá a třetí generace 8+3 Cortexu (X5 a X6) a nový Apple M3 totálně rozdrtí. Opět se můžeme bavit jestli je vůbec reálné na x86 mít dekodér na 10 instr/takt, když to znamená 639 možností kde těch 10 instr začíná.
.
.
.
4) RISC86
Pointa je v tom, že čistý CISC CPU už desítky let neexistuje.
Existují pouze RISC procesory, některé zatížené HW emulací CISC x86.

Takže se nabízí otázka proč neostranit ten starý CISC x86 humus a nepřejít na RISC verzi x86 ?

Tedy kromě toho že Intel a AMD se nás snaží přesvědčit že X86 je skvělá protože má KOMPLEXNÍ instrukce (co je logicky něco víc než ty redukované že jo mámo, protože to říkal Franta že když dá v traktoru redukovanou rychlost tak jede pomaleji, coz není legrace protože si to myslí 99% uživatelů PC), přičemž ani redaktoři co píší o procesorech nemají ponětí že x86 je starý komplikovaný anachronismus co měl zmizet před 20 lety tak jako ostatní CISC. A hlavně že RISC může mít stejně komplexní instrukce ve smyslu výpočetního výkonu jako CISC. A taky že má: ARMv9 má instrukce SME2 pro matrix výpočty s šířkou až 2048-bitů o čemž si může x86 i s jejich AVX512 leda nechat zdát vlhké sny).

Ono totiž konverze CISC x86 -> RISC86 není žádná věda. Změní se Opcode ve strojáku, ale třeba názvy instrukcí v assembleru zůstanou prakticky stejné. Akorát jedna strojová multi-instrukce nebude mít prefixy a postfixy, takže prostě incrementace/de­krementace proměnné bude zvlášť RISC instrukce o 4 bajtech (stejně jako je incrementace zvlášť v assembleru i pro CISC) a nikoliv 1 bajtový CISC přílepek, který kvůli úspoře 3 bajtů na i8086 v roce 1978 brutálně komplikuje dekodování v roce 2023.

No teda fascinuje mě, jak jsou pro vás některé věci extrémně určující a jiné zase naprosto zanedbatelné. Na všechno teda reagovat nebudu, ale:

"Load, Store jednotky nemají na IPC vliv, protože OoO Rename provádí tzv. eliminaci Load/Store párů, takže třeba Intel má obrovské množství LSU, ale IPC tomu moc neodpovídá."

A co když výpočetní smyčka čte stream jedněch dat z paměti a druhý stream zapisuje?

IPC je taková statistická věc, aplikací jsou tisícovky a víc a mají různé charakteritisky, věci, které jim pomáhají se mění, nakonec se z toho dá udělat nějaké způrměrované číslo. Když se na load/store vykašlete, tak vám u části z nich vyjde nižší procento a do průměru se to na konci promítne...

Jinak to SME2 už je v nějakém procesoru nasazené? Intel má maticové instrukce AMX s podobným určením a už na trhu jsou (ač ta CPU měla rok a půl zpoždění, takže ARM ekosystém dostal nějakou tu možnost je předběhnout...)

14. 6. 2023, 13:50 editováno autorem komentáře

1) Možná se tomu bude někdo divit, ale počítač je od slova počítat. A protože ALU jednotky počítají a dělají logiku větvení programu, tak nějak asi každému dojde, že to co dělá výkon je ALU. Bez ALU jednotky žádný CPU sestrojit nelze. Bez LSU ano.

Jinak samozřejmě stream vstupních a výstupních dat eliminovat nelze, to jsem ani nepovažoval za nutné zmíňovat. To je snad samozřejmost vyplývající z pochopení principu, že eliminace se týká jen dočasných hodnot mezivýpočtů (kterých je tam hodně).
.
.
.
SVE vs AMX
SVE (představeno 2016) mělo maticové instrukce a bylo tady CPU v 2019 tedy 4 roky před Intelem. Takže ten kdo tady výrazně ztrácí je x86 svět. ARM provedl slušný skok ze 128-bit NEON na superpočítačové SVE umožňující až 2048-bit.

Ale hlavně CPU-only ARM/SVE superpočítač byl schopen porazit obří výpočetní GPU od Nvidie. O tom si Intel i s AMD zatím můžou nechat zdát.

SME2 by v CPU mohlo dorazit asi 2025, nejspíš v novém Fujitsu pro další superpoč, který opět nakope jak x86, tak GPU. Jinak by CPU-only nedělali že.