Rozbor CPU architektury Intel Gracemont: „Malá jádra“ Alder Lake jsou silnější, než čekáte

59

Přinášíme detailní rozbor malého jádra v procesorech Alder Lake. Čekáte, že je úsporné a nevýkonné? Ve skutečnosti je ale architektura Gracemont pořád hodně rychlé jádro, které bychom vedle něčeho jiného než Golden Cove normálně označili za velké…

Intel teď odhalil architekturu svých nejnovějších procesorů Alder Lake. Tentokrát jsou to ale architektury dvě. Alder Lake je hybridní a vedle „velkých“ jader pro jednovláknový výkon má další „malá“ jádra Gracemont. Ta ale nejsou jen do počtu či pro úsporu energie v nečinnosti jako u ARMů v mobilech, naopak se významně podílí na celkovém výkonu. Jejich architektura je vlastně sama celkem velká a teď se na ní detailně podíváme.

Předchozí
Následující

Gracemont: „malá“(?) architektura silná už jako Skylake

Gracemont je jádro, která podle Intelu bylo navrženo tak, aby mělo při co možná nejmenší ploše co možná nejvyšší výkon a díky tomu se s ním dalo dosáhnout dobrého škálování monohovláknového výkonu. Jádro by mělo mít výkon až někde okolo architektury Skylake – tedy aspoň pokud by jejich frekvence byly stejné – ale nižší spotřebu.

Cíl bylo, aby Gracemont měl vyšší IPC než Skylake, ale jádro je navržené na běh na nízkých napětích, takže spotřeba má prý být „zlomková“. Dokonce by prý mělo jít o x86 jádro s nejvyšší energetickou účinností (tedy nejlepším poměrem výkon/watt) na světě.

Poměrně významný rozdíl ale je, že jde jen o jádro zpracovávající jedno vlákno. Chybí technologie HT. Zda ji Intel v tomto druhu jádra nechce mít (kvůli komplexitě, spotřebě, tranzistorech navíc), nebo se jen ještě nedostal k tomu, aby ji do E-Core přidal a v budoucnu se zde také objeví, to nevíme. HT benefituje z širokého výkonného jádra, což Gracemont až překvapivě silně je.

Efficient Core procesorů Alder Lake, architektura Gracemont Zdroj: Intel

Frontend s 2×3 dekodéry

Na Gracemontu je jasně vidět, že vychází z předchozí „Atomové“ architektury Tremont (její architekturu jsme popisovali zde), ale jádro je stejně jako Golden Cove proti předchůdcům značně rozšířeno. Jádro po Tremontu přejímá jeho nejvýraznější rys: dekodéry, které jsou rozdělené do dvou klastrů po třech – počty zůstaly stejné. Tyto dva klastry nejsou rovnocenné šesti dekodérům v jádru Golden Cove, při dekódování proudu instrukcí se nemohou spřáhnout dohromady a dekódovat šest po sobě následujících instrukcí. Mohou jen paralelně dekódovat dva proudy instrukcí, každý po třech instrukcích za cyklus. Toto řešení je proti šesti dekodérům energeticky úspornější.

Efficient Core procesorů Alder Lake, architektura Gracemont Zdroj: Intel

K současnému využití obou skupin dekodérů dochází tehdy, když procesor kvůli větvení ví, že bude skákat na určitou adresu v kódu, kterou může druhý klastr dekodérů použít jako startovní bod a začít od tohoto místa paralelně dopředu dekódovat. Větvení mohou být v kódu hodně častá (při vydání Tremontu se mluvilo, že mohou nastávat v průměru třeba i každých šest instrukcí), což by dovolovalo druhý klastr dekodérů využít překvapivě často.

Zatímco kapacita dekodérů je stejná jako u Tremontu, Intel zvětšil na dvojnásobek L1 instrukční cache, která má místo 32 KB teď 64 KB (paradoxně 2× víc, než v Golden Cove). Stejně tak byla zvětšena Branch Target Cache prediktoru větvení (na 5000 položek, velikost v Tremontu nevíme), což zlepší jeho úspěšnost. Prediktor si má pamatovat poměrně dlouhou historii, což by opět mělo pomáhat úspěšnosti.

Efficient Core procesorů Alder Lake, architektura Gracemont Zdroj: Intel

Predecode informace v L1 instrukční cache

Jádro používá optimalizaci nazvanou On-Demand Instruction Length Decode. Ta by měla spočívat v použití pre-dekódování při načítání dat do L1 instrukční cache, které zjistí délky instrukcí a udržuje tuto informaci v L1 jako metadata (takže procesor už bude vědět, kde jednotlivé instrukce začínají). Tato informace se pak používá při opětovném provádění stejného kódu z L1 cache, kdy se díky tomu část práce dekodérů ušetří (a tím se také uspoří energie).

Gracemont nepoužívá μOP cache pro cachování již dekódovaných instrukcí a jejich opětovné použití, což větší x86 jádra (Intel od Sandy Bridge, AMD od Zenu, ARM od Cortexu-A77) implementují pro snížení spotřeby. Predecode a cachování délky instrukcí je zřejmě jakási zjednodušená náhrada, která je asi méně náročná na implementaci a množství tranzistorů, i když asi také méně pokročilá.

Velké posílení hlavně Out-of-order enginu a výpočetních jednotek

Zatímco Golden Cove provedlo největší rozšíření jádra ve Frontendu a menší v Backendu procesoru (samotných výpočetních jednotkách), Gracemont je tak trošku opačný případ. Frontend proti Tremontu není tak zvětšený, ale Backend výpočetních jednotek naopak velmi. Společné s Golden Cove ale je, že byla posílená prostřední část, kde dochází k optimalizaci a přehazování instrukcí stylem out-of-order.

Fáze Allocation umožňuje v Gracemontu zpracovat až pět instrukcí (μOPů) přicházejících z fáze dekódování a fronty μOP Queue za cyklus. Je to zlepšení o čtvrtinu proti Tremontu (ten je v této fázi pipeline jen 4-wide) a není to moc daleko od jádra Golden Cove, které má fázi Allocation zpracovávající až šest instrukcí za cyklus (6-wide). V této fázi se μOPům přiřazují jejich pracovní registry a dále se provádí přejmenování registrů kvůli konfliktům, které umožňuje instrukce používající kolidující architektonické registry vykonat současně. Zde také procesor dokáže eliminovat některé operace, které nepotřebují jít dál do výpočetních jednotek (MOV Elimination, Zeroing Idiomy).

Out-Of-Order okno jako má Zen 3

Po této fázi v procesoru následuje Re-Order Buffer (ROB), tedy fronta instrukcí, v níž procesor jejich pořadí přehazuje tak, aby se jich co nejvíce vykonalo paralelně a tím se využily pokud možno všechny dostupné jednotky. Out-of-order procesor může instrukce, které na sobě nezávisejí, vykonat paralelně a pokud nejbližší instrukce zatím nemají splněné závislosti nebo pro ně chybí data, může místo nich zatím počítat dopředu instrukce, které budou následovat v kódu dále. Toto kód „zkompaktní“ a k jeho vykonání je pak třeba méně cyklů. Ale pro co nejlepší účinnost tohoto přeorganizování je třeba, aby procesor „viděl“ co největší kus kódu, a tento kus představuje právě délka fronty Re-Order Buffer.

Efficient Core procesorů Alder Lake, architektura Gracemont Zdroj: Intel

Intel ho v Gracemontu použil docela velký – má totiž 256 položek. Je to sice jen polovina ROB, který má Golden Cove (512 položek), ale víc, než má architektura Skylake (224 položek), a co je pozoruhodné, stejná hloubka ROB, jakou má AMD u Zenu 3 (také 256). Je sice pravda, že Zen 3 je asi spíš výjimka, kde je ROB netypicky malý na to, jak je jádro výkonné, ale to, že má Gracemont 256 položek, dobře ukazuje, jak se vymyká z kategorie „malého jádra“.

Článek pokračuje na další straně.

Předchozí
Následující

59 KOMENTÁŘE

    • Clanek je podle mne naopak dobry. Co je pruser, je marketing Intelu, ze ktereho cerpa. JO poukazuje na mozne sede zony v ‚marketingovem‘ prezentovani architektury, kde je sice spousta grafu a cisel, ve skutecnosti ale nic, co by se dalo vzit jako nejaky realny technicky parametr. To poukazani na chybejici frekvence v clanku, novejsi vyr.proces, stavi prezentaci Intelu do trochu jineho svetla, nejspis horsiho.
      Takze jo, az se to otestuje, tak se teprve uvidi

  1. U mě zatím žádný dojem – ani pozitivní, ani negativní. S ohledem na ohlášenou spotřebu se žádný wow-efekt nekoná.
    Osobně si stále myslím, že celý design „x86 big.litttle“ je překombinovaný a bude problém udržet scheduler na uzdě, s čímž se pojí problém neočekávaných výkonových propadů. Jestliže platí, že oba typy jader mají jiné IPC, bude nutně výkon kolísat nezávisle na nastavené frekvenci. Když si vzpomenu, jak se u Zenu řešilo přiřazování ST úloh vybranému „lepšímu“ jádru, tak tohle mi připadá jako stejný problém, ale na steroidech. Nevěřím, že toto zvládne integrovaný scheduler bez ztráty kytičky – možná tak v benchi.

    • když jsi o tom scheduleru nevěděl, chtěl jsi, aby tam nějaký byl, když už tam je, bude prý k ničemu … tobě se těžko zavděčit 😀 … ber to jako „první vlašťovku“ … tak nějak nevěřím, že by to zkoušeli jen v benchmarcích … a taky na 100% neexistuje situace, aby se Intel zavděčil všem … kdyby prodávali ryzen 5800x s nálepkou Intel i11, stejně Redmarx napíše “ tohle bych do compu nedal ani s pistolí u hlavy“ …

      • Ale o tom žádná, potvrzuje se, že s big.little u ARMu to nemá nic společného, a tak je logické, že nějaký scheduler bude třeba. Jen mám (IMHO oprávněné) obavy o to, jak spolehlivě to bude fungovat. Protože tady se jedná o poměrně sofistikovaný proces „odhadování“ toho, co je aplikace na popředí. Jsem zvědavý, jak si třeba poradí s malwarem, nebo vytěžujícím ovladačem, který se někde v koutku točí za svým vlastním ohonem a na obrazovce svítí jeho okno, zatím co ty se budeš snažit třeba pracovat v Excelu.

          • Asi takto: já si právě myslím, že úhelný kámen celého řešení je ten scheduler. Jen si vem, jak MS nechtěl upravovat svůj scheduler ve Windows, a to je prosím scheduler, který je součástí jádra Windows, takže má detailní informace o procesech. Navíc se bavíme o řešení schedulingu pro více než 16 jader, ale stejných, nebo velmi podobných jader, lišících se jen dosahovanou frekvencí v zátěži, a to je řádově jednodušší problém než řešit, jestli to hodíš na Davida nebo Goliáše.

            A teď si to celé posuň na úroveň baremetalu, kdy už vlastně ani pořádně nevíš, jestli ty instrukce, které zrovna provádíš, jsou instrukce kódu kernelu, aplikace, nebo ovladače, protože ti chybí ten kontext, který má jádro OS. Je docela možné, že ty avizované úpravy od MS ve Windows půjdou právě tímto směrem, prostě se nějakým semaforem bude „tagovat“ důležitý kód – ale to je jen moje spekulace. Jinými slovy, procesor buď bude „odhadovat“ co je třeba vykonat přednostně, nebo bude mít „noty“ na totéž, pak ale bude třeba spolupráce s OS (a to zase bude problém s Linuxem a BSD, aspoň dočasně). Je samozřejmě taky možné, že v případě MT zátěže se výkon Biga omezí na výkon Littla, čistě kvůli power obálce celého CPU, to si ale nemyslím, že bude pravděpodobné řešení, protože by pak celý koncept skončil jako svého druhu lepší ST turbo a nebyl by potřeba HW scheduler.

            Tak jak tak je to IMHO hodně zajímavé řešení a jsem zvědavý, jak to bude reálně řešeno a hlavně zda to bude fungovat (univerzálně – to by asi byla lambáda, nebo pouze specificky, případně vůbec – tomu moc nevěřím)

            • tak „lambáda“ 😀 „D smysl pro humor tě neopouští, to je dobré znamení …

            • Pekne popsano, neco podobneho jsem mel na mysli i ja. Ackoliv se mi architektonicke zmeny libi jak u GoldenC, tak u Gracemont, a to hodnotim hodne kladne, tak jsem zatim k celemu konceptu malinko skepticky prave kvuli tomu scheduleru, na kterem to bude cele stat.
              Ono totiz ty propady vykonu u „testu“ GoldenC oproti predchozi generaci mohou klidne ukazovat na scheduler, ktery bud neni vyladeny, nebo vyladit ho nepujde tak lehce.
              V kazdem pripade jsem na realne testy zvedav a uz ted premyslim o nove „AL“ hracce 😉

  2. to že Gracemont konečně dotáhnul výkonem Skylake z roku 2015 není na žádnou oslavu… spíš smutné…. ať žije pokrok !
    ad ty marketingové grafy ohledně spotřeby: ono když se srovnává 14nm a 7nm tak to pak ta spotřeba/velikost jádra vypadá hezky…

    lepší bude počkat na nezávislé testy, zatím je tam až přiliš mnoho neznámých proměnných, nevíme jak dobře bude fungovat koncept Big-Little nebo přehazování vláken prostřednictvím Thread Directoru atd. a v neposlední řadě o případném zájmu o koupi bude ve velké míře rozhodovat nastavená cena.

    když nic jiného, aspoň by AL mohl vytvořit určitý cenový/výkonostní tlak na AMD , což je pro nás zákazníky dobře .-)

    PS: díky Honzovi za pěkný rozbor i ten „ukecaný“ úvod na začátku článku

  3. Alder Lake
    Zapnu vypocetni aplikaci a zacne pocitat:
    scheduler zapne prvni male jadro, nestaci to, zapne druhe male jadro, nestaci to, zapne treti male jadro, nestaci to, zapne ctvrte male jadro, nestaci to, zapne pate male jadro, nestaci to, zapne seste male jadro, nestaci to, zapne sedme male jadro, nestaci to, zapne osme male jadro, nestaci to, co ted?
    V horsim pripade se dosahne limitu PL1 a nic dal nebude. 🙂
    V lepsi pripade zapne prvni velke jadro, nestaci to, zapne druhe velke jadro …. 😀

    • Zapnete „výpočetní aplikaci“, ta spustí inicializační vlákno, které nic nepočítá, ale jen zjistí, kolik jader (vláken) má procesor a tolik pustí svých výpočetních vláken. Scheduler všechna vlákna spustí, okamžitě vidí, že jsou to vlákna, která neidlují a nacpe je každé na jedno jádro/vlákno procesoru.

        • Vaší poznámce moc nerozumím.
          OS je schopen poznat vlákno, které je výpočetní, jednoduše tak, že to vlákno se samo nevzdává svého běhu, ale scheduler ho vždy musí pozastavit, aby ho mohl prostřídat s jiným vláknem (teď mi třeba běží 3536 vláken, ale ani jedno nevytěžuje jádro, na kterém běží, na maximum).
          Když je takových vláken málo, nacpe je na velká jádra. Pokud je takových vláken hodně, nacpe je na všechna jádra. Pokud jsou vytížena všechna (či skoro všechna) jádra, tak jsou uměle bržděna (frekvenčně) velká, protože mají horší efektivitu.
          Pokud by můj systém běžel aktuálně na bigLITTLE architektuře a ne na Ryzenu 3900X, tak by velká jádra spokojeně spala a všech těch mých 3536 flákajících se vláken by běželo na těch malých jádrech.
          Guláš v tom žádný není.

          • Pekna teorie, ale v mobilech se jim to takto zatim implementovat nepodarilo, pomerne slozite prepinaji velka a mala jadra, kdy bud bezi jenom mala a to treba ne vsechna nebo system rozbehne velka vlakna, ale potom aplikace vytizi treba 100% velkych jader, ale uz neumi vytizit zadne z tech malych jader navic. Na tech bezi jen system a klidne jich i vic jak pulka muze spat i v dobe 100% vykonu vsech velkych jader.

            Tak uvidime, o kolik bude Intel v implementaci uspesnejsi.

            • Vám taky nerozumím. Kolik si aplikace pustí výpočetních vláken je zcela její věc. A nenapadá mě důvod, proč by měl procesor ta vlákna, která potřebují výkon honit jen na některých jádrech a jiná nechal flákat.
              V podstatě je to totéž, co dneska dělá s HT (SMT). Nejprve obsazuje jedno vlákno na jádro a teprve, když má těch vytěžovacích vláken více, než je jader, tak začne používat druhé vlákno na jádro. A je samozřejmě věcí té aplikace, kolik vláken vytvoří.
              Na mobilu samozřejmě už dávno malá a velká jádra najednou běžet mohou. První takový čip byl, pokud se nepletu Samsung Exynos 5420 a to už je nějakých 8 let.

            • Ne, ty jadra prave na mobilu zaroven na stejne urovni nebezi. Aplikace si z tech malych jader ukousnout nemuze, funguji jen jako podpurna na system.

            • Pokud se nepletu a nic se nezměnilo, tak v mobilech se nikdo nesnažil o současný běh aplikace na všech jádrech. Malá jádra tam jsou kvůli úspoře energie při malém zatížení.

  4. Tak ja neviem, všade že Skylake, že menšia spotreba a +- rovnaký výkon, no Skylake je 14nm… keby spravili skylake 7nm nežral by menej a nebol by menší? jasné že áno… ja tam nevidím nič prevratné, proste menší výrobný proces prináša benefit v spotrebe a veľkosti, inak nula, nula….. nič prevratné. Či je riešenie v desktope dať namiesto jedného poriadneho jadra s HT menšie a viac uvidíme, no v desktope asi to nebude terno….. veľa malých alebo radšej menej veľkých s HT? Ja osobne radšej menej veľkých by som bral….. v mobilnom segmente možno, ale teším sa, niečo nové, bude čo čítať a testovať a kritizovať…

    • i5 skylake se 4mi jádry měla kolik 65W, tady máš ty skajlajky dva, tudíž 130W plus k tomu další plnotučné hitech osmi jádro, celkem to má kolik 228W tzn = 98W takže tam nějaká úspora musí být. A navíc nevíme jak je to s kontiunální spotřebou, takže zatím u mě jakž takž pořád dobrý.

  5. Hybridná technológia big.LITTLE je vynikajúca cesta
    ako radikálne zvýšiť efektivitu procesorov. To nám
    už takmer rok dokazuje Apple svojim integrovaným
    procesorom 4C+4c. Intel sa rozhodol pre najlepšie
    riešenie s ohľadom na najbližšiu budúcnosť i
    strategický význam. Hustota tranzistorov sa bude
    navyšovať a nepríjemnosti s tým spojené je
    potrebné preventívne riešiť, čo aktuálna hybridná
    technológia v podaní Intelu práve robí.
    Zjednodušený príklad – prečo by sa malo 16 výkonných
    jadier škvariť pod vysokým napetím, za vysokej
    teploty a neefektívnom pásme s vysokou spotrebou,
    ak môžme záťaž rozložiť na 32 fyzických jadier bez
    HT, ktorých pracovný bod bude vo vysokoefektívnom
    pásme, pričom tranzistory budú tikat na pohodových
    frekvenciách s veľmi nízkym Vcore a tým pádom
    nízkej teplote a zlomkovej spotrebe….
    Ano, Intel s Apple odhadli ďaľší vývoj správne,
    AMD zachrápalo, tak-či-tak červení budú prinútení
    nastúpiť do rozbehnutej mašinérie, ale so sklzom
    pravdepodobne 3-4 roky…

    • To, že procesor běží na neefektivním napětí a frekvencích a má kvůli tomu spotřebu jako blázen ale zrovna je problém, který je k tomu, jestli je procesor hybridní nebo má homogenní jádra, úplně ortogonální.
      Intel může hnát výkon za cenu napětí a spotřeby nahoru úplně klidně i u Alder Lake (včetně těch malých jader – ostatně koukněte jak se vyvíjí ta křivka jejich výkonu vs. spotřeba, hnát je na maximum také způsobí, že budou neefektivní) a jestli se potvrdí, že PL2 zase půjdou výš než 200 W, tak se tenhle problém skutečně nevyřešil.

      Ten problém je, že výrobci připouštějí u procesorů příliš velkou spotřebu.
      AMD 142 W (PPT pro „105W“ modely) a už to je dost, ale Intel nechává „125W“ CPU žrát ještě mnohem víc.
      Tyhle „wattáže“ jsou to, co se musí snížit/zlepšit, aby se dalo jásat nad efektivitou.

      • Uznávam, moja chyba, že sa mi vytratilo upresnenie
        toho príkladu “ pri stejnom výkone „, teda to upresňujem dodatočne…

        Alder Lake je začiatok, tam to nebude ešte tak
        očividné, ale Arrow Lake so 40 core 8C + 32c to
        už bude iná káva…

        Wattáže sa musia znížit, ale nie prostredníctvom
        zníženia Vcore a tým zníženia výkonu/frekvencie,
        neefektívneho čipu, ale práve nasadením vyššieho
        počtu úsporných jadier pracujúcich s nízkym
        napetím s cieľom dosiahnutia stejného výkonu
        s podstatne menším príkonom…

        • Jako super, jenze tohle co pises, se zatim u zadneho vyrobce bigLITTLE architektury nepodarilo. Velke mnozstvi malych jader ma znacne odpadni ztraty a tudiz se dosahuje stejneho vykonu s vetsim prikonem. Proto to nakonec ti vyrobci takto vubec nedelaji a funguji na systemu prepinani velkych a malych jader, ale v zadnem pripade je nedokazi prubezne presne dle potreby zapinat a vypinat a tim perfektne skalovat vykon a spotrebu.

          Jako urcite Intelu preju, aby se mu to jako prvnimu podarilo, ale uprimne bych na to nevsadil ani 1 Kc.

            • Ze zatim nikde nemas konfiguraci 8+32, protoze nemas duvod mit 32 malych jader k nicemu. Misto toho vyrobci v mobilni sfere jedou treba i prepinane jadra 1+3+4. No a tudiz se to neda ani scitat. Ve vysledku budes mit 8+32 mensi vykon nez 16+0 a jeste tech 16+0 muze byt uspornejsi.

              Jako netvrdim, ze to Intel neprorazi, ale nic tomu nenasvedcuje. Oslavy fanousku Intelu jsou tudiz hodne predcasne. Pockejme na nezavisle testy, pak se uvidi. Ja osobne neverim, ze to Intel da a Intel hw scheduler dokaze to, co se zatim nikomu nepodarilo.

            • mám dojem, že plácáš kompletní nesmysly … Intel po létech vývoje přijde na to, že to, co vymysleli, nefunguje … mícháš dohromady x86 a arm a taky „amatéry“ od arm s profíky z intelu, nebo amd …

            • Uvidime.
              Ja tvrdim, ze bigLITTLE nefunguje v ARM a nebude fungovat ani Intelu!

  6. Tady někdo nemůže těžce spolknout že AMD jde pomalu a jistě do kopru, co se týče Tynýta, tam není co řešit, je ho před vydáním AL všude plno a plive kolem sebe kde se dá, ale nečekal jsem tak těžký fanatismus od Delsy42, ten zase plive na Intel kde se dá, hlavně na PcT, co se týče dementů z Diitu, tam není co řešit, stačí si přečíst a potom si dát těžkou sodu a rozdejchat to. Já osobně už se těším až hodím 5950x a 5900x do popelnice a rozloučím se s nedodělky od AMD a opět osedlám Intel, jj uznávám že to trošku trvalo ale konečně je tam kde má být.

  7. Honzo, pokud ty malé jádra jsou bez HT technologie, tak je příště srovnávej s procesorem SkyLake také bez HT, tudíž 6600K, který točí alespoň u mě 4,4GHz a jsou týpci co z toho vytáhli i 4,6GHz. Takže jestli v tom procáku jsou dva skylajk procáky a k tomu další osmijádro, tak se obávám, že to bude víc jak 50%+ výkonu všude tam kde to dokáže aplikace využít.
    Jak se budou taktovat K verze? Nejspíš nebudou mít společnej násobič co ?