Oprava mikrokódu snížila výkon procesorů Intel Ice Lake a Tiger Lake. Jde o Move Elimination

36

Ne zrovna příjemná zpráva pro vlastníky 10nm procesorů Intel: jak Ice Lake, tak Tiger Lake mají chybu, jejíž oprava v mikrokódu lehce snižuje výkon. Nemělo by ale jí o bezpečnostní díru.

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-Hmobilní 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 CoveWillow 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
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 02
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.

Galerie: Odhalení procesorů Ice Lake a architektury Sunny Cove (Computex 2019)

Zdroje: Intel, Andreas Abel (1, 2)

Oprava mikrokódu snížila výkon procesorů Intel Ice Lake a Tiger Lake. Jde o Move Elimination
Ohodnoťte tento článek!
5 (100%) 17 hlasů

36 KOMENTÁŘE

      • Ale vůbec ne. Jen je vidět, kdo vlastní akcie AMD, a udržováním hype se stará o jejich zhodnocení. Mě jen mrzí, že jsem nezainvestoval před pár lety, kdy bylo AMD pár týdnů od krachu a akcie byly za babku. Teď už do toho vstupovat asi nemá cenu, AMD je teď topdog a nevím jak moc by se investice zhodnotila, jaký potenciál k růstu ještě má. Mě by teď přišlo dobré investovat do Intelu, ten už snad níž nemůže jít. Ale jak se znám, tak nakonec stejně nic nekoupím.

        • Investovat máš když je „krev v ulicích“ (např. v Covid panice 2020), ne když jsou akcie Intelu a akciové indexy obecně u svého maxima a amerika je těsně po rozdávání nových helicopter money…

  1. Jeden prastarý, ale stále dobrý, a evidentně stále platný:

    Motorola (pomalu a uvážlivě): Intele,….kolik….je…. dva …. plus …. dva??
    Intel (okamžitě vyhrkne): pět
    Motorola: to… je…. ale ….. špatně….!?
    Intel: alerychle!

    • To nechápete dobře – pokud Rocket Lake tímhle trpí, tak už je efekt teď zahrnutý v těch benchmarcích, které jsme viděli. Takže další snížení už nebude.

      Mimochodem zvýšení výkonu v novějších BIOSech se už částečně potvrdilo (i když samozřejmě není úplně jasné, jestli už ty změny nemohly do toho testu AnandTechu doputovat před jeho vydáním, ale spíš mi přijde, že ne). Zítra k tomu dám dohromady nějaký komntář 🙂

  2. Nejdřív mne napadalo, že starého psa novým kouskům nenaučíš. Ale je faktem, že i když mají u Intelu další chybu tak přece jenom je zlepšení v tom, že omezení rychlosti není tak drakonické jak tomu bylo v minulosti. Rád bych podobné zlepšení zaznamenal i ve výrobních procesech.

    • Faktem je, že Intel chyby okamžitě opravuje, a když si nikdo evidentně ničeho ani nevšimnul, tak to asi takový problém nebyl. No a pak tady máme AMD, které, po více než roce (možná dokonce 2?) oznámilo, že snad už v dubnu, s AGESA 1.2.0.2, opraví chybu s USB porty. Takže klasika. AMD nové kousky opravdu nenaučíš.

      • Jako AMD určitě není bez viny, ale evidentně jsi Intel fan, když nevidíš jak děravá byla a pořád je architektura Intelu – byly tu články snad každý týden o dalších a dalších chybách o kterých Intel věděl a řešil je prakticky až po uveřejnění (měl čas na opravu minimálně rok). Takže obě firmy mají máslo na hlavě, ale spílat jen jedné firmě moc fér není.

  3. Hezky clanek. Ovsem s malou chybkou ve vysvetleni move elimination. Naprosta vetsina CPU neumi do out-of-order zpracovani zahrnout pamet – tedy ze hodne fyzickych registru zabrani castejsimu pristupu k pameti. To je dost casty omyl a standardne to tak nefunguje. Jedine CPU, ktere tohle castecne umi, je AFAIK Zen2, ale Zen3 uz zase ne.

    • A ono něco takového je v článku napsáno?
      Já to, co je v článku napsáno pochopil tak, že když mám za sebou instrukce:
      MOV adresa v paměti, registr
      MOV registr, něco
      a registr je v obou případech stejný, tak ta druhá instrukce nemusí čekat, až je ta první instrukce dokončena, ale použije jiný virtuální registr.

      • Ta Move elimination by byl případ MOV registr,registr

        Teď teda doufám, že to chápu dobře, ale s tím, že přejmenování omezuje vylévání do paměti, jsem to myslel tak, že když jsou v kódu dvě jinak nezávislé sledy operací, kdy kvůli omezenému počtu architektonických registrů ty dva řetězy instrukcí jedou nad stejnými registry (ale datová závislost tam reálně není, je to prostoě proto, že registry došly), tak by jedna ta sekvence musela normálně čekat, až bude ta první hotová. Ale s přejmenováním registrů budou mít obě ten registr z svého pohledu pro sebe a CPU je bude moc provést paralelně.

        • To je spravne. Doufam, ze moc neslovickarim, ale nejak nevidim souvislost s vylevanim registru do pameti. Kdyz programatorovi dojdou registry, musi neco odlozit do pameti, coz se odborne jmenuje vylevani (register spilling), ale prejemenovani registru tomu nijak nezabrani. Jen spolecne s OOO engine pomuze kompenzovat latenci, pokud je to mozne (ale to je obecna vlastnost OOO i bez pametovych operaci). Ten zapis a nacteni do pameti/cache se musi „fyzicky“ provest vzdy. Jen u Zenu 2 to za urcitych okolnosti funguje trochu jinak. Tohle je celkem neintuitivni vec, proto si hodne lidi mysli, ze vic fyzickych registru pomuze snizit pristupy do pameti a na poctu architektonicjych registru zase tolik nezalezi. Opak je ale pravdou. Proto se pravidelne zvysuje pocet arch. registru (z 8 na 16 u x64 a 32 u AVX512).

            • Taky si nejsem uplne jisty, ale myslim, ze store-to-load forwarding umoznuje jen cist ze store bufferu s latenci nekolik taktu (Intel tohle zvlada o dost lip). Teoreticky je mozne, ze data zustavaji nejakou dobu v registrech jako spekulace, ale tezko rict, moc bych na to nesazel, protoze by to odhalily benchmarky. Mozna tohle umi prave ten Zen2.

  4. Já teda věci moc často nekomentuju, páč rozumím jenom regulárním výrazům. Ohledně Intelu nemám co dodat, ale trochu mě mrzí, že se stejnou měrou „neřeší“ problémy se stabilitou nových ZENů. Po letech stabilního soužití s OC 2600K jsem si na vánoce postavil nový PC s 5800X, Asus Dark Hero. Výkon super, jen jsem se zařadil do nemalé skupiny uživatelů s problémem nečekaných rebootů v idle. Nepíšu to sem proto, abych byl zaplaven radami nebo urážkami (obojího se mi dostalo požehnaně), ale jen abych vyjádřil svůj osobní názor – klidně bych oželel pár procent výkonu výměnou za stabilní běh. Snad nová AGESA 1.2.0.1 pomůže, když u ní (jako obvykle) uvádějí Improved stability…
    Tolik pro vtipálky s rychlým/špatným Intelem a pomalou/správnou Motorolou. V dnešní době bych tam se stejnou nadsázkou mohl přidat AMD, které by ani nedokončilo větu 🙂

        • za tou jednoduchostí je ale spousta let empirie. Chápu že jsi naštvaný, ale tohle se děje všude. Že Asus možná umí desky pro Intel neznamená, že je umí pro AMD.

          Vybral sis gamesnickou desku od patlalů z Asusu (oni jsou tedy dnes patlalové všude, ale jen u Asusu to ženou vždy na ostří nože), ale může za to AMD. 🤔

          edit: netvrdím, že AMD v tom nemá prsty, ale [zřejmě jsou|prokazatelně existují] desky, ve kterých ty Zen3 běhají spolehlivě, takže čistě procesorem to asi nebude.

          • Teď se zpronevěřím svým zásadám a naprosto zbytečně zareaguju – co konkrétně může empirik Tynyt označit na Dark Hero jako dohnané na ostří nože? Nejlépe i s odborným rozborem (nemusí být vlastní).
            Tím za sebe končím tuto offtopic odbočku a zase jen budu dál žasnout nad českými IT diskuzemi, všechna čest výjimkám.

            • LOL, chápu.. Takže TY máš problém, ale JÁ ti mám vysvětlovat, přičemž ty už dopředu VÍŠ a ŽASNEŠ nad kvalitou českých diskusí.

              Víš co, běž zpátky k regexpům, tam je to pro tebe ideální. Já si zase nechám svá empirická moudra pro sebe a pro ty, kdo o ně opravdu stojí.

    • Zdar, jaky mas zdroj? Mam stejnou desku, navic 5950X a zravou RTX 3900 a vypadky nastesti zadne, musim zaklepat. Zdroj Corsair AX1000. Slysel jsem o vypadcich se slabsim zdrojem, ale je to zalezitost spis spiku na graficke karte, pokud mas neco nabusenejsiho.

  5. Intel core s nVidiou zorganizujú súkromnú párty, pozvú aj v počítačovej brandži menej známu
    dvojku Ryzena s Radeonkou.
    Nálada je v plnom prúde, sovietske šampanské tečie potokem, čierny hrášek mizne na kilá,
    proste pařba jak sviňa. Zrazu kohosi napadne, čo tak si zasexovať, všetci s nadšením prijímajú
    a už aj idú na vec. Intel pojme nVidiu a šup do spálne vpravo, Ryzen schytí Radeonku a šup do
    spálne vľavo.
    Po dvoch hodinách nespútanej vášne a čísiel padajúcich jak v športke sa Intel s nVidiou rozhodnú
    pre krátku osviežujúcu fajčpauzu. Príjemne orgiami znavení čakajú v objatí na Ryzena s Radeonkou.
    Prejde hodina a po červených kremíkoch ani smrad, prejdú dve hodiny, stále nič….
    Po troch hodinách vtrhne do haly nasraná Radeonka a zapiští –
    „ tomu debilovi zas nefunguje usbpinďa „