Názory k článku Velké změny pro procesory x86. APX odstraňuje limity legacy instrukcí, přebírá i nápady ARMu

A ty 2048 bit vektory budou ci nebudou? Podle zdejsich diskusi je evidentní, že je to doslova killer featura, nejvetsi technologicky ve CPU za posledních 500 let.

budou, až Intel zruší x86 instrukční sadu a přejde plně na ARM procesory .-)

To je právě ten průser. Tohle nové APX přidává AVX10.1 a 10.2 kdy posledně zmiňované umí AVX512 instrukce pro 128-bit a 256-bit šířku registrů SIMD a volitelně i 512-bit. Takže tím Intel řeší ten binec s backportováním VNNI instrukcí z AVX512 do AVX2 pro 256-bit e-core Gracemont. Ale pořád to neumí instrukce nezávislé na šířce registru jako to umí ARM SVE/ SVE2 / SME / SME2. Takže o 2048-bit SIMD nebo o SW nezávislým na šířce instrukcí, který si umí vektory porcovat podle toho co za šířku SIMD dynamicky detekuje za běhu programu, o tom si svět x86 pořád může nechat zdát sny.

Citace Intelu k rozšíení registrů na 32 jako má ARM :"Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations."

Takže to je přiznání přímo od Intelu, že ISA má zásadní vliv na spotřebu/efektivitu CPU. Takže jsem měl celou dobu pravdu a Jan Olšan se mýlil že ISA nemá vliv. Jsem zvědav kdy přizná svou chybu a omluví se mi. "Já totiž trvám na opakování ceremoniálu!" :D (řekl bych pan redaktor se tomuto tématu záměrně vyhnul aby nemusel přiznat že celou dobu byl vedle jak ta jedle. To už je život, ne každý má koule na to přiznat že se sekl).

Každopádně ARM měl koule v roce 2010 zahodit komplet 32-bit ARMv7 a vytvořit zcela novou 64-bit ISA s čistým listem papíru (tedy binárně nekompatibilní). Tohle APX je další přílepek už tak hrozného bloatu s názvem x86. To je rozsudek smrti.

Aha a ony jsou přístupy k registu natolik zásadní, že samy o sobě ovlivňují spotřebu CPU v desítkách %. Určitě ne. Navíc ten problém dávno x86-64 řeší po svém, což v článku je napsáno.

"Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations."

Dle Intelu registry mají výrazně nižší spotřebu než LD/ST operace. Desítky procent sis vycucal z prstu ty sám, protože nemáš ponětí jak CPU pracuje, ale když vezmu v potaz že kompilátoru dojde počet registrů, tak musí použít Load - Store / push -pop na zásobníku, což znamená vypočítat adresu v paměti, a přes TLB vypočítat adresu fyzické paměti, zatíží to cache subsystém pokud to spadne do L1. Ono to zůstane v nejspíš ve fyzických registrech a OoO engine tyto LD/ST páry eliminuje v Rename v rámci ROB okna, ale pointa je ta, že když máš dost registrů, tak odpadne spousta toho zbytečného LD/ST eliminování v první řadě, protože CPU umí eliminovat v každém taktu jen určitý počet párů instrukcí.

Jako není to sranda za běhu programu na 6 GHz provádět analýzu instrukcí a zjišťovat které jsou zbytečné a které ne. To musí žrát hromadu energie. Dostatek registrů v podstatě tuto eliminaci z CPU přesouvá na kompilátor a samotný CPU pak má mnohem méně práce (stačí mu menší eliminační obvody) a tedy má menší spotřebu při stejném výkonu.

Jsem si dost jistý, že pokud Jan Olšan něco takového tvrdil, je to vytržené z kontextu.

Mimochodem nechcete začít pro Extrahardware psát články od AMRu, SVE, ALU a tak, a vystavit tak svou kůži na trh pod svým skutečným jménem? Nebo klidně i pro jiný magazín. Narozdíl od flamu v diskuzích jsou za to skutečné peníze ;-)

Radši pro jiný! Ale on psal, že má ty zahraniční firmy s miliony zařízení co mu platí 400€ za hodinu IIRC, to by si u nás "lehce" pohoršil :)

26. 7. 2023, 20:21 editováno autorem komentáře

Nebudou, je to naprosto o nicem.... :)

Dobrý vtipek (:

Inak s rozšíreným zrejme veľký problém nebude. AMDe určite APX a ostatné novinky rado okopíruje, to je ich obľúbená činnosť na ktorej totiž historicky založili svoje podnikanie ;)

Číňanom na druhej strane by to dovoliť nemuseli...

2048 bit instrukce na 128 / 256 bit jednotkách dávají super smysl... Nejširší má Fujitsu - 512 bit, takže i tam to je na 4 průchody tou jednotkou.

SVE vektory nejsou revoluční tím, že umí 2048-bit šířku vektoru, ale hlavně tím, že instrukce SVE neobsahují informaci o šířce toho vektoru. Proto lze naprogramovat SW tak, že umí pracovat s jakoukoliv šířkou SIMD v CPU, tedy od základních 128-bit, přes 256-bit .... až po těch 2048-bit. Podle toho jak širokou SIMD ten SW po spuštění detekuje, tak si ty vstupní data rozseká automaticky.

To je na tom to geniální. Jeden a ten samý SW běží maximálně rychle na všech 16-ti různých SIMD šířkách SVE. Dnes ti tvůj SW poběží na těch 512-bit SVE, ale za pár let až někdo udělá 2048-bit SVE tak ten samý SW poběží automaticky 4x rychleji. Tohle x86 s fixníma vektorama neumí, starý SW který používá 128-bit SSE ti na moderním Zen 4 co umí AVX512 nepoběží 4x rychleji v 512-bit módu. SVE tohle umí.

Tohle sice zní velice hezky, v praxi to bohužel ale tak dokonalé není. Ta variabilní šířka často přináší víc problémů, než užitku. Na triviální věci typu SoA to funguje bezvadně, ale jakmile je algoritmus složitější a obsahuje i "horizontální" složku (což je dost často), tak jste v háji...

Nevím kolik jsi toho naprogramoval pro SVE, ale vypadá to, že máš víc zkušeností než všichni inženýři co navrhovali CPU Fujitsu A64FX a inženýři v ARMu.

Mobilní telefony jsou trh se 410 miliardama USD (oproti serverům se 85 mld USD), takže si nemyslím že by ARM chtěl riskovat implementací SVE pokud by to nebylo výhodné. Ti kluci nejsou blbí a než něco takového vypustí do světa tak to proženou benchmarkama na virtuálním simulovaném CPU s SVE. Na tom si odladí nejen kompilátor a úpravy v CPU samotném, ale vidí i statistiky jestli se zmenšila binárka, efektivita CPU, zatížení cache....hned vidí jestli SVE se vyplatí oproti fixním vektorům nebo ne. ARM prostě má odvahu nasazovat radikálně výhodné věci i za cenu zahození zpětné kompatibility (původní SVE nejsou zpětně kompatibilní s původními fixními vektory ARM/NEON).

Stejně jako 64-bit ARMv8 je úplně jinak kodovaná, binárně nekompatibilní ISA a pro zpětnou kompatibilitu s 32-bit ARMv7 museli mít v CPU 2 dekodéry. ARM měl odvahu všechno staré zahodit a skokově se posunou dopředu na něco radikálně lepšího.

Zajímavá situace. Jsem zvědav jak zareaguje AMD. Přijme tohle nebo přijde s vlastní technologií.

Bude mit vektory 4096 bitů?

Když vy inženýrku, tak my nové kachličky...! :-)))

Já nejsem ten kdo vidí do kuchyně AMD na tohle odpoví jistě někdo jiný ne já. :-)

Jo a chybí mi tam slovo revoluční.

amde bude kopirovat intel. iné nevedia žebraci (:

To je otázka. Nevím ale jaké označení použít na Intel když nejsou schopni ani okopírovat AMD a konečně postavit produkt co by byl lepší.

Kdyby AMD kopírovalo Intel, tak už nás opravdu zachrání jen ty revoluční vektory a revoluční počet ALU.

Chlapi, musíte si uvedomiť, že je kopa ľudí čo dokáže tu Intel arch. a kopu menších jadier využiť a ten zastali koncept amd im už nešmakuje. Všetko neni len o pár old school ľuďoch z diit&ddword.cz čo si gratuluju ake je amd skvelé.

AMD skvělé rozhodně není a není ani ničí kamarád, vyjma peněz. Samozřejmě pokud někomu vyhovuje víc Intel, má možnost koupit jejich produkt. Je paráda mít možnost výběru :-)

Súhlasím. Inak s tým kopírovaním som si sice robil srandu, ale nema intel-amd dohodu o free zdieľaní x86 technológií ako inštrukčne sady? Najznámejší prípad čo poznám u intelu sú 64bit inštrukcie od amd, len tomu dal iné meno a amd zas preberá tie veci ako SSE, AVX... atď. Preto predpokladám aj prevzatie (skopčenie) tých nových APX amdčkom.