Vlákno názorů k článku Velké změny pro procesory x86. APX odstraňuje limity legacy instrukcí, přebírá i nápady ARMu od CCc - A ty 2048 bit vektory budou ci nebudou?...
-
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.
-
"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 ;-)
-
Boha. Psal jsem že zákazník platí 400 EUR za hodinu mojí práce, myšleno jiné firmě co ten projekt realizuje, a ta si najímá jiné firmy včetně naší co dodává tu část za 500 mega Kč. Když já jsem předpokládal, že každý ví že takové velké projekty dělají firmy a ne jednotlivci. Neuvědomil jsem si že redaktor co nic užitečného v práci nevytváří prostě nemůže vědět co je to skutečná práce a jak fungují velké projekty, moje chyba. Musel jsem si rejpnout :) Pointa nebyla chlubení, ale pokus o zamyšlení, že když něčí člověkohodina stojí 400 EUR tak to asi nebude úplnej polodement. Mimochodem zákazník má mezi fabrikama 12 soukromých letišť, a provozuje 17 vlastních letadel, čtyři 737, docela sranda.
Sem píšu jen pro zábavu když máme v práci čas, protože pokládám za prospěšné ty vaše prázdné kedlubny edukovat, ikdyž se vám to nelíbí. Olšan si vás nasrat pravdou nemůže, protože by dostal padáka, že jo. Navíc na to nemá ani znalosti, jak kodování ISA, strojáku, assembleru a C/C++, takže dělá co může. Není redaktor jako redaktor, když člověk vezme třeba Frumusamu z Anandtechu, to je redaktor co dá do SPEC benchmarku countery a dokáží spočítat statistiku o počtu větvení atd. dokáže spustit mikrobenchmarky a tak zjistit kolik ALU a FPU jednotek má jaké funkce v CPU, velikost ROB atd. Tohle od Olšana nikdy neuvidíme, přitom ego má 5x větší než Frumusamu (ten teď maká v Quacomu na těch nových Nuvia CPU).
Alespoň vás naseru 2048-bit SVE vektorama a tím váš mozek donutím o tom přemýšlet ať chcete nebo ne. Těm chytřejším to časem docvakne.
-
Neumětelové ve firmách samozřejmě jsou, ale ti jsou schovaní někde v kanclu. Lidi co musí sednou na letadlo a řešit přímo u zákazníka problémy se zařízením za 500 mega, kde jedna chyba = poškození a oprava třeba za 50 mega v lepším případě, v horším úmrtí 10 lidí a vězení, tak tady prostor pro neumětely opravdu není. Proto si taky firma za mou práci účtuje u zákazníka sazbu 400 EUR/h.
Jedna z věcí co se člověk časem naučí je, že nýmandi se časem zesměšní sami. Stejně jako Olšan se zesměšnil když se smál ALU jednotkám, protože neměl vůbec ponětí jak CPU pracuje. Teď když se dovzdělal tak už se ALU jednotkám nesměje a radši šoupe nohama aby někdo nevytáhl jeho starší posty.
Stejně tak když Olšan ještě minulý měsíc tvrdil, že ISA nemá vliv na spotřebu a málo registrů oproti ARMu vůbec nejsou problém protože fyzických má CPU hafo.... buch Intel uvádí nové APX co řeší efektivitu a zvyšuje počet registrů,což Intel sám zdůvodnil snižováním spotřeby CPU. To je fakt sranda. Stačí chvilku počkat a nýmandi se zesměšní sami i těma SVE 2048-bit vektorama nebo SME maticovýma instrukcema (brzy vyjde nový ARM Fujitsu A64FX na 3nm se SME a opět ARM CPU bude drtit GPU+podavač dat x86).
Ale buďme tolerantní. Chytrých a schopných lidí je málo a ti nepracují jako redaktoři. No a ti nechytří se rádi shlukují a přitakávají si, to už tak příroda zařídila. Je to třeba brát s nadhledem.
-
"Stejně jako Olšan se zesměšnil když se smál ALU jednotkám, protože neměl vůbec ponětí jak CPU pracuje. Teď když se dovzdělal tak už se ALU jednotkám nesměje a radši šoupe nohama aby někdo nevytáhl jeho starší posty."
Nevím teda kde jsem se smál ALU jednotkám (asi nejspíš vaše interpretace), ale možná si vzpomeňte, jak jste tu vypotil, že branch jednotka je pro vás totéž, co ALU.
-
Divím se, že na vás pan Olšan vůbec reaguje. Asi to tu má fakt rád.
Osobně pana Olšana považuji za jednoho z nejlepších českých IT redaktorů, sedí mi jeho pokora a způsob, jakým do článků doplňuje své názory.
Jak je vidět, ne všichni to tak ale vidí.Dejte vědět, až vyjde nějaký článek od vás, rád si ho přečtu.
-
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í.
-
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.
-
Můžu od vás dostat odpověď, jestli teda v SIMD něco programujete vy? Jen přes C nebo podobný kód (tj. necháváte vektorizaci na kompilátoru), nebo intrinsics, ASM? Jaká je povaha/určení toho kódu? Nechci vědět nic indentifikovatelného, jméno firmy nebo produktu, ale charakterizovat by se to nějak obecně mělo dát.
Protože když se já jdu zeptat na názor lidí, co fakt SIMD kód píšou, tak mimochodem něco podobného jsem taky slyšel. A takoví lidi na druhou stranu obvykle mluví trochu jiným stylem než jsou ty vaše příspěvky...
P.S. To, že výrobce procesorů něco navrhne a úplně se s tím netrefí do potřeb reálného softwaru, je úplně běžné, zas tak snadná práce tenhle obor není, lidi nejsou vševědoucí. Nebo se často projeví třeba ten faktor, že jedna koncepce se hodí pro A, ale méně pro B a firma se rozhoduje podle A a B zanedbá... Nebo firma vidí při návrhu velmi dobře, že jsou faktory A a B, ale musí si zvolit koncepci, kdy jedna vychází dobře pro A ale hůř pro B, kdežto druhá naopak, a je to jednoduše řečeno dilema, takže ať se rozhodne jak bude chtít, vždy to z jednoho pohledu bude vypadat špatně...
2. 8. 2023, 20:33 editováno autorem komentáře
Návody a tipy
23. 10. 2024
| online
31. 7. 2024
| online
6. 7. 2024
| online
