Odpověď na názor

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.