Intel Silvermont: ofenzíva do světa tabletů a mobilů
27.6.2013, Petr Štefek, recenze
Intel tento měsíc uvedl zbrusu novou architekturu Silvermont, která bude pro společnost vstupenkou do elitního klubu výrobců špičkových platforem pro tablety a smartphony. Silvermont nebude žádné ořezávátko a třást se před ním může AMD Jaguar i ARM Cortex A15.
Kapitoly článku:
Pokud se máme dozvědět něco více o architektuře Intel Silvermont, tak si musíme udělat malé opakování, co se týká principů out-of-order execution. Informovanějším je zřejmě jasné, jaký je rozdíl mezi out-of-order a in-order architekturou. První jmenovaná má výkonnostní výhodu a naopak ztrácí v provozních vlastnostech a velikosti jádra, respektive jeho plochy díky vyššímu počtu tranzistorů.
Funkce CPU obyčejně spočívá v tom, že čte instrukce libovolného programu, který běží a v závislosti na tom vykonává to, co je obsahem těchto instrukcí. Jejich výsledek zapíše následně zpět do paměti. Programový čítač uvnitř CPU určí adresu v paměti, kde bude vykonána a zapsána příští instrukce. Logika CPU tuto instrukci vezme pěkně po pořádku (in-order), a ta je následně dekódována do formátu, kterému CPU „rozumí“ (jsou případy kdy je jediná instrukce dekódována, respektive rozložena na více menších instrukcí). V momentě, kdy je instrukce dekódována, tak jsou všechny potřebné operandy načteny z paměti (pokud už nejsou uloženy v lokálních registrech) a následně je kombinace instrukcí a operandu posunuta k vykonání exekučními jednotkami. Výsledky jsou pak uloženy v paměti, kterou představují registry, cache nebo systémová paměť. A tak to jde pořád dokola.
V in-order architekturách je potřeba dodržovat pořadí zpracování v pipeline, což může znamenat občas problém, protože hodně kroků je v tomto ohledu závislých na potřebě mít příslušné operandy k dispozici ihned, když jsou pro vykonání instrukce potřeba. Operandy na druhé straně mohou být závislé na předešlé instrukci, která dosud nebyla zpracována, anebo mohou být uloženy v operační paměti, což je pro CPU trošku z ruky. V tomto případě dojde k tomu, že efektivita architektury, respektive vykonávání instrukcí, značně poklesne.
Pipeline - Saltwell vs. Silvermont
Na druhé straně out-of-order architektura se snaží těmto problémům předejít tím, že CPU bude vykonávat instrukce, které mohou být vykonány dříve než ostatní, které zatím čekají na data. Fronta instrukcí se tak nezastaví, ale instrukce, které by blokovaly frontu, jsou jednoduše odloženy. Instrukce jako takové jsou načítány popořadě, ale samotné vykonávání je již out-of-order, respektive mimo pořádek.
Jak jsme si řekli na počátku této kapitoly, tak využití out-of-order architektury přináší jistou oběť, co se tyká plochy jádra a následné spotřeby, což je mimo jiné také důvod, proč se dostala out-of-order architektura do mobilních platforem tak pozdě. Pokud se vrátíme ke známému ARM Cortex A8 nebo Bonnell (x86) alias první Atom, tak se jednalo o typické in-order architektury. Celkově se ovšem potřeba výkonu v mobilních zařízeních zvětšuje, takže přestup na out-of-order je logickým vyústěním.
Intel ale svým Silvermontem nebo AMD s Jaguarem nejsou prvními out-of-order mobilními architekturami. Mezi out-of-order architektury můžeme započítat také ARM Cortex A9 (ikdyž jen částečně) a ARM Cortex A15 a Qualcomm Krait 200/300 (opět jen částečně). Silvermont se tak zařadí do elitního klubu plně out-of-order architektur. Mezi výhody out-of-order patří také výrazné zvýšení výkonu u jednovláknových aplikací.
Celkově je změna pipeline oproti Atomu relativně malá. Atom respektive Bonnell měl 16stupňové pipeline a samozřejmě in-order architektury. Velkou nevýhodou řešení Bonnellu bylo, že všechny operace musí projít přes všechny úrovně datové cache, i když se nimi v důsledku vůbec nepracovalo. Nově bude dovolovat out-of-order architektura Silvermontu přemostit ty úrovně, které nepotřebují data z paměti, což bude mít za následek výrazné zkrácení úrovní pipeline, přes které musí data projít (z 13 na 10 v případě floating-point a v případě celočíselných je to 14-17 úrovní).
Jedním z hlavních posunů je v případě Silvermontu vylepšená branch prediction, která je pro efektivní architekturu stěžejní. Nová architektura si sice vzala brach predictor z Bonnelu, ale značně zvětšila velikost a navíc přidala nepřímý branch predictor (tato logika se snaží jednoduše řečeno odhadnout jaký kód se bude zpracovávat a jak bude vypadat a alokovat dostupné zdroje). Kombinací obou vylepšení by mělo dojít k markantnímu zlepšení přesnosti predikce. V řeči procent by mělo dojít k 5-10% navýšení IPC (Instruction Per Cycle).
Funkce CPU obyčejně spočívá v tom, že čte instrukce libovolného programu, který běží a v závislosti na tom vykonává to, co je obsahem těchto instrukcí. Jejich výsledek zapíše následně zpět do paměti. Programový čítač uvnitř CPU určí adresu v paměti, kde bude vykonána a zapsána příští instrukce. Logika CPU tuto instrukci vezme pěkně po pořádku (in-order), a ta je následně dekódována do formátu, kterému CPU „rozumí“ (jsou případy kdy je jediná instrukce dekódována, respektive rozložena na více menších instrukcí). V momentě, kdy je instrukce dekódována, tak jsou všechny potřebné operandy načteny z paměti (pokud už nejsou uloženy v lokálních registrech) a následně je kombinace instrukcí a operandu posunuta k vykonání exekučními jednotkami. Výsledky jsou pak uloženy v paměti, kterou představují registry, cache nebo systémová paměť. A tak to jde pořád dokola.
V in-order architekturách je potřeba dodržovat pořadí zpracování v pipeline, což může znamenat občas problém, protože hodně kroků je v tomto ohledu závislých na potřebě mít příslušné operandy k dispozici ihned, když jsou pro vykonání instrukce potřeba. Operandy na druhé straně mohou být závislé na předešlé instrukci, která dosud nebyla zpracována, anebo mohou být uloženy v operační paměti, což je pro CPU trošku z ruky. V tomto případě dojde k tomu, že efektivita architektury, respektive vykonávání instrukcí, značně poklesne.
Pipeline - Saltwell vs. Silvermont
Na druhé straně out-of-order architektura se snaží těmto problémům předejít tím, že CPU bude vykonávat instrukce, které mohou být vykonány dříve než ostatní, které zatím čekají na data. Fronta instrukcí se tak nezastaví, ale instrukce, které by blokovaly frontu, jsou jednoduše odloženy. Instrukce jako takové jsou načítány popořadě, ale samotné vykonávání je již out-of-order, respektive mimo pořádek.
Jak jsme si řekli na počátku této kapitoly, tak využití out-of-order architektury přináší jistou oběť, co se tyká plochy jádra a následné spotřeby, což je mimo jiné také důvod, proč se dostala out-of-order architektura do mobilních platforem tak pozdě. Pokud se vrátíme ke známému ARM Cortex A8 nebo Bonnell (x86) alias první Atom, tak se jednalo o typické in-order architektury. Celkově se ovšem potřeba výkonu v mobilních zařízeních zvětšuje, takže přestup na out-of-order je logickým vyústěním.
Intel ale svým Silvermontem nebo AMD s Jaguarem nejsou prvními out-of-order mobilními architekturami. Mezi out-of-order architektury můžeme započítat také ARM Cortex A9 (ikdyž jen částečně) a ARM Cortex A15 a Qualcomm Krait 200/300 (opět jen částečně). Silvermont se tak zařadí do elitního klubu plně out-of-order architektur. Mezi výhody out-of-order patří také výrazné zvýšení výkonu u jednovláknových aplikací.
Celkově je změna pipeline oproti Atomu relativně malá. Atom respektive Bonnell měl 16stupňové pipeline a samozřejmě in-order architektury. Velkou nevýhodou řešení Bonnellu bylo, že všechny operace musí projít přes všechny úrovně datové cache, i když se nimi v důsledku vůbec nepracovalo. Nově bude dovolovat out-of-order architektura Silvermontu přemostit ty úrovně, které nepotřebují data z paměti, což bude mít za následek výrazné zkrácení úrovní pipeline, přes které musí data projít (z 13 na 10 v případě floating-point a v případě celočíselných je to 14-17 úrovní).
Jedním z hlavních posunů je v případě Silvermontu vylepšená branch prediction, která je pro efektivní architekturu stěžejní. Nová architektura si sice vzala brach predictor z Bonnelu, ale značně zvětšila velikost a navíc přidala nepřímý branch predictor (tato logika se snaží jednoduše řečeno odhadnout jaký kód se bude zpracovávat a jak bude vypadat a alokovat dostupné zdroje). Kombinací obou vylepšení by mělo dojít k markantnímu zlepšení přesnosti predikce. V řeči procent by mělo dojít k 5-10% navýšení IPC (Instruction Per Cycle).
