CPU VS VGA 2.5: Memória intermezzo

Avagy meglepetések a memóriasebesség kapcsán.

1. rész - Mit eszik egy 9600GT?
2. rész - Mi alá mit tegyünk?
2.5. rész - Memória intermezzo
3. rész - Variációk CPU-limitre

1. Bevezető

Ahogy a sorozat második részében szó volt róla, a 3. rész hivatott megvizsgálni a modernebb CPU-igényes játékokat – ezzel teljessé téve a CPU-VGA összképet. Az utolsó felvonás előkészítése során nagyító alá került a memória hatása is – amíg az első rész CPU-limites eseteiben a memória által hozott / vitt pár FPS-nek igen mérsékelt jelentősége volt (pl. 170 helyett 180 fps várhatóan senkit nem kápráztat el), addig a 30-50 fps-es magasságokban mozogva igencsak számít, ha a memória megfelelő beállításaival akár 5-10% teljesítményt nyerünk. A vizsgálódás hozott néhány elég meglepő eredményt, ezért érdemes egy külön cikket szentelni a témának – a 3. rész pedig innentől kezdve tényleg koncentrálhat a CPU és a VGA viszonyára.

Update 2008.05.26: szerző a kommentek hatására továbbképezte magát a memória strapek és a tRD időzítési tényező kapcsán. Ez számos teszteredmény megváltozásával járt, így valamelyest a következtetések is módosultak.

2. Rövid áttekintés a memória paramétereiről – Intel platform

Egy előzetes megjegyzés: a memóriák sebessége kapcsán az egyszerűség kedvéért a legtöbb cikk eltekint attól, hogy a byte-ok nagyságrendi ugrásai nem 1000-szeres, hanem 1024-szeres szorzót jelentenek. Ezért a 6.4GByte / másodperc sebesség valójában 6.4 milliárd Byte / másodperc, ami 5.96GByte / másodperc. Az összehasonlíthatóság kedvéért ez a cikk is úgy használja a GByte / másodperc terminológiát, hogy milliárd Byte / másodpercet ért alatta.

Tömören és a műszaki részletek (pl. SDR – DDR viszony) igénye nélkül, az Intel platformon a következőktől függ a memória teljesítménye:
1. Az FSB sebességétől
2. A memória-szorzótól (Intelnél nincs köze a CPU szorzóhoz!)
3. Az üzemmódtól (Single Channel, Dual Channel, esetleg egyéb)
4. A memória időzítési beállításaitól
5. A rendszerbusz teljesítményétől

Az első két paraméter összeszorzása kiadja a memória effektív órajelét (pl. egy alapbeállításokkal futó E6750-es CPU és egy DDR2-800-as memória esetén a 333MHz-es FSB-ből és egy 2.4-es szorzóból „készül” a 800MHz), ezt megszorozva a memóriabusz szélességével (64 bit) kapjuk a memória maximális átviteli sebességét (a példa szerint 6.4GByte / sec).

A 3. paraméter kapcsán manapság leginkább a Dual Channel üzemmód dívik: megfelelően összepárosítható memóriákból az alaplapok két memóriacsatornát képeznek, így pl. amikor a CPU „pihen”, mert az egyik memóriacsatorna válaszát várja, akkor átkapcsolhat egy másik threadre / processzre, amely a másik csatornán hozzáfér a memóriához. A megoldásból fakadó elméleti sebesség-duplázódás (a példában 12.8 GByte / sec!) az Intel platformon nagyjából a tündérmesék szintjén mozog, de azért a gyakorlatban a Dual Channel bekapcsolásával 20-40%-os sebességnövekedést el lehet érni.

A memória-időzítésekről: a DDR2-es memóriáknál a 4-4-4-12-es és az 5-5-5-15-ös elsődleges időzítések a legelterjedtebbek (a továbbiakban CL4 és CL5). Itt az első szám (CAS Latency) a legfontosabb, amely azt határozza meg, hogy a memóriaolvasási parancs kiadása után hány órajelciklussal érhető el az adat (folyamatos, vagyis burst olvasás esetén ez az első adatra vonatkozik – ezután ciklusonként érkeznek az adatok). Értelemszerűen az alacsonyabb érték a jobb, a tesztben lesz szó az időzítés hatásairól.
A másodlagos időzítések közül a legfontosabb a tRD érték (egyes helyeken Performance Level néven találkozhatunk vele) – olyannyira, hogy még a CAS Latency-nél is fontosabb. Ez az érték azt határozza meg, milyen késleltetésre van szükség akkor, amikor az x sebességen futó memóriától az y sebességen futó rendszerbuszra kerül az adat. Ideális esetben (pl. egy AMD platformon :) ez az érték 0, ilyenkor nincs extra késleltetés – a gyakorlatban az FSB-től, a CAS Latency-től és a memória-szorzótól függően jellemzően 4 és 12 közötti tRD-vel találkozik a felhasználó. Azaz csak találkozna: a tesztben használt Gigabyte P35 DS3 alaplapnál pl. csak a CTRL+F1-gyel előcsalható haladó BIOS beállítások között található meg a tRD manuális beállítása. Az újabb magasabb kategóriás alaplapoknál már lehet számítani rá, mint standard beállítás – viszont, ha a BIOS-ban a memória-beállítások környékén akad olyasmi, hogy Performance Enhancement, akkor annak állítása várhatóan elsősorban a tRD-re hat. Ezek hajlamosak kissé kiszámíthatatlanul működni – ezért nem árt ellenőrizni, pontosan milyen hatással jár a bekapcsolásuk adott beállítások mellett. Ennek ellenőrzésére pl. a MemSet program kiválóan alkalmas.

5. paraméter: a rendszerbusz teljesítménye ott jön a képbe, hogy ő a memória szolgáltatásának „fogyasztója” – ha a rendszerbusz pl. csak 1GByte / sec adatot tud átvinni, akkor ennél többet senki nem fog látni a memóriából, aki a rendszerbuszon keresztül éri azt el. A fenti példában a rendszerbusz sebessége kb. 10.7GByte / sec – a CPU külső sebessége az FSB 4-szerese (1333MHz), és a 64 bites busz 8 byte átvitelére képes.

Mivel a rendszerbusz és a memória nem szinkronban futnak, a végső átviteli sebesség sajnos nem a két érték közül a kisebb, hanem ennél kevesebb (pl. a fentebb taglalt tRD miatt is) – a tesztből látszani fog, hogy ezt a hatékonyságot melyik paraméterek hogyan befolyásolják.

3. A tesztelés módszere, tesztkonfiguráció

Az elemzés módszere paraméterek szerinti mérés volt – egy mérés-sorozatban egy paraméter változott, a többi pedig fix maradt, így meg lehetett mérni az adott paraméter hatását a memória teljesítményére. A négy mért paraméter: a memória órajele, a memória időzítései, az FSB órajele (amely fix memóriasebesség mellett is hat a teljesítményre, a rendszerbusz sebességén keresztül), ill. a CPU sebessége – ez utóbbi nem kis meglepetést okozott a teszt során, és nagyban hozzájárult ezen cikk elkészüléséhez is.

Mérési alanyként három szintetikus- és egy játékteszt szolgált. A Sandra XI Lite átviteli tesztje, valamint az Everest 2.2 olvasási és írási tesztje mellett bevetésre került a jó öreg Doom 3 standard timedemo-ja is – utóbbi esetben természetesen a CPU-sebesség másképp kell értelmezni, mint a szintetikus tesztekben.

Minden tesztesetre 3 mérés készült, a grafikonokra a 3 eredmény átlaga került.

A tesztkonfiguráció a következő volt:

A tRD feltüntetése a memória-beállítások mellett némi magyarázatot igényelhet. A célszerű az lett volna, ha a mérések a Standard memória-sebességi mód használata mellett készülnek, de sajnos ez a beállítás több helyen is „elrontja” a teszteredményeket: 266MHz-es FSB esetén a 3-as szorzóhoz rendel irreálisan magas tRD értéket, a 333MHz-es esetnél a 2.4-eshez, 400MHz-hez pedig láthatóan nincsenek optimalizálva a beállítások. A Turbo mód bekapcsolása rendbeteszi a 266MHz-es esetet (3-as szorzó esetén a tRD 7 helyett 4 lesz), viszont teljesen kaotikussá teszi a 333-ast (2.4-es szorzó esetén 9 helyett 6 a tRD, míg 2.5 esetén 8), és semmit nem csinál a 400MHz-essel. Ezért a teszt minden beállításához egyedi tRD érték lett rendelve, a következők szerint:
- A tRD ne legyen alacsonyabb, mint a Turbo mód által beállított érték
- A tRD ne legyen alacsonyabb, mint egy azonos FSB-hez és alacsonyabb szorzóhoz tartozó érték (a tRD tipikusan csökkenthető a szorzó növelésével)
- A 400MHz-es határ az olvasott források alapján komoly hatással van a tRD-re, ezért ide 1-gyel magasabb érték lett beállítva, mint az alacsonyabb FSB-jű, 2-es szorzós esetekhez.

Így keletkeztek a táblázatban látható tRD értékek – zárójelben utánuk látható a Standard memória-sebességi mód default beállításai, ill. a Turbo módé is, ha az eltér a Standardtól.

4. Tesztek

A következő 4 szekcióban találhatóak a 4 paraméter szerinti mérések eredményei, némi magyarázattal kiegészítve. Az utolsó csoport kivételével a memóriák végig a 4-4-4-12-es időzítésekkel működtek.

4.1 A memória órajele

A legtöbb teszt a memória órajelének hatása szerint készült. Itt fix az FSB, és fix a CPU sebessége is – viszont három ilyen fix kombináció mellett is meg lettek mérve az átviteli teljesítmények. Az alábbi 3 grafikonon látható a szintetikus tesztek eredménye:

Az első beállításnál jól látható, hogy az Everest szereti az órajel-emelést – mind az 533MHz-ről 666 MHz -re, mind a 666 MHz -ről 800 MHz -re történő ugrás kb. 10% növekedést hoz mind az olvasási, mind az írási tesztben. A Sandra ezzel szemben, míg az első ugrásnál hasonlóan viselkedik, a 666 MHz ->800 MHz emelésből már jóval kevesebbet profitál.

A második grafikonon nincs meglepetés – a harmonizált tRD érték mellett a teljesítmény arányosan növekszik.

A harmadik grafikon szinte tükörképe a másodiknak, némileg magasabb értékekkel.

A Doom 3 esetében a három beállítás ráfért egy grafikonra, bár a jelmagyarázat kissé sűrű lett:

Itt sincs meglepetés, a teljesítmény az órajel-ugrásokkal szépen növekszik.

4.2 FSB-órajel

Az FSB órajel hatásának a mérése volt a legnehezebb feladat, mert nem minden esetben lehetett úgy összevariálni a szorzókat, hogy mind a memória, mind a CPU sebesség fix maradjon. Az eredmények:

Az első két szekció nagyon szépen mutatja, milyen fontos az FSB sebessége –megemelése mind 266MHz-ről 333MHz-re, mind 333MHz-ről 400MHz-re jól megugrasztotta az olvasási teszteket. A Sandra javulása igen látványos, az Everesté kicsit visszafogottabb, de azért jól látható.
Az Everest írási tesztje némileg belerondít az összképbe, nem tudni, mi a baja a 8x333MHz-es beállítással.

A Doom 3 teszt az Everest olvasási teszt eredményével rokon:

… és további kommentet nem igényel.

4.3 CPU sebesség

Most jön az, amire a teszt készítője álmában sem gondolt volna – a CPU sebességének hatása a memória teljesítményére, fix FSB és fix memóriasebesség mellett. Lássuk a szintetikus eredményeket:

Az első tesztre a három 800MHz-es memóriasebességgel készült mérés mellett rákerült kettő olyan is, ahol 833MHz-en ketyegett a memória. Ennek oka az volt, hogy a teszt korábbi verziójában itt látszott nagyon látványosan a 2.5-szeres szorzó negatív hatása, amit aztán a tRD manuális beállításával sikerült megszüntetni.

Az olvasási tesztek a CPU sebességével szépen lassan kúsznak felfelé, az Everest mindkét tesztje kicsit komolyabb eredményt mutat 2.66GHz-ről 3.0GHz-re ugrásnál. Az utolsó eset a magasabb FSB miatt ugrik ki.

A 400MHz FSB-s grafikon kevésbé sűrű:

Az olvasási tesztekben a 2.4GHz-es CPU-sebesség még kevésnek tűnik, viszont a 2.8GHz-es és a 3GHz-es esetek között alig van különbség. Az írási tesztben ezúttal a 3.2GHz-es eset hozza a meglepetést: majdnem 10%-kal lassabb, mint a másik két eset.

Végül lássuk a Doom 3 eredményeit, a már megszokott kisregény jellegű jelmagyarázattal:

A játék sebessége természetesen folyamatosan nő a CPU órajelének növelésével, ill. az 5. oszlop itt is mutatja, hogy a magasabb FSB-t is meghálálja a játék (pedig a 2x416-os esetben a tRD rosszabb, mint a 2.5x333-asban). A grafikon jobb oldalán nincs meglepetés.

Idekívánkozik még egy Doom 3 teszt, amelyben a CPU-sebesség növelésének hatása, ill. a memória-sebesség növelésének hatása összevethető:

A grafikonok elég egyértelműen abba az irányba mutatnak, hogy platform limitált esetben a Doom 3 kb. 50%-50%-ban CPU-, ill. memória-sebesség-limitált.

4.4 Memória időzítések

Az időzítések grafikonjai az eddigiektől kicsit eltérő módszerrel készültek – bár a tesztek nagy része futott CL4-es és CL5-ös beállítások mellett, nem lett volna túl látványos, ha a grafikonokon párosával ácsorogtak volna a 3D oszlopok. Ezért inkább a korábbi grafikonok olyan változatai jelennek meg itt, ahol a CL5-ös mérések bele vannak „szőve” a CL4-esek közé – a grafikonok jelmagyarázatából érthetőbb, mit is jelent ez.

Változó memória-sebesség mellett így fest a kép:

533MHz után egy nagyobb ugrás van, de utána az értékek szép egyenletesen nőnek, tehát a jobb időzítési beállítás kb. lefelezi a távolságot az egy lépcsővel magasabb memória-órajelhez képest.

Változó FSB-nél kicsit más a helyzet:

… lényegesen kisebb hatást lehet elérni az időzítések javításával, az FSB növelése sokkal jobb eredményt hoz. Az Everest írási teszt mindkét időzítés mellett hozza a 2.4x333MHz-es memóriasebességnél korábban már látott anomáliát.

Végül változó CPU-sebesség mellett ismét fordul a kocka:

… ami annyiból nem meglepő, hogy a CPU-sebesség változásának magasabb órajeleken kevés ráhatása van a memória teljesítményére.

A Doom 3 grafikon sok meglepetést nem tartogat, azt leszámítva, hogy a jelmagyarázat tekintetében a korábbi rekordokat is megdöntötte:

Mindhárom tesztcsoportból jól látszik, hogy az időzítések javításával 5-8fps javulás érhető el – ez egyfelől nem sok, másfelől viszont ingyen van, ha a memória hajlandó CL4-ben menni. Egyes esetekben a jobb időzítés hatása majdnem eléri a magasabb beállítást rosszabb időzítés mellett (pl. a memória-sebesség 666MHz-es és 800MHz-es értéke között).

Végül, bár a tesztnek nem célja a tRD-csökkentés hatásának elemzése, az alábbi két grafikonon egy-egy példa látható erre:

Az első grafikonon a változó CPU sebesség hatása látható, a tesztben használt tRD=8 beállítás mellett az alaplap által beállított default tRD=11 értékkel kiegészítve – bal oldalon a lassabb, jobb oldalon a gyorsabb eset. Míg a Sandrában 5% javulást mutat a tRD=8 eset, az Everestben közel 10%-ot jelent a jobb tRD beállítás.

A Doom 3 szintén 5% körüli javulást hoz, de nem szabad elfelejteni, hogy itt a memória csak a limitáció 50%-át adja – az alacsonyabb tRD hatása tehát itt is jelentős.

5. Konklúzió

Egy biztos: ez a teszt bővelkedik érdekes eredményekben. Lássuk őket sorban:

Az első fontos dolog, ami a tesztelés egészére vonatkozik, hogy a különféle teszteszközök erősen eltérő eredményeket is tudnak produkálni, és egész váratlan paraméterek is befolyásolhatják őket (ld. CPU sebesség) – erre nem feltétlen számít az ember egy olyan egyszerűnek tűnő esetnél, mint a memória teljesítményének megmérése. A fenti tesztekben az Everest olvasási tesztje inkább a memória órajelének növelését hálálta meg, a Sandra pedig az FSB-t szerette jobban. A teszt összképe alapján a Doom 3 inkább az Everest viselkedéséhez áll közel.
Említést érdemel még az Everest írási tesztje, amely időnként elég hektikusan viselkedett – ennek az okát nem sikerült kideríteni, úgyhogy ezeket az eredményeket érdemes némi fenntartással kezelni.

Az feltehetőleg senkit nem ért váratlanul, hogy a memória órajelének emelésével viszonylag konzekvensen nő a memória teljesítménye – az már érdekesebb, hogy korántsem mindegy, hogyan emeljük az órajelet.
A tesztek megcáfolták azt a közismert mítoszt, hogy az FSB és a memória között egész számú szorzót célszerű használni – a P35-ös Northbridge-nek jól láthatóan mindegy, milyen szorzót használunk, amennyiben gondoskodunk róla, hogy a tRD beállítás megfelelő legyen. (A teszt korábbi verziójában a BIOS által helyenként furán beállított tRD értékek miatt a 2.4-es szorzó nagyon jónak, a 2.5-ös szorzó pedig nagyon gyengének tűnt.)

Az sem meglepő, hogy az FSB emelése a teljesítmény növelését hozta, a mértéke talán már inkább – azonos memória-sebesség mellett a Sandra helyenként 10%-nál is többet profitált egy 20%-os FSB emelésből.

A másik „lerombolt” mítosz a jobb időzítésekkel kapcsolatos – bár a CL4-es időzítés konzekvensen jobb eredményt hozott, mint a CL5-ös, a jobb időzítés használatával jó esetben is csak megközelíteni sikerült a magasabb órajeles eseteket, de általában az „alacsonyabb órajel + CL5” és a „magasabb órajel + CL5” esetek közé kb. középre érkezett az „alacsonyabb órajel + CL4” beállítás. Magasabb FSB mellett pedig alig érződött a jobb CL hatása. Azaz célszerű az alacsonyabb időzítést használni, de azért csodákat nem érdemes várni tőle.
A tRD csökkentése szintén látványos eredményeket hoz, az Everest és a Doom 3 esetében még inkább, mint a Sandráéban.

A számtalan teszteset által festett kép még egy következtetésre lehetőséget ad: nagyon szépen körvonalazza, milyen memória-beállításokat érdemes használni a P35-ös platformon. Miután a memória maximális sebessége általában adott, a többi paraméterrel a következők szerint érdemes játszani:
Megfelelően beállított tRD mellett a magasabb FSB – alacsonyabb szorzó kombinációk jobban működnek, annak ellenére, hogy egy alacsonyabb FSB – magasabb szorzó kombinációhoz akár lényegesen jobb tRD is tartozhat (pl. a tesztben 3x266 esetén 4, 2x400 esetén 8 volt a tRD, a második eset mégis 15-25%-kal gyorsabb volt a szintetikus tesztekben, és 10%-kal a Doom 3-ban).
Az alacsonyabb CAS Latency használata ajánlott, de jelentős FSB áldozatot nem érdemes miatta hozni, különösen magasabb sebesség esetén.

Kérdés még, mennyire általánosíthatóak a fenti eredmények. Az szinte biztos, hogy az AMD platformra, ill. az nForce chipsetes Intel platformra nem érvényesek – a többi Intel platformra viszont várhatóan alkalmazhatóak. Persze, néhány ellenőrző mérés sosem árt – célszerűen a tartósan használni kívánt beállítások mellett.

7. Köszönetnyilvánítás

A cikk az első megjelenés után némi redesign-on esett át – itt köszönet illeti Brae-t a tRD-vel kapcsolatos információkért, és fagy53-at a kontroll tesztekért. Emellett hála és köszönet a http://www.tweakers.fr oldalnak a MemSet utility-ért.

A tesztcsomag instrumentálásában ismét nélkülözhetetlen segítséget nyújtott az AutoIt v3 – áldassék érte Jonathan Bennett keze, most már háromszorosan is! (http://www.autoitscript.com/autoit3/)

És szokás szerint köszönet The DJ-nek és t|-|om-nak a képefeltöltő oldalért! (http://www.dj-beat.hu/phimage)

Folyt. és bef. köv. (de most már tényleg!)