Vlákno názorů k článku Modlitba pro Intel: trápící se gigant a jeho radikální řez od Tom04 - Podle mě nepadla jedna důležitá věc a to...
-
Podle mě nepadla jedna důležitá věc a to skomírající x86 architektura. Nebude to podle mě dlouho trvat a majoritu i v počítačích a server bude mít ARM. Důvod proč není konkurence v procesorech je uzavřenost týhle architektury. Nikdo kromě AMD a Intelu nemá šanci cokoliv na tom vydat.
To se s ARMem mění. Apple, Qualcomm a přijdou další.
Do budoucne doufejme i RISC-V.
Na duruhou stranu Intel je právě výjemčný tím že má vlastní výrobu čipů, tzn je to pro USA hodně strategická firma u které se podle mě nestane, že by ji nechali padnout. To to radši nenápadně zasanujou z veřejnýho rozpočtu. Co si ale dokážu představit je, že jí rozseknou na dvě jako AMD. Výroba a návrh jako AMD s Global Foundaries a podporovat budou jenom výrobu. -
U out-of-order procesoru je instrukční sada nedůležitá a nemá prakticky žádný vliv na výkon. Vždycky tam musí být překlad na interní kroky a vytvoření virtuálních registrů. Velikost binárek má dneska také zanedbatelný vliv vzhledem k velikostem cache, na to aby měly instrukční sady, které produkují menší nějakou výhodu.
Výkon a spotřeba jsou dneska ovlivněny jenom schopnostmi těch mágů, co navrhují architekturu a použitém procesu. -
Ano s runtime překladem lze udělat divy. Do teď to díky extrémním zkušenostem v uncore, sběrnicích paměťových řadičích a optimalizacím v kompilátorech a obecně návrhu SW generacemi nejlepších programátorů šlo pro výkonné procesory do serverů a notebooků udržet. Naopak již před deseti lety snaha přijít znova s 80186 do těch nejmenších embedded zcela selhala na spotřebě a složitosti. To se stalo již předtím na mobilech a tabletech a dnes se to děje v oblasti notebooků (Apple M1+).
Ale i v těch výkonných serverech drahý překlad instrukcí spotřebovává energii a zpomaluje. Pokus o velkou cache překladů na Pentium IV selhal. Překlad na ještě větším na Transmeta Crusoe také. Nelze tedy celý kritický blok programu přeložit a jet třeba z tracecache. Je nutné uvažovat i o tom, že kritická část kódu je větší. Dekódování instrukcí s bytovou granularitou od jednoho do 12 byte je katastrofa a tak Intel sice byl z malé trase cache schopný brát až šest instrukcí na cyklus, ale z hlavní L1I cache jen čtyři a i to s podporou kompilátoru, například dva skoky v zarovnaných 32-bitech jsou asi stále smrt. Není kam dát v cache metadata. Od Sunny Cove pak nabírá z L1I až pět instrukcí, ale ta logika tam musí být brutální, proti tomu M1 vezme 32 bytů a má osm instrukcí bez starostí. Takže i na méně stupňů a tím i s menší latencí při skoku mimo tarcecache atd... Přitom ARM instrukce jsou tříoperandové, je dost regsitrů, v 64-bitech 31 a pre a post inkrementy při adresování. Intel přidal APX REX2, aby tu registry získal, ale kódování je tragédie.
Jak Intel tak RISC-V se upnuli na multimédia, kde jim SIMD pevné délky na algoritmy sedělo dobře. Ale na obecné výpočty je start a konec smyček tragédie. To lidi od RISC-V říkali rovnou a dívali se u svého V rozšíření směrem k vektorovým procesorům Seymoura Craye. ARM jim zavedením SVE dal za pravdu. Jen to zbytečné vyplýtvaní instrukčního codespace již nelze napravit. RISC-V může kombinovat Compressed (16-bit) a standard 32-bit kódování instrukcí a tím často i ty pre a post inkrementy ARMu zvládnout ve shodných 32-bitech a zároveň má již ty instrukce téměř 1:1 s uOPs za dekodérem. Přitom makra pro zkrácení některých sekvencí také zavedli, viz cm.push, cm.pop, cm.popret, cm.popretz, cm.mvsa01, cm.mva01s. Přitom jsou tyto instrukce tvrdě omezené na idempotent memory. U RAMu tím, že ldm neomezil jen na hlavní paměť, tak roky lezla i u safety procesorů errata. U AArch 64 dovolil jen páry.
Obecně, myslím si, že stále přednáška A New Golden Age for Computer Architecture platí.
Zároveň na AI a další to bez Domain Specific Archietcture rozšíření nejde. Takže rigidní x86 s vyčerpaným kódovým prostorem v snesitelně dlouze kódovaných instrukcích je na konci sil a již současné kódování je i na spotřebu i pro velké systémy těžko udržitelné.
-
Jinak i přes bolístky jako GhostWrite v současných pokusech o výkonový RISC-V jde vývoj dopředu. Pro naše studenty Pokročilých architektur počítačů již můžeme nabídnout od RISC-V International na základě mých aktivit dodaný jeden ze dvou Milk-V Pioneer boxů - 64x T-Head C920 jádro na SOPHON SG2042 čipu, 128 GB RAM, 1 TB NVME a ARM grafika v PCIe 4 x16.
Fotka a trochu obskurní experiment na osahání zde i s trochou nostalgie.
-
V principu by měl Risc-V compressed ISA trpět stejným problémem jako Intel x86_64, akorát tedy dvakrát menším (a samozřejmě většina instrukcí se bude skládat maximálně ze 2, občas 3 kusů). IMHO když už, tak měli použít spíš něco jako self-correcting UTF-8 - tedy aby bylo jasně poznat, zda je instrukce pokračováním, bez toho, aby znali předchozí část. Cena by byla nízká (třeba jedna hodnota ze čtyř), ale vyhli by se chaosu s nejasným dekódováním.
aarch32 compressed encoding uměl taky a u aarch64 jej zcela zahodili, protože byl nejspíš brzdou.
To, že se o Risc-V říká, že byl tak dobře navržený, že je tu už mnoho let, nemusí být vůbec validní. Aarch64 navrhli úplně nově, na základě aktulních znalostí a je úplně někde jinde. Když třeba vezmu, jak je navrženo kódování immediate pro bitové operace, tak aarch64 to vyřešil geniálně, zatímco Risc-V musí typicky nahrávat jednoduchou masku z paměti nebo přes dvě load instrukce a potom teprve porovnávat.
iMHO půjde Intel podobnou cestou - Risc-V už zkoumali, proprietární aarch64 se jim nejspíš nechce (i když taky už byly signály, že se tomu nebrání). Ale jak se ukazuje, vytvořit úplně novou architekturu dneska už zdaleka není tolik práce, když to bude potřeba. A může tím zahodit celou historii, včetně zbytečně striktního memory ordering.
-
Spíš si myslím, že "self-correcting UTF-8" je plýtváním codespace. Pokud vezmu třeba 32 byte pro 8 dekodérů, tak za podmínky, že vím, na které šestnáctici bitů začínám (ukazuje PC) potřebuji 16 určit jestli jsou u každé 16-tice nejnižší dva bity nula a pak mít logiku, která těch 16 signálů zpracuje a podle ní přeřadí správně 16 nebo 32 bitů na osm dekodérů. Ano, je to komplikovanější než jednoznačná korespondence u AArch64, ale proti nutnosti posouvat bloky po bytech o libovolné délky je to o řády méně muxů. Zatím 48-bitové kódování nebudu počítat.
Thumb i Thum2 u AArch32 je mnohem méně mocný, neboť procesor se musí do režimu přepnout skokem a pak na dekódování 32-instrukcí opět přepnout skokem, komplikace s nejnižším bytem skokové adresy atd. tedy přepnutí je tak dlouhé, že se na jednotlivé instrukce nevyplatí. Přitom Thumb pak vede na jen dvouoperandové instrukce a snadno přístupný jen subset registrů. Na RISC-V pak může kompilátor instrukci od instrukce zvažovat, jestli raději 3 operandy a trochu delší kód nebo kratší kdy jeden vstup bude změněný. Na výkonné procesory to není u AArch64 takový problém, ale trochu se plýtvá cache, pokud je v původním kódování instrukcí. Na embeded kde stále růst kapacity Flash odpovídá ceně spíš lineárně než u velkých systému, kde je závislost SDRAM spíše logaritmická, tak menší hustota kódu AArch64 vyřazuje a musím používat jinou architekturu Cortex-M. RISC-V obsáhne vše. Ano, compressed dekodér je určitá komplexita, není povinný a celkově se to podle me vyplatí.
Co se týče immediate a post/pre inkrementů atd, tak flexible second operand na ARM 32 kódování měl velký přínos, ale pro komplexitu ho z AArch64 vypustili a je tam jen 12 bitů a méně immediate a jen s možností lsl 12 nebo o velikost operandu. Takže se komplexnosti vzdali, krátce zmíněno v mé přehledové přednášce pro prváky PDF/Video.
Jinak pokud Intel nepřijde s něčím v kódování výrazně chytřejším než RISC-V, tak by se mu měla komunita vzbouřit. Času promarněného na souboje se segment offset, protected bez stránkování. PAE, příšerné kódování atd. již promrhal příliš mnoho. AMD to trochu zkorigovalo při přechodu na x86_64, ale zase se na to lepilo a REX2 je již zoufalost. Moc jsem při zavedení AMD64 doufal, že po letech AMD řekne a teď zapněte tento bit v CRx a nebo použijte tento mikrokód a máte k dispozici i od prvního našeho 64-bit čipu alternativní kódování instrukcí, které nepotřebuje REX a prefixy. Třeba něco jako Am29000, který měli vyvinutý již v roce 1985. Ale asi to tam opravdu neměli. Na správu jsem si představoval, že by to nabízelo třeba něco jako PAL od DEC Alpha. Případně by to bylo přímo v těch microcode instrukcích...
Jinak si představuji, jak v AMD museli ti s představivostí skřípat zuby, když místo svých elegantních architektur, na které ale běžní uživatelé přejít nechtěli, museli dělat na x86 prasárně.
-
Na toto musím reagovat jako někdo kdo píše AVX-512 pro obživu.
AVX-512 (tedy 128-bit, 256-bit, a 512-bit granularita) je zatím to nejlepší pro co jsem vyvíjel a podle mě ARM SVE i RISC-V V jdou cestou k nepoužitelnosti.
Co je zajímavé na AVX-512 (a obecně SIMD s fixní délkou registrů) je to, že SIMD se dá použít i na věci, které nejsou pole, a dá se počítat s velikostí vektoru. Takže třeba je možné navrhnout algoritmus pro 256-bit SIMD, nebo 512-bit SIMD, který bude dělat kompresi / dekompresi, nebo dekódovat nějaké binární data, atd... U kodeků se bude počítat s tím, že se napíše SIMD algoritmus pro dekódování nějakého tile (třeba 8x8, 16x16, atd...). Ale to není všechno, máš strukturu co má 64 bytes? 2 instrukce ji zkopůrujou.
Toto je úplně jiná kategorie problémů než udělat SIMD "strlen()" nebo zpracování nějakých dat v poli (časté přiklady pro SVE), atd... A AMD nám ukazuje, že AVX-512 je jediná budoucnost x86, protože decode je problém, ale když jsou široké registry, tak decode není až takový problém vzhledem k tomu, kolik dat vhodně navržený kód zpracuje.
Další problém SVE a RISC-V V je ten, že se pro to nedají udělat abstrakce (třeba v C++) tak jak pro kód, kde člověk zná délku registru. Takže člověk musí používat stejné intrinsics tak jak specifikuje ta architektura, což nikdy nebylo něco, co bych chtěl používat napřímo.
Je zajímavé, že třeba čínský Loongarch touto cestou nejde - místo "variable vector width) přidali 256-bit SIMD a to staví tu architekturu do pozice ~AVX2.
-
> To se s ARMem mění. Apple, Qualcomm a přijdou další.
To nie je tak celkom pravda. Aktuálne beží súdny spor medzi ARM a Qualcomm, kvôli tomu, že Qualcomm si dovolil vo svojom aktuálnom top modeli (Snapdragon X Elite) použiť svoje vlastné (resp. získané akvizíciou) jadrá a nelicencuje (a teda ARM-u neplatí) aj za Cortex, ale iba za ISA.
Takžše ARM sa snaží, aby zabil presne to "a přujdou další".
-
"pro USA hodně strategická firma"
Pro USA může, ale ten bod kdy se kvůli dluhům a hromadou pýchy zastaví svět... dost brzo blíží... takže půjčka Intelu je vlastně z další půjčky, která se vlastně nesplácí...
Je to dnes pro Čínu, pro umírající USA to za chvilku může být zcela jedno...A AMD a Global je kapitola sama o sobě... tam toho bylo... a je jen zázrak, že AMD to přežila...
-
Taky většina firem neumí dělat vlastní jádra CPU (a GPU). V x86 aspoň AMD nabízí svoje jádra v rámci semi-custom divize (PS, Xbox, Steam Deck, ...). Intel nenabízí nic.
Na druhé straně, pokud nepotřebujete maximální single-thread výkon, tak si můžete za babku licencovat Cortexy (běžné SoC, starší serverové ARMy) a nově i Nuvia (novější Gravitony od Amazonu, ...).
> Intel rad umozni vyuzit jejich patenty na x86 a AMD zase rado na x64.
Nevím, jestli tohle dnes platí, ale dřív neplatilo a možná tím Intel zabil konkurenci, která by mohla x86 pomoct. Např. jádra NVidia Denver měla umět i x86, ale nezískali licenci.
12. 8. 2024, 14:20 editováno autorem komentáře
