Vlákno názorů k článku Čtyřicet let existence oslavované i nenáviděné platformy PC od dfxxfd - Ja si myslím, že by sa Microsoft, Intel...

Ja si myslím, že by sa Microsoft, Intel a AMD mali dohodnúť a ukončiť spätnú kompatibilitu a podporu pre 16 a 32 bitové inštrukcie a staré rozšírenia a nechať iba AMD64, AVX2 a novšie, napríkad AVX512. Časť kremíka by tým ušetrili a zároveň by sa zjednodučilo aj jadro operačného systému. Za 3 - 5 rokov by to v pohode zvládli. A procesory so spätnou PC kompatibilitou by mohli predávať, kým by bol o ne záujem. Prakticky by tým ukončili vývoj PC kompatibilných počítačov.

Apple v pohode zrušil podporu 32-bitových aplikácií a darí sa mu.

Tak na Skyrim a podobné 32b aplikácie môžu Intel a AMD ešte ďalších 20 rokov vyrábať poslednú generáciu kompatibilných procesorov, niečo ako core i7 15700 alebo Ryzen 7 10700. Veď Intel vraj ešte stále ponúka Itania.

Otázka je, kolik by se ušetřilo, zrovna AVX-512 potřebuje poměrně hodně plochy. Hodně taky zabírají cache, které s instrukční sadou přímo nesouvisí. Například 80486 mělo něco málo přes milion tranzistorů, dnešní CPU jednotky až desítky miliard, to je jako kapka v moři.

Kremík by sa ušetril na zjednodušení dekodéra inštrukcií a odstránení zastaralých módov. Je zbytočné udržiavať v procesoroch spätnú kompatibilitu, ktorú rozumne napísané aplikácie už dávno nepotrebujú.

64 bitové aplikácie samozrejme budú fungovať. Na spätnú kompatibilitu s 32 bitovými a 16 bitovými aplikáciami by sme už mohli zabudnúť, veď AMD64 inštrukcie boli predstavené v roku 2000.

Ten dekodér je vůbec magie, instrukční sada je tak slepená dohromady, že dekodér je spekulativní, hodně práce zahodí a nedá se už více paralelizovat - když vyšel Apple Silicon, vyšlo na Anandtechu pěkné porovnání instrukčních sad AMD64 a ARM64. Intel/AMD už z principu nemůžou ten dekodér udělat lépe, Apple M1 má tak vysoké IPC hlavně díky mnohem snadněji dekódovatelné instrukční sadě (v kombinace s efektivitou díky výrobnímu procesu je pak celkově rychlý a úsporný). Shrnuto a podtrženo, Intel/AMD nemají horší inženýry nebo výrazně horší technologii (AMD ostatně vyrábí z velké části tam, kde Apple), ale táhnou za sebou břímě historie. Apple na zpětnou kompatibilitu zvysoka kašle, proto se pak může chlubit.

Áno, na to som myslel. Pokiaľ ten procesor musí spracovávať aj 16 a 32 bitové inštrukcie, tak bude veľmi ťažké urýchliť dekodér inštrukcií. Apple už niekoľko rokov používa iba 64 bitové procesory a vidno to na rýchlosti a efektivite.

To by si příliš nepomohli. Bez ohledu na to, že je dneska už k ničemu, tak ta podpora pro real mode až tak moc nezabírá, pro 32-bit to nejspíš taky nebude takový rozdíl, vzhledem k omezenému počtu registrů i instrukcí a v zásadě poměrně obsáhlé dopředné kompatibilitě k dnešní x86_64. To, že se část instrukcí nepoužívá, část má nejspíš nějaký překryv a část se dá zakódovat kratší variantou s nějakými registry než jinými, nemá asi větší význam, kromě toho, že to mírně komplikuje kompilátor a dekódování v procesoru. 32-bit určitě neběží výrazně pomaleji než 64-bit, tak instrukční sada je v zásadě stejná (respektive jen rozšířená). U 16-bit si nejsem jistý, ale i kdyby se to emulovalo software, tak se asi nic tragického nestane (ostatně, svého času se musely opravovat knihovny pro Turbo Pascal, protože v době vývoje se nečekalo, že by procesor mohl běžet tak rychle).

Nicméně, ukončit by to asi šlo. Jak ukázal Apple a Rosetta 2, s rozumnou architekturou a defakto JIT se dá emulace udělat poměrně dobře udělat softwarově, s nepříliš výraznou ztrátou výkonu (i kdyby byla poloviční, tak to u zastaralých 32-bit aplikací nikoho nebude extra dráždit).

Problém x86 (a x86_64) je ale ta zpětná kompatibilita, která se stále drží na úrovni ISA. Když to navrhli na začátku, tak to nějak dávalo smysl, s omezeními, které byly dány dobou a cenou (i když, jak ukazují jiné příklady, šlo to určitě udělat líp). S osmi registry (spíše s bídou s šesti) a malou cache ten CISC dával v zásadě smysl, bo většina operací vyžadovala práci s pamětí. Měli slušnou code density, nízkou cenu atd. Dokonce bych jim ani nevyčítal ty segmenty - postupem to sice bylo peklo, ale původně asi počítali s tím, že všechny objekty budou v rámci 16-bitového prostoru a segmenty tak umožňovaly jednoduchou adresaci při omezení designu na 16-bitové registry. Jenže, časem se rozšiřovalo a ISA se hackovala, až do 64 bitů, kde velká část instrukcí vyžaduje nějaký prefix či dokonce víc, aby fungovala se správnými operandy. To celkem fungovalo u jednoduchého procesoru před 40-ti lety, ale u dnešních superscalar to už značně komplikuje instruction decoder. Ten sice opět nezabírá velkou část procesoru, ale schopnost číst instrukce paralelně v podstatě plýtvá energií, brzdí zbytek pipeline a dekódovat víc než několik kusů najednou je pro CPU sázka do loterie. Podobně je to s code density - většina původně designovaných instrukcí se defakto nepoužívá, bo CPU už má dost registrů, takže většina instrukcí je defakto v kategorii RISC. Navíc jsou zbytečně delší, protože velkou část ISA prostoru zabírají ty, které už nejsou využívané. Jako obvykle platí, že čím vyšší aplikační vrstva, tím lepší znalost má o tom, čeho chce dosáhnout a jaké jsou následky a vztahy s okolními komponentami, takže jsme zpátky v době, kdy je lepší optimalizaci udělat na softwarové úrovni než dělat šílené hacky a kontroly na úrovni CPU. V tomto směru byla Transmeta zcela slepá ulička .

Takže, x86 či x86_64 už nic nezachrání. Intel a AMD to držely dlouho kvůli know-how a patentům, které nikdo neměl, a samozřejmě obrovským investicím, které si mohli dovolit kvůli množství zákazníků. Ale jak to obvykle bývá, svět se časem srovná s tím, jak se technologie a postupy stanou dostupnější - teď máme ARM a dvě open-source architektury, které vznikly s minimem prostředků na univerzitách. Těžko soudit, možná se ARM a RISC-V dostanou časem do podobné situace, až jim třeba dojde prostor v jejich ISA a budou potřebovat rozšiřovat. V té chvíli možná bude opět dobré celou ISA zahodit a vytvořit zcela novou, na základě aktuálních požadavků (spíš si myslím, že se tak v dohledné době nestane, vzhledem k tomu, že ty požadavky jsou do velké míry dány možnostmi napsat na to software a tam se drasticky neposunujeme, s výjimkou různých masivně paralelních architektur apod). V každém případě jsme dneska už v jiné době a jsme schopni to řešit velice efektivně - ať už formou software emulace (respektive kombinace emulace a kompilace) nebo tím, že většina aplikačního SW běží na nějaké VM a nativní kód je obvykle open-source nebo dobře udržovaný a dostupný closed-source (pokud ne, tak je stále možná ta první varianta emulace, ale větší problém je stejně v nebezpečnosti toho software jako takového).

Paradoxně, odhaduju, že x86 (x86_64) definitivně pohřbí Intel. Ta architektura je za zenitem a na limitu, Intel je v ní v této chvíli pozadu a dostat se v ní zpátky na špičku by stálo extrémní peníze, navíc by to bylo Pyrrhovo vítězství, vzhledem k tomu, že ta špička x86_64 je pořád za současnými ARM CPU. IMHO současné plány Intelu (a nejspíš i AMD) směřují buď k ARM nebo spíš RISC-V (bo licence, ale zároveň je taky modernější), které nemají ty nesmyslné 40 let staré omezení a jsou tak lepší k rozvoji. Teoreticky by mohli navrhnout novou vlastní ISA, ale to by bylo obrovské riziko z hlediska podpory kompilátorů, OS, hardware vendorů atd. Se svým know-how budou schopni dotáhnout tu architekturu dál než aktuální svět a můžou pokračovat ve své nadvládě ve světě CPU. Nemají moc na výběr - buď se přizpůsobí evoluci nebo vymřou jako dinosauři. Navíc můžou zkusit využít nějaké své patenty a architekturu nadále vylepšit a blokovat zbytek světa. Což je špatná zpráva, ale z obchodního hlediska dává smysl...

Tento názor souzní s mým dlouhodobým výhledem. I nejmonstróznější x86 dekodéry zvládají jen 6 instrukcí paralelně a to jen někdy a i od těch jak Intel tak AMD ustoupili a dokáží dekódovat jen 4 instrukce z cache paralelně. Dohání to trace cache, která může injektovat až 6 RISC like instrukcí paralelně, ale její kapacita je maličká (většinou 64 entry) a uplatní se jen v těch nejtěsnějších smyčkách. Zkusit do RISC kódování převést celou L1 se ukázalo na Pentiu IV jako katastrofa, ono rozumně mapovat jesnobytové x86 instrukce, které pracují s pamětí a rozpadnou se ně tři RISC like a pak 14 bytové, které koncí na jedné RISC na sebe bez obrovského plýtvání kapacitou cache po instrukcích nejde a dělat to nějak dynamicky místo n-cestně asociativní cache s přímým indexování adresou asi moc nejde. Je jednodušší udělat nějaký překlad na SW úrovni. Takže sada x86 je na dekódování mrtvá nebo minimálně při požadavku na rozuměnou spotřebu.

Apple M1 dekodér na až osm instrukcí paralelně je proti tomu vlastně jednoduchá hračka. Na druhou stranu si myslím, že ARM udělal chybu s vypuštěním nějaké možnosti využít 16-bit aliasů (Thumb) v 64-bit režimu. Na RISC-V sice zabírá 16-kódování 3/4 codespace, ale dává možnost lepšího využití kapacit cache větší kódovou hustotou nebo alespoň dorovnání handicapu jednodušších adresových režimů proti ARM AArch64. Ty širší režimy indexace na ARMu jsou výhodou, ale odhaduji, že ve výsledku zaplacenou složitějším návrhem jednotek počítajících adresy (AGU na Zen, LAD, SAD na RISC-V). Takže si myslím že rozhodnutí RISC-V redukovat adresní režimy a počty vstupních a výstupních závislostí instrukcí minimílně není chyba. Předpokládám, že AArch64 již v codespace prostor na 16-bit aliasy bez přepínání režimu procesoru nemá, naopak ho pak plýtvá na klasické multimediální operace s pevnou šířkou operací, tedy NEON je vlastně se dvěma šířkami 64 a 128-bitů a tím zabírá ještě více codespace. AArch64 se problém snaží nyní řešit přidáním SVE (Scalable Vector Extension), ale celkově to je opět další redundance a komplexita navíc. RISC-V se svým RISC-V V vector extension si myslím, že je na tom lépe přitom bude dobře škálovat na různě výkonné implementace s různě širokými cestami skrz čip a i nejjednodušší smyčku s proměnným počtem průchodů půjde zakódovat s minimální zátěží na víc, že i pro případ, že bude zavolaná jen na dva průchody vyjde dobře.

Přitom skupinu multiplexorů, které teřeba na začátek dokáží dekódovat 32 byte z RISC-V L1 cache na 4 až 8 konstrukcí podle délky si na rozdíl od x86 dokáži představit a při správném využití kódování kompilátorem to může mít jen malou ztrátu proti M1. Když se podaří dekódovat 64 bytů, do 8 až 16 instrukcí tak ho předběhne.

Takže zatím vidím spíš důvody, proč je dlouhodobě RISC-V lepší volba. Zároveň pokud dostane ARM Nvidia, tak je možné, že zla, kterého se mi ve jménu nepodepsání jejich NDA dostalo napáchají ještě více a spolupráci ještě více lidem otráví.

Jinak letem světem jsem popovídal o přehledu od i4004 přes x86, M1 k RISC-V na letošním InstallFestu. Zatím odkaz do streamu https://youtu.be/Tjej9Vz_A0E?t=1542 . Kdo by chtěl hlubší přehled, tak nabízím prezentace a záznamy z našich Pokročilých architektur počítačů , bylo to původně i pro cizince i když letos, na rozdíl od několika předchozích běhů, nakonec žádný předmět nedokončil, ale zůstal jsem i tak u své CzEnglish, tak se předem omlouvám https://cw.fel.cvut.cz/wiki/courses/b4m35pap/lectures/start . Jinak kdo si potřebuje oživit základy, tak mohu nabídnout náš úvodní předmět https://cw.fel.cvut.cz/wiki/courses/b35apo/lectures/start pro prváky.

S pozdravem,

Pavel Píša

Moc díky za doplnění!

S touto myšlenkou jste tu příliš brzy. Vždyť i dnes je spousta 32bit-only aplikací, hlavně ve Windows světě (a existuje spousta 32bit ARMů pokud nejsme jen u x86).
Na druhou stranu, dovedu si představit, že by moderní x86 procesory měly třeba jedno dedikované 32-bit only jádro pro kompatibilitu a zbylých X jader s 64-bit odlehčenou instrukční sadou. I když teď nad tím při psaní komentáře uvažuji, nevím jak by to technicky fungovalo...

Jsem jenom laik, ale mam za to, ze obecne se vyplati mit strukturou stejna jadra, a naopak treba zpetnou kompatibilitu resit "polosoftwarove" (muze byt treba mikrokodem, nebo nejakym v CPU schovanym "trapem" ala x86 SMM; resp. presne takhle to mel myslim nejaky klon MIPSu aby obesel patenty). Uz zasadni problem je v tom, ze by OS musel vedet na jaka jadra schedulovat jake procesy.

„S touto myšlenkou jste tu příliš brzy. Vždyť i dnes je spousta 32bit-only aplikací, hlavně ve Windows světě [...]“

A některé jsou pro Windows svět malinko zásadní...

Sranda, kdo chce 64-bitové VS, musí na Mac :)

Nebo VS Code.

> dovedu si představit, že by moderní x86 procesory měly třeba jedno dedikované 32-bit only jádro pro kompatibilitu a zbylých X jader s 64-bit odlehčenou instrukční sadou

Tohle určitým způsobem existuje v ARM světě. Typický mobil má 4 velká a 4 malá jádra. Ta velká jsou 64bit only a ta malá jsou 32/64bit. OS pak spouští 32bit aplikace jen na těch malých. Výkonově je to ok, protože 32bit ARM aplikace byly dělány pro mobily s 4 takovými jádry, takže jedou na stejném výkonu jako tehdy. (Ta malá jádra jsou šíleně zastaralá a několikanásobně pomalejší než moderní malá jádra v Apple. Firma ARM má peníze jen na vývoj velkých jader - ta jsou taky lépe prezentovatelná. Ve světě mimo Apple se aspoň využije kompatibilita s 32bit aplikacemi.)