Gyorsítótárak, memóriaelérés
A Nehalem megjelenésével folytatni kívánjuk a K10-es debütjét követő szokásunkat, és az alkalmazástesztek előtt szintetikus benchmarkok segítségével is fel szeretnénk térképezni az új architektúrát. Az átlagfelhasználó számára ezek a benchmarkok, illetve az ezekben elért eredmények nem jelentenek szinte semmit, mégis, érdekesség gyanánt egy-egy új architektúra megjelenését követően érdemes egy kicsit lejjebb ásni, hogy lássuk, mi történt, mit alkottak a mérnökök az elmúlt években, mely területek az újdonság gyengéi vagy erősségei, és mi következik mindebből. Cikkünk ezen része két felvonásra osztható fel, először a memóriavezérléssel és a cache-hierarchiával foglalkozunk (ez a kettő nehezen választható ketté), majd az utasítás-végrehajtás kapja a főszerepet. Mélyvíz, csak úszóknak!
A késleltetési időket ábrázoló grafikonról kiderül, hogy a Nehalem L1 cache-ének elérési ideje nőtt a Penrynéhez képes, 4 órajel lett, míg a többieké 3 órajel volt. Ugyanakkor a másodszintű gyorsítótár késleltetése drasztikusan csökkent, 17 órajelről 11-re. A harmadszintű gyorsítótár késleltetése a Phenom szemszögéből érdekes, hiszen az asztali CPU-k között csak az AMD processzora rendelkezik L3 cache-sel, amely – mint tudjuk – késleltetésben gyorsabb a rendszermemóriánál, de szekvenciális másolásban/írásban alig előnyösebb annál. A lényeg, hogy a Nehalemben található L3 cache eléréséhez 13 órajelre van szükség, míg a Phenomban találhatóhoz 25 órajel alatt jut hozzá a processzor, vagyis közel dupla olyan gyors, ami igen jelentős különbség.
Megvizsgáltuk az L1D gyorsítótár sebességét; a Nehalem ezen a téren semmit nem változott, ugyanolyan gyors, mint a Penryn. A Core 2 processzorokban két 128 bites port van, ezek egymástól teljesen függetlenül működnek. Ez jól is látszik, az olvasás és az írás ugyanolyan gyors, míg a másolás során összeadódik a két port sebessége. 3,2 GHz-es órajelen az elérhető maximális olvasási/írási sebesség 51 200 MB/s, míg másolásban ezen érték duplája. Az Everest Copy az L1D cache méretének felét olvassa ki és írja vissza, amiben pontosan az a jó, hogy így a teljes copy rutin az L1D cache adataival dolgozik, és tisztán látszik, ha függetlenek a load/store portok. A Phenom máshova helyezi a hangsúlyokat, aminek bizonyára vannak előnyei.
A következő lépcső a másodszintű gyorsítótár sebességének lemérése volt, ami már egy kicsit bonyolultabb téma, mert eltérő késleltetéssel eltérő sebességűek a gyorsítótárak. Az L1 esetében ez nem volt nagy probléma, mert az L1 cache-ek késleltetése közel azonos volt, de az L2-nél már jóval nagyobbak a különbségek. A Nehalem itt elhúzott, mert a Penrynben található nagy, 6 MB méretű gyorsítótár elérési ideje jóval rosszabb. A Nehalemben található másodszintű gyorsítótár, bár kicsi, ugyanakkor olvasában 23, írásban 45, másolásban pedig 35%-kal gyorsabb, mint a Penryné. A Phenom lemaradása egyértelmű.
Végül az L3 gyorsítótárakat vetettük össze, mintha a Nehalem és a K10 külön dimenzióban létezne. A Nehalem L3-asa olvasásban kb. 3-szor, írásban kb. 2-szer és másolásban kb. 2,5-szer gyorsabb a rivális megoldásánál, ráadásul a Nehalemben található L3 cache méretre is jóval nagyobb. A lejáratás elkerülése végett azt azért figyelembe kell venni, hogy a tesztelt Phenom L3-asa csak 2 GHz-es órajelen járt, és egyelőre nem tudjuk, hogy a 45 nm-en gyártott, következő generációs Phenom L3-asa milyen gyors lesz, de ha feltételezzük, hogy az is 33%-kal magasabb, 2,66 GHz-es frekvencián fog ketyegni, még akkor is jóval gyorsabb a Nehalem harmadszintű gyorsítótára.
Ezek után a memóriaelérési, azaz késleltetési időkkel foglalkoztunk. Elsőként az Everest benchmarkjával teszteltünk, ami lineáris elérési időt mér, azaz, hogy a memóriaolvasási parancs kiadásától számítva mennyi idő telik el, míg az adat megérkezik a regiszterekbe. Ezúttal megvizsgáltuk azt is, hogy a Nehalem DDR3-1333-as üzemmódban gyorsul-e. A még rendszerbuszon kommunikáló Penryn jelentősen le van maradva a Nehalem mögött, ami a gyorsabb memóriával 4 ns-ot tudott javítani DDR3-1066-os legjobb eredményén.
Az Everest lineárisan végzett méréseinek következő állomása a memóriaműveletek sebességének lemérése egyetlen szálon. A Nehalem már három csatornán keresztül fér hozzá a memóriához, ami teoretikusan 25,5 GB/s-os maximális sebességet feltételez. Az igazság azonban az, hogy ezek a memóriacsatornák egymástól függetlenül is képesek működni; kb. úgy képzeljük el ezt, mint a K10-es "unganged" módját. A gyakorlatban ennek alig a felét éri el, azt is csak másolásban, de még így is jóval gyorsabb a Penrynnél, amit lekorlátoz a rendszerbusz szűkössége. Gyorsabb a K10-nél is, ami beépített memóriavezérlője révén szintén komoly ellenfél lehetne, de az Everest szerint még a Penrynt sem képes befogni. Ebben a tesztben a Nehalemet nem csak kétféle memóriaórajel mellett teszteltük le, hanem megnéztük azt is, hogy a Hyper-Threading milyen hatással van a teljesítményre. Nagyon úgy tűnik, hogy a HT kikapcsolása lassítja a memóriaelérést, ami végülis egy jó pont, mert arra utal, hogy a használata javasolt, ugyanis a processzor képes kihasználni. A 1333MHz-es DDR3-as memória az olvasáson 10%-ot javított.
Ennél talán izgalmasabb téma a nem lineáris, azaz véletlenszerű memóriaelérés. A processzor számára szükséges, memóriában található adatok nem csak lineárisan helyezkedhetnek el, ezért a véletlenszerű memóriaelérés lemérése is kulcsfontosságú. A problémát a legjobban egy LATER nevezetű programmal tudtuk illusztrálni, az alkalmazás a memória véletlenszerű elérését méri kétféle módon, egyrészt az L1 cache-t is bevonva a munkába, másrészt az L1-et kivonva a forgalomból. A K10-esről már tudjuk, hogy az L1-be "épített" prefetch miatt ebben a módban jelentősen gyengébben teljesít még a K8-nál is, hiszen a prefetch logika mindig rossz adatot húz be a memóriába, amivel időt pazarol el. A Nehalem ezen a téren szinte nem változott semmit a Penrynhez képest, nagyjából ugyanolyan eredményeket értünk el vele. A tesztből az is kiderült, hogy a memória sebességének növelésével a véletlenszerű memóriaelérés ideje is csökken.
Az előzőleg tárgyalt programok sajnos csak egy szálon mérnek, ezért keresnünk kellett egy olyan benchmarkot, mellyel több szálon is képesek vagyunk a memóriaelérés tesztelésére. Végül megtaláltuk a Rightmark Multi-Threaded Memory Testet, amit pontosan ennek a kérdésnek a megválaszolására fejlesztettek ki. A programmal az operációs rendszer által látott összes logikai processzoron külön-külön végeztethetünk el írást vagy olvasást. Be kell állítani a tesztelés során használt memóriablokkok méretét, a művelet típusát (olvasás, írás, szoftveres prefetch-csel olvasás, non-temporal írás) és a használt regiszterek típusát, ezek a:
- 64 bit MMX: MOVQ reg, [mem]; MOVQ [mem], reg és MOVNTQ [mem], reg
- 128 bit SSE2: MOVDQA reg, [mem]; MOVDQA [mem], reg és MOVNTDQ [mem], reg
lehetnek.
Beállítható a szoftveres prefetch hossza is. Mi 64 MB-os blokkokat alkalmaztunk (tehát a 64 MB-ot osztottuk annyi felé, ahány szálon folyt a tesztelés, két szálon 32 MB, négy szálon 16 MB), és 128 bites regisztereket használtunk. A program lényege tehát a több szálon végzett konkurens memóriaelérés tesztelése, amivel kimutatható a rendszerbuszt használó processzorok ilyen téren való gyengélkedése, illetve az integrált memóriavezérlők fejlettsége.
Az egyszerű olvasási teszt, mint neve is mutatja, egyszerűen a memóriaolvasást méri. Az L2 cache is beleszól az eredménybe, az így kapott érték pedig az „átlagos”, mindennapi memóriaolvasást jelképezi.
Az olvasás szoftveres prefetch-csel egy szoftveres prefetch segítségével méri az olvasást, ezzel, megkerülve az L2 cache-t, valóban csak a maximálisan elérhető memóriaolvasási sávszélességet méri. Ez a módszer a processzor OoO-végrehajtását segíti ki azáltal, hogy előre betölti azokat az adatokat, amelyekre később szüksége lesz a végrehajtó egységeknek, így nem alakulnak ki függőségek és várakozási sorok, tehát gyorsul az adatfeldolgozás. A mindennapi életben ilyennel nem nagyon találkozunk.
Az írás egyszerű lineáris írást mér, az L2 cache sebessége is számít, az eredmény pedig amolyan átlagos, mindennapi írási sebességnek felel meg.
A non-temporal írás a cache-hierarchiát megkerülve, külön erre a célra bevezetett utasítások segítségével mér maximálisan elérhető, tiszta memóriaírási sávszélességet. Ez a módszer nagy mennyiségű adat kiírása során a cache olvasási/írási kényszere alól menti fel a processzort (ugyanis nem kell állandóan felülírni a cache-cellákat, lásd fentebb), így az írási sebesség drasztikusan megnőhet a sima íráshoz képest. A valóságban ezzel sem nagyon találkozni, csak speciálisan olyan feladatoknál, amikor erre van szükség.
Először az egyszálas tesztek futottak: a lineáris olvasásnál 20%-kal, a lineáris írásnál azonban már 50%-kal gyengébb eredményeket produkálva. Persze a Nehalem így is lekörözi mindkét rivális architektúrát.
A két szálon végzett mérés már izgalmasabb, mert valóban arra ad választ, amire kíváncsiak vagyunk, ráadásul asztali környezetben is előfordulhat egy ehhez hasonló szituáció. A Nehalem a szimpla olvasás/írás tesztben jelentős előnyre tesz szert, a Penryn írását már lekorlátozza a rendszerbusz, míg a K10 két memóracsatornája ellenére is mindössze a Penrynnel versenyez - felemás eredménnyel. A szoftveres prefetch olvasás és non-temporal írás tesztben az eredmények jelentős átalakulásokon mentek keresztül, a Nehalem olvasásban iszonyúan lelassul, viszont az írás "kiüti" a mérőórát, mintha a rendelkezésre álló sávszélességből nagyobb prioritást, nagyobb szeletet követelne magának. A Penryn jelentősen belassult, és a Nehalemhez viszonyítva a K10 sem volt túl gyors, de teljesítménye jóval kiegyensúlyozottabbnak bizonyult. Mindenesetre a sima olvasás/írás teszt itt a mérvadó, hiszen ez áll közelebb az általános felhasználáshoz.
A négy szálon végzett memóriateszt már inkább csak a szerverek világában bír különösebb jelentőséggel, de mindenképpen érdekes látni az egyes architektúrák teljesítményét. A kíváncsiságtól vezérelve a Nehalemet itt négy (olvas-ír-olvas-ír) és nyolc szálon (olvas-olvas-ír-ír-olvas-olvas-ír-ír) is leteszteltük; a Hyper-Treadingnek köszönhetően érdekes eredményekre számítottunk, és a sejtésünk be is igazolódott. A szimpla olvasás-írás tesztben négy szálon a Nehalem nagyon szépen szerepelt, mind a négy szál közel azonos sávszélességgel rendelkezett (3400-3700 MB/s), viszont amikor a Hyper-Threading is képbe került, jelentősen felborult az egyensúly, egyrészt a sávszélességek lecsökkentek, másrészt az első-második és negyedik-ötödik szál ismét alacsonyabb prioritást kapott, mint a másik négy. A Penryn itt hozta szokásos formáját, a rendszerbusz erősen visszafogta, a K10 viszont egyenletesen, a Nehalemhez mérten alacsony teljesítményt nyújtott. A prefetch olvasás és non-temporal írás tesztben nem történt sok változás, a Nehalem és a K10 esetében ismét az írás kapott nagyobb prioritást.
A cikk még nem ért véget, kérlek, lapozz!
