Než vyšly procesory Ryzen s architekturou Zen 3, asi se obecně čekalo spíš, že AMD nedosáhne na IPC (tedy výkon na 1 MHz) procesorů Intel Tiger Lake a bude tím mít nižší jednovláknový výkon. Nakonec je to zdá se překvapivě vyrovnané (i když teprv uvidíme, jak dopadnou Rocket Lake, Tiger Lake-H a mobilní Zen 3 od AMD).
Tomuto vyrovnanému souboji (nebo řekněme vyrovnanějšímu pro AMD, než se čekalo) možná trošku pomáhá i to, že nové „post-Skylake“ procesorové architektury Intelu teď utrpěly určité zpomalení. V jádrech Sunny Cove a Willow Cove, tedy CPU architekturách 10nm čipů Ice Lake a Tiger Lake, totiž byla nalezena chyba, kvůli které Intel musel aktualizací mikrokódu dostavit jednu z funkcí procesoru. A to pravděpodobně vede k nějakému snížení IPC (a tím i celkového výkonu). Naštěstí asi nevelkému, i vzhledem k tomu, že to prošumělo dost bez povšimnutí.
Tato chyba byla Intelem zadokumentována jako erratum ICL065 a není asi úplně čerstvá – opravné mikrokódy byly distribuovány nejpozději loni v listopadu (a možná ještě dřív, o tom za chvíli), ale stalo se to zřejmě bez velké pozornosti. Nyní ale bylo výzkumníkem Andreasem Abelem upozorněno na to, že tato oprava vypíná u Ice Lake tzv. funkci Move Elimination.
Erratum ICL065 říká, že ve vzácných případech může při eliminaci operací přesunu dat mezi registry (Move Elimination) dojít k tomu, že se procesor zblázní – dojde k tzv. nepředvídatelnému chování, což bývá typicky pád nebo zamrznutí. Nejedná se tedy o bezpečnostní díru, ale o chybu ovlivňující stabilitu, jaké se bohužel občas vyskytnou. Dokumentace mluví o tom, že se problém dá obejít pomocí BIOSu, což znamená právě asi aktualizaci mikrokódu CPU, která může být zabalená do BIOSu.
Erratum procesorů Ice Lake, kvůli němuž byla deaktivována schopnost Move Elimination (Zdroj: Intel)Co je Move Elimination
Andreas Abel přišel na to, že po této aktualizaci procesor Ice Lake Move Elimination asi úplně přestane provádět, což se dá ověřit speciálními mikrobenchmarky (podrobnosti najdete zde, máte-li zájem). O co jde? Move Elimination využívá to, že dnešní procesory nemají napevno zadrátované architektonické registry. Místo toho mají tzv. fyzický soubor registrů, v němž jsou uložené hodnoty a procesor pracuje s „odkazy“. S takto implementovanými registry je možná jedna optimalizace. Přesuny dat mezi registry totiž nemusí reálně přehazovat data. Pokud instrukce například přesouvá data z R8 do R9, stačí procesoru, když si poznačí, že stávající hodnotu ve fyzickém souboru registrů nyní má chápat jako obsah registru R9 – změní se tedy jen odkaz, ne fyzická „poloha dat“. Toto mimochodem má šetřit spotřebu a přeneseně tím zlepšovat výkon.
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove. Při použití Move Elimination se instrukce přesouvající data mezi registry provedou v ranné fázi pipeline, ještě než dorazí do ALU (Zdroj: Intel)A protože je to tak jednoduché, nemusí tuto operaci vlastně ani provádět výpočetní jednotky procesoru. Out of Order procesory totiž již dávno provádějí tzv. přejmenování registrů, kdy interně abstrahují registry od jejich architektonických jmen, aby mohly pracovat s vyšším počtem registrů než je například 16 dostupných u x86-64. Díky tomu se skryjí některé konflikty a výpočty se urychlí, protože není třeba čekat na „vylévání“ dat z registrů do RAM a jejich znovunačítání.
Když má procesor fyzický soubor registrů s popisovaným systémem odkazování, je velmi snadné místo instrukce MOV prostě během fáze přejmenování registrů prohodit odkazy, čímž je instrukce vyřízená. Toto se právě jmenuje Move Elimination. Operace pořád proběhne, ale vyřídí se v pipeline procesoru ještě předtím, než by měla dorazit do výpočetních jednotek. Ty se díky tomu nezaměstnají prováděním instrukce MOV a mohou dělat něco jiného.
Dopad na výkon je asi zanedbatelný, nastal ale i u Tiger Lake
V Ice Lake ale Intel nalezl nějakou logickou chybu, kvůli které zřejmě procesor může při Move Elimination udělat špatně nebo jinak někde něco pokazit. Zřejmě jde o velmi vzácný případ daný neobvyklou souhrou faktorů, jinak by to bylo odhaleno mnohem dříve a byla by pozorována nestabilita procesorů. Ale závažnost byla asi i tak dostatečná na to, aby tato chyba nebyla ponechána bez opravy.
U Ice Lake byla proto Move Elimination na podzim(či dříve) vypnutá. To znamená, že instrukce MOV přesouvající data mezi registry teď zase budou zpracovávat manuálně výpočetní jednotky a přidá jim to něco práce. Díky paralelismu v procesoru, který by často měl mít pro operaci nějakou volnou jednotku, by to obvykle neměla být velká přítěž. Vypnutá eliminace se také týká jen obecných registrů, ne SIMD registrů pro instrukce SSEx, AVX a AVX-512. Tam funguje i po aktualizaci.
Dobrá zpráva je, že ačkoliv toto má nějaký měřitelný dopad na výkon, měl by být hodně malý – proto si asi také věci nikdo hned v listopadu nevšiml a nejsou vidět stížnosti na zpomalení. Ti, kdo o tomto erratum informovali nebo ho testovali, měření rychlosti před a po aplikaci mikrokódu nikde neuvádějí, ale podle odhadu by zřejmě průměrné zpomalení nemělo být víc než zhruba nějaké jedno procento – někdy možná lehce nad, často asi i pod jedním procentem.
Chyba a oprava je tu možná již od jara?
Je tu ovšem možnost, že tento objev nefungující Move Elimination je ve skutečnosti už trošku starší regrese výkonu, ač se na ni asi trošku zapomnělo a teď se o ní mluví znovu. Podobná aktualizace mikrokódu snižující výkon právě procesorů Ice Lake cca o procento až pár procent totiž vyšla loni na jaře, psali jsme o ní a web Phoronix tehdy pokles výkonu změřil:
Tip: Intel vydal nové mikrokódy CPU. Oprava neznámé chyby zdá se zpomalí jádro Ice Lake
Tehdy scházela informace, z jakého důvodu byl výkon snížen. Závada na mechanismu Move Elimination je tedy možná opožděné vysvětlení. V takovém případě je to tedy tak, že se nyní znovu bavíme o stejné chybě. To je dobrá zpráva, protože se tím pádem také bavíme o tomtéž již proběhnuvším zpomalení a není to tak, že by nyní přicházelo další, aby se s předchozím hezky nakumulovalo. Nicméně, úplně 100% to staré bezcenné noviny nejsou.
Špatná zpráva totiž je, že následně byla potvrzená postiženost tímto erratum ICL065 nejen v procesorech Ice Lake, ale i i v novějším Tiger Lake. I u něj je podle mikrobenchmarků Move Elimination na obecných registrech vypnutá (není jasné, zda hned od vydání, nebo aktualizace mikrokódu také vyšla až po něm). Ač jsme tedy loni o chybě mluvili jako o regresi výkonu na architektuře Ice Lake, toto znamená, že ji Tiger Lake zdědilo a Intel ji nestihl před jeho vydáním hardwarově opravit. Bohužel tu tedy teď máme sekundární zprávu, že stejný problém/propad výkonu má i aktuální 10nm generace.
I Rocket Lake?
Je dokonce možné, že byla chyba při portování na 14nm proces přenesena i do přicházejících desktopových procesorů Rocket Lake, kterým by tím pádem také trošku poškodila IPC. Opět, dopad je téměř zanedbatelný (pokud je ICL065 ten starý problém z loňska, pak asi onen test Phoronixu ukazuje, o co procesory Rocket přichází). Možná, že by to mohlo být částečné vysvětlení toho, proč nakonec Rocket Lake v benchmarcích nejsou proti Zenu 3 tak silné, jak se čekalo.
Galerie: Test Phoronixu ukazující propad výkonu procesoru Intel Ice Lake s mikrokódem 0x78
Pokud některý z postižených procesorů vlastníte, asi není třeba se opravou nějak rozčilovat. Zhoršení výkonu o pár procent by reálně nikde nemělo být na obtíž. Pokud ovšem nesnesete toto pomyšlení, můžete alespoň v případě Ice Lake nahrát starší BIOS z před listopadu, který ještě nebude obsahovat opravný mikrokód. Ztracený výkon tím získáte navíc, ovšem za cenu teoretického rizika, že někdy na onu vzácnou nestabilitu narazíte. Podle Travise Downse je Move Elimination stále funkční ještě u verze mikrokódu 0x70.
Ideální by samozřejmě bylo, pokud by křemík tuto chybu neměl, ale u dnešních komplexních CPU není možné docílit úplné bezchybnosti. Kombinace všech možných stavů a faktorů v různých situacích nelze předem otestovat, takže je nevyhnutelné, že některé chyby v návrhu zůstanou a jsou odhalené až v hotových čipech. Takových errata mívají dnes CPU i přes sto a jsou něčím, s nímž se člověk jednoduše musí smířit.
Intel pravděpodobně chybu odstraní v některé z příštích architektur (možná Alder Lake, pokud ne již v Rocket Lake), takže postih na IPC, který teď vznikl a lehce pomůže konkurenčnímu AMD, bude u budoucích jader získán zpět.
