architektura-procesoru-nehalem-2-2
Hardware Článek Architektura procesorů Nehalem (2/2)

Architektura procesorů Nehalem (2/2) | Kapitola 4

Petr Koc

Petr Koc

4. 9. 2008 01:00 71

Seznam kapitol

1. Front-end 2. Dekódování 3. Out-of-order engine 4. Cache subsystém
5. Paměťový subsystém 6. Správa energie 7. Co od Nehalemu čekat?

Nehalem bude první masově nasazovaný procesor Intelu, který bude integrovat řadič pamětí blízko procesoru. Tím ale výčet novinek nekončí. Inženýři se při návrhu zaměřili také na návrh samotné výpočetní části a kompletně předělali také návrh cache subsystému. Pojďme se podívat, v čem budou největší změny samotné architektury procesoru.

Reklama

V předchozím textu jsme již nakousli instrukční cache. Nyní se na celkový subsystém podíváme blíže.



Architektura Nehalemu je optimalizovaná především pro serverové použití. Serverové úlohy jsou typické tím, že se často jedná o několik velmi podobných nezávislých operací běžících vedle sebe. Například pokud v databázovém serveru provádíme jednoduché selekty typu…



SELECT jmeno, prijmeni FROM zamestnanci



… pak RDBMS engine začne prohledávat tabulku a z ní volí data (… což patrně provede tak, že si načte data ze svého interního záznamového formátu, sestaví dynamický seznam pomocí objektů a pointerů a následně tyto objektové struktury předá tazateli). Tato jedna konkrétní úloha bude patrně obtížně paralelizovatelná tak, aby bylo dosaženo slušného výkonu (nucená paralelizace by patrně vedla ke zpožděním vlivem nepřítomnosti dat v cache). Nicméně pokud server bude vykonávat tyto úlohy dvě, např. od dvou vzdáleně připojených klientů nebo jakožto subsoučást složitějších SQL dotazů, pak bude možné každou úlohu řešit separátně. Tyto separátní úlohy přitom nebudou sdílet téměř žádná data, neboť se každá zabývá něčím jiným (např. jinou tabulkou). Z hlediska návrhu architektury cache subsystému je tento fakt velmi důležitý. V zásadě je totiž možné navrhnout cache jako sdílenou nebo jako nesdílenou (separátní).





Každý tento přístup má své výhody a nevýhody. Sdílená cache může, při konkurenčním přidělování místa, nabídnout jednomu vláknu potenciálně větší úložnou kapacitu, než kolik by mu nabídla cache separátní - logicky jde o výrobní náklady. Pokud máme k dispozici transistory na 4 MB cache, pak z nich buďto vytvoříme jednu 4 MB cache s potenciálem přidělení celých 4 MB jak vláknu 1, tak vláknu 2, nebo vytvoříme dvě 2 MB cache, které každé nabídnou svému příslušnému vláknu jen 2 MB. Další výhodou sdílené cache je, že pokud vlákno 1 upraví nějaká data v RAM momentálně bufferovaná v cache, pak se tato úprava hodnot projeví i pro vlákno 2 a to ještě před tím, než se data skutečně zapíšou do paměti RAM. U separátních cache je buďto nutné provádět synchronizaci obsahů cache (… což, jak se v praxi ukazuje, se provádí pomocí polo-nefunkčních mechanismů) nebo prostě počkat, až se změna zapíše do RAM, a následně tuto změněnou hodnotu přečíst do druhé cache (… což je zase strašlivě pomalé).



Na druhou stranu nevýhodou sdílené cache je to, že její celková propustnost je o polovinu nižší, než u separátních cache. Pokud např. uvážíme, že propustnost cache bude jeden 64 byte cache line každých 10 hodinových cyklů, tak dvě menší cache získají celkem dvě cache line, zatímco jedna větší cache pouze jednu. Separátní cache tak nabízí jednotlivým vláknům vyšší propustnost. A co víc, velká sdílená cache má i problémy technického charakteru – její návrh je složitější, neboť je větší (a větší obecně znamená pomalejší) a také musí být víceportová (není určena jen pro jeden logický procesor, což také znamená pomalejší).



Z hlediska nasazení se sdílená cache hodí pro programy, které zpracovávají ve vláknech data, která jsou nějakým způsobem propojená – to se týká zejména aplikací v oblasti desktopů (třeba her) a částečně i v oblasti workstation. Naopak separátní cache jsou vhodné pro servery, kde spolu jednotlivé úlohy nesouvisí.





Architektura Core byla stavěna primárně s ohledem na desktopové aplikace. Měla velkou, rychlou, sdílenou L2 cache. Její parametry dosáhly maxima v jádrech 1067x (rodina Penryn), kde byla přítomna dvouportová, 6 MB velká, 14 cyklová, 24-way asociativní cache. Nehalem naproti tomu implementuje zcela jiný přístup. Zakládá se na třech úrovních cache, přičemž L2 je separátní pro každé jádro a L3 je sdílená mezi všechna jádra.



Připomeňme v této souvislosti, že u Nehalemu je sdílená už i L1 cache a to mezi dvě vlákna zpracovávaná v rámci technologie Hyper-Threading.



Nehalem tak spíše preferuje úlohy, které jsou nezávislé – tedy obecně servery. Toto uspořádání má bohužel pro desktopové použití značné nevýhody:



  1. L2 cache má velikost prťavých 256 kB (proti 6 MB u Penrynu). Přestože je rychlá (10 cyklů), její malá velikost bude pro mnoho desktopových úloh limitující. Týkat se to může například her, které jsou na velikosti a rychlosti cache dost závislé. A když to vezmeme kolem a kolem, 24x tak velká L2 cache Penrynu o tolik pomalejší není (14 cyklů)
  2. Synchronizace dat mezi jádry se stává obtížnější, protože jediná sdílená cache (L3 cache) je od jádra příliš daleko (zhruba 40 hodinových cyklů vs. 14 cyklů u Penrynu).

Aby toho nebylo málo, jsou zde ještě další vlastnosti, které činí cache subsystém pro desktopové úlohy mnohem méně vhodný:


    


Core

Nehalem

L1 instrukční cache

separátní 32 kB,

8-way

separátní, 32 kB,

4-way

L1 datová cache

separátní, 32 kB,

3T

, 8-way

separátní, 32 kB,

4T

, 8-way

L2 unifikovaná cache

sdílená, 6 MB,

14T

,

24-way

separátní, 256 kB, 10T, 8-way

L3 unifikovaná cache

sdílená, 8 MB,

40T

,

16-way


Protože každé jádro podporuje Hyper-Threading, jsou už cache první úrovně dvouportové, a proto mají horší vlastnosti (instrukční má nižší účinnost a datová je pomalejší). L2 cache je trapně malá a L3 cache hrozivě pomalá a dokonce má i přes větší velikost menší asociativitu než L2 u Penrynu! Tento cache subsystém se pro desktopové použití nedá ve srovnání s Penrynem nazvat jinak než katastrofou. Bohužel je to daň za více jader a více zpracovávaných vláken. Být Nehalem konstruován jako dvoujádrový a bez Hyper-Threadingu, nic by nebránilo dosažení vyšších výkonů cache, a tedy i vytvoření lepších podmínek pro desktopové aplikace. Výhodu to bude mít snad jen pro uživatele, kteří super-intenzivně multitaskují a zároveň nepoužívají Windows (je vůbec někdo takový?).



Windows mají velmi hloupou tendenci neustále přehazovat procesy mezi jádra. To vede k velkému množství cache miss, které se v praxi projevují poklesem výkonu na jedno jádro oproti jednojádrovým procesorům a také horší odezvou v plném zatížení oproti jednojádrovým procesorům, se kterou ani nelze nic dělat (snížení priority procesu nepomáhá).



Předchozí
Další
Reklama
Reklama

Komentáře naleznete na konci poslední kapitoly.

Reklama
Reklama