Život po x86 aneb kam dále s procesorovými architekturami? | Kapitola 3

ARM nebyl jediný

Asi nejvyšší magií je potom predikce skoků, protože moderní procesory používají zpracování instrukcí ve fázích (pipelining), kde špatná predikce skoků rozboří rozpracovanou kaskádu a vše se vrací zpět. Efektivita moderních procesorů roste se schopností odhadnout, kam se bude pokračovat po vykonání podmínky, na což jsou naštěstí různé fígle, například jak rozeznat cyklus, kde se typicky skáče na začátek cyklu.

Tyhle fóry ale začaly být dosažitelné relativně nedávno – a tak se po určitou dobu zdálo, že x86 prostě musí umřít na svoji vlastní složitost. A v oné době, což překvapivě byla už 80. léta, začala vznikat celá řada alternativních architektur, z nichž některé tu máme dodnes – a jiné prakticky vyhynuly. To, co tu máme dnes (a překvapivě to máme i uvnitř x86), je architektura RISC, tedy omezený instrukční set. Začalo se na něm dělat v kalifornském Berkeley v letech 1980–1984 a tato architektura se opírala o studie informatika Andrewa Tanenbauma z roku 1978, který dokázal, že je možné významně zmenšit instrukční sadu, aniž by to omezilo možnosti programů.

Idea RISC byla založena na tom, že bohatou ale poněkud ad hoc vytvořenou množinu strojových instrukcí nahradíme podstatně menším množstvím instrukcí, což nám ušetří komplexitu litografie na čipu. Menší počet prvků na čipu rovná se levnější výroba, menší rozměry čipu, menší množství vyzářeného tepla a lepší šance pro zvýšení provozních taktů – samá pozitiva! Kód pro RISC bude o něco delší, ale to až tak nevadí, paměť se bude neustále zvětšovat a zlevňovat, takže koho to zajímá?

Ideje RISCu stojí za úspěchem architektur ARM, ale opravdu uspěl jen a pouze ARM. Intel se pokoušel o vlastní RISC s procesorem Intel i960 (1988–2007) a AMD s jejich architekturou AMD 29k (1987–1995?). Co bylo špatně na těchto architekturách, netuším, nikdy jsem s nimi nepracoval, ale ve finále se objevily většinou v akcelerátorech a průmyslových řešeních. Do mainstreamu nepronikly – tipoval bych, že se snažily uspět v době, když se výkon x86 radikálně zvyšoval v podobě 486, Pentií a podobných procesorů. Ve finále tyto architektury úplně nezanikly, jejich vývojové týmy se podílely na „RISCiaci x86 procesorů“, ale zřejmě bohatství softwaru a prostor pro další optimalizaci architektur vedl k tomu, že jak Intel, tak i AMD se zaměřily na vytěžení x86. Pokud je mi známo, od těchto architektur nikdy nevznikla opravdu úsporná (low power) verze, tento prostor zůstal pro ARM a pro jeho procesory, které se v 90. letech prosazovaly jako StrongARM. 

Neznamená to, že by se nikdo nepokoušel o tvorbu nové architektury. Už v roce 1983 Josh Fisher z Univeristy of Yale navrhl koncept explicitního paralelismu, tedy toho, že programátor – anebo spíš překladač – dostane do ruky moc řídit přímo jednotlivé jednotky v procesoru. Jak jistě víte, procesor se skládá z velkého počtu výkonných jednotek – a zaměstnat je problém, takže Fisher navrhl, že kompilátor zjistí, které jednotky jsou nevyužité a pomocí speciálních instrukcí VLIW (Very Large Instruction Word) je dokáže zaměstnat.

Tato idea znamenala, že můžeme zvýšit účinnost běhu procesoru, aniž bychom vymýšleli nějakou pracnou řídící logiku, která jenom zabírá místo na litografii a pálí energii v pokusu vykoumat, co se dá spustit najednou – ne, tohle udělá jednou kompilátor a bude to.

Tento koncept vedl k sérii procesorů Transmeta Crusoe, což byl procesor vyvíjený od roku 1995 a do světa vržený v roce 2000. VLIW znamenalo, že bylo možné udělat relativně malý procesor, který měl mít schopnost jet opravdu efektivně – ale místo toho jel dost pomalu. Transmeta později uvedla další procesor, Transmeta Efficeon, který sice zlepšil svoje výkony zhruba dvojnásobně, ale pořád byl na úrovni Intelu Atom, takže se objevoval jenom v nejlevnějších laptopech.

V čem byl problém? Zase v paměti! Kompilátor může miliardkrát mudrovat nad tím, které jednotky jsou TEORETICKY volné, jenomže výpočet stojí a padá s dostupností dat – a kompilátor jednoduše neví, zda při běhu programu data budou, anebo nebudou po ruce, to je otázka toho, jestli náhodou jsou v cache, anebo se bude čekat na hlavní paměť. A každé takové čekání zastaví běh programu, protože pokud jste neskončili operaci, prostě nemůžete jet dál. Tohle nelze zlepšit, protože neexistuje ani teoretická možnost jak odhadnout, jestli data v cache budou, anebo nebudou – to můžete maximálně zlepšit tím, že tu cache uděláte opravdu velikou.