Bevallom, bacsis szervertesztes cikkét olvasva én is a fanyalgók táborát szaporítottam. Viszont onnan jött az ötlet, hogy kellene egy komolyabb szerver vasas tesztet csinálni. Nem finoman, durván.

Update: Lelkes fórumtársaknak köszönhetően érkezett eredmény Opteronról (2214E), fog jönni E5440-es Xeonról, a régészek kedvéért csináltam egy Celeron 800-as gépen is, és lesz T9300-as Core2 is. Az új sorozat grafikon elkészültéig kérek egy kis türelmet. Meg esetleg ötleteket, hogyan lehetne ennyi adatot valami átláthatóbb formában megjeleníteni.

Először is pár szó a tesztekről. Most nem lesznek itt a megszokott benchmark programok. Zúzás ugyan lesz, de nem FPS játékokkal, hanem legfeljebb a vasak pörkölésével. Van egy rossz hírem: mégcsak klasszikus szerver benchmark programok sem lesznek. Egy konkrét feladathoz készítettem tesztprogramot, annak az eredményeiből fogok mazsolázni, tehát egy valós alkalmazás valós rutinjairól van szó. Ez a teszt fullHD képeken végzett műveletekből áll. A képek mérete (1920*1080, 32 bit) elég volt hozzá, hogy a jelenlegi processzorok egyikén se férjen bele a cache-be (de minden teszt után egy külön rutin is gondoskodott a cache beszemeteléséről). A számítások jellegzetessége, hogy a 7,9 MiB adaton memóriafolytonosan ment végig, tehát egy okos prefetcher sokat hozhatott a konyhára. Persze némelyik tesztben ezt direkt igyekeztem elrontani az olvasási sorrend felborításával. A teszteket kifejezetten egyszálas végrehajtásra készítettem, kivéve az utolsót, ahol épp azt vizsgáltam, hogy rendesen skálázódnak-e a teljesítmények a magok számával.

Az összes grafikon FPS-ben (képkocka/másodperc) értendő, tehát minél nagyobb, annál jobb.

Megjegyezném, hogy a viszonyítási alap a rutinok C-ben készült változata, amit Visual Studio 2005-tel fordítottam le, az összes értelmes optimalizálást bekapcsolva, kiegészítő utasításkészleteket engedélyezve. A gépi kódú rutinokat magam csináltam, tehát esetleg nem optimálisak. Bizony, manapság az optimalizálás már nem az utasítások órajelciklusainak számolgatásából áll, mint a régi szép 386-os időkben, hanem a párhuzamos végrehajtóegységek minél jobb etetéséből, és a cache minél jobb előre feltöltéséből.

A versenyzők

Minden gépben párban voltak a memóriamodulok; a szerverekben Kingston, az asztaliakban Kingmax. Minden alap órajeleken és időzítésekkel. Az éjjel-nappal elvárt folyamatos működés miatt csapok a kezére, aki túlhúzással próbálkozik.

Írás

Vágjunk hát bele! Bemelegítésnek egy alap gyakorlat: nyers írási sebesség, a memória kinullázása. Az x86 assembly, MMX és SSE rutinok között nem volt mérhető különbség. Úgy látszik, a Microsoft programozóinak ez mégsem volt olyan triviális feladat, mert az ő könyvtári verzióik 50-200%-kal lassabban futottak.

Nagy meglepetések azért nem értek minket. Az Athlon hozta a kortárs Xeonok verését (nem kicsit, nagyon); látjuk az egyes generációkon belüli közel órajel-arányos sebességet; és a gyorsulást a generáció váltásokkal.

Read-modify-write

Bonyolítsunk egyet! Kiolvassuk az adatot, belepiszkálunk egy kicsit, majd visszarakjuk ugyanoda. Esetünkben ez annyiból állt, hogy a 32 bites számok felső byte-ját (alfa csatorna) telire állítottam. Itt a Microsoft compiler-írói szépítettek valamennyit, mert a C és az x86 verzió közel azonos sebességgel futott. Az MMX és SSE rutinom meg csak a Prestonia magokon hozott mérhető gyorsulást.

Ami az izgalmas az előző teszt eredményeivel összevetve, hogy a memóriavezérlők és -csatornák architektúrális különbségeinek ellenére az asztali/laptop processzorok mindegyike 1,6-szoros körüli lassulással oldotta meg ezt a feladatot. A villanykályha Xeonok viszont sokkal jobban megszenvedték. Érdekes, hogy míg az egyutas E5310 volt a leggyorsabb, az E5335 kétutas változatban még a magasabb órajel ellenére is csúnyán kikapott. Hogy a második foglalat memóriaforgalma disznólkodott bele a cache-ekbe, vagy másról van szó, azt majd megmondják az okosak.

Másolás

Harmadik feladat a klasszikus memória másolás egyik helyről a másikra. Itt egy jólirányzott prefetch-kezeléssel szintén a dupláját hozhatjuk gépi kódban a Microsoft könyvtári változatának.

Az Athlont itt is csak a nagyobb órajelű Core2-ok nyomják le. A szerverprocik ugyan csúnyán kikapnak, de ez az alacsonyabb órajel eredménye. A kétutas Clovertown ebben a feladatban is gyengébb valamivel, mint azt órajele alapján várhatnánk tőle. Az egyetlen érdekesség a két asztali Core2 Duo nagyon közeli eredménye, itt az E6850-esbe rakott memóriamodulok sebességére gyanakszom.

Nagyítás

Ez is egy egyszerű feladat, de kicsit nagyobb terhet ró a cache-logikára. Nem teszünk mást, mint egy képet vízszintesen és függőlegesen is duplájára nagyítunk. Ebben semmi pixelenkénti számolás sincs. Minden olvasáshoz négy írás tartozik, így valamivel ritkábban kell váltogatni a busz-irányt, mint a sima másolásnál. A kimeneten a sorok duplázása viszont borítja az eddigi folytonos memória-hozzáférést.

Az eredményen már nem is csodálkozunk: Az AMD körülbelül a másolás sebességét hozza, a régi Xeonokat büntette ez a teszt, a Core2 magok viszont kivirultak.

Színtér-konverzió

Szép, hogy ezeket leteszteltük, de értelme közvetlenül nem volt. Az időnek viszonylag kis részében csinálunk ilyen feladatokat, az erőforrások javát a számítások kötik le. Kezdjük ebből egy egyszerűvel: 4:4:4-es RGB32 pixelekből (minden képpont egy 32 bites adat, amiből minden csatorna 8 bites) varázslunk 4:2:2-es YUV képet (itt a színkomponensek vízszintesen felezett felbontással vannak, így 32 bitre két pixel fér el). Maga az RGB-YUV átszámítás egy sima lineáris transzformáció.

Az első adag mérést egy buta rutin csinálta. Ebben a nagykönyv szerint van megírva a konverzió, lebegőpontos számításokkal. Az új Xeonok itt már kezdenek valamit megvillantani abból, hogy miért is kerülnek sokszorosába az asztali társaiknak. Míg a régi Xeonok itt is már csak köhécselve bírják tartani a tempót, szegény Athlont meg állva hagyják Core2-es társai, amin nem lepődünk meg a lebegőpontos végrehajtóegységek ismeretében.

A második menetben némileg okosabban esünk a problémának: előre kiszámoljuk a szorzásokat, és segédtáblázatokat használunk. Így a pontunk nem lebeg annyit, viszont sok indexelt memóriahozzáférésünk lesz, sok címszámítással, és sok cache-be rakandó adattal.

Szépen visszatértünk az órajel-arányoshoz közelítő eredményekhez (a régi Xeonok szokásos buktájával). Felhívnám a figyelmet még arra, hogy az Irwindale Xeonnak mennyire nem fekszik a táblázat. Igaz, hogy így is duplájára gyorsul a favágó módszerhez képest, de mit ér ez a régebbi testvérei hatszoros gyorsulása mellett?

Képek mixelése

Ebben a feladatban két képet keverünk össze valamilyen arányban. Ilyen látható például a videók mixelésekor, amikor egyik snittből a másikba váltunk fokozatos átmenettel. A képlet egyszerű: x(új) = [x₁·α + x₂·(255–α)]/255.

Lebegőpontosan az árbajnok Athlon egyszerűen lealázza az úri mezőnyt. A táblázat alkalmazása itt is sokat segít, és visszajutunk a papírformához; az új Xeonok generációváltása nem ér semmit, órajel-arányosan maradnak alul az öregekkel szemben.

Ráalfázás

Itt annyiban nehezedik a feladat, hogy amit rárakunk a háttérre, az már eleve részben átlátszó (van nekije alfa csatornája). Például megfeliratozunk egy filmet, kirakunk a sarokba egy logót, egy (18)-as karikát, vagy a fél NCIS-t letakarjuk a Kiválasztott reklámozásával. A képlet nehezedik, mert figyelembe kell venni a felső réteg átlátszóságát is, ami képpontonként változik: x(új) = [x₁·α·α₁ + x₂·(255–α·α₁)]/255².

A mixeléshez hasonló elrendezésűek a grafikonok. Felhívom még a figyelmet az eredmények abszolút értékeire: Még a gyorsított módszerrel is lassúak vagyunk a rendes valós idejű lejátszáshoz. És akkor még semmi mást nem csinált a gép, nem tömörített ki/be MPEGet. (Igaz, egy videóműsort nem is szoktak teljes képernyős grafikával letakarni.)

Összealfázás

Az élvezetek netovábbja: amikor részben átlátszó rétegeket növesztünk össze úgy, hogy a végeredménynek is tartalmaznia kell az átlátszósági információt. x(új) = [x₁·α·α₁ + x₂·α₂·(255–α·α₁)]/[255²·α₂]. Le kell kezelni a speciális eseteket (üres α₂), és a „háttér” új alfáját is ki kell számolni.

Ha kicsit végiggondoljuk a szükséges számításokat (vagy a teszt eredményeket nézve a sebességeket), egyből világos lesz, a játékokban miért inkább a nagyobb felbontású számolást (AA) választják ehelyett. Pláne, hogy az párhuzamosítható, alfázva pedig meg kell várni a hátrébb levő felületek elkészültét. Egy füves réten nyilván nem valósítható meg a fűszálak mélység szerinti egyenkénti renderelése a masszívan párhuzamos feldolgozás helyett.

Thread-stressz

Semmi más, mint az alfázás, egyre több threadben. Minden szálnak megvannak a saját memóriaterületei, tehát azt szimuláljuk, hogy egyszerre több képet számolunk. „Gondolkodás nincs, enyém lesz a kincs.” Az nyer, aki adott idő alatt a legtöbb képet tudja kiszámolni összesen, az összes fizikai és logikai magját bevetve. És azt is tudjuk vizsgálni, hogy vajon ez az érték hogyan változik, ha több magot pakolunk a gépbe.

Látszik, hogy ebben a szerepkörben a HyperThreading mintha ott sem lenne. Hiába van 4 logikai processzorunk, végrehajtóegységből nem rakott mögé ennyit az Intel, így két szálnál megáll a skálázódás. A Windows 2000 meg ugye még nem is tud a HT-ről, szóval két threadet képes ugyanazon fizikai mag két logikai procijára kiosztani. Mármint képes lenne, ha nem kapcsoltam volna ki a HT-t. Az érdekesség kedvéért azért csináltam róla diagramokat. A kéken HT engedélyezve, Windows 2000, a lilán egy HT nélküli gép látható. Három szálat a Windows 2000 simán szétoszt darabra a négy logikai mag közül az első háromra, aztán a két peches küzdhet a fizikai végrehajtóegységekért. Az ütemező bemutat nekünk a középső ujjával.

A négymagos procik gyönyörű lineáris teljesítménynövekedéssel jutalmazzák, ha egyre több szálat bízunk rájuk. Persze csak amíg el nem fogynak a magok, attól kezdve hiába is erőlködünk, az összes mag csúcsra van járatva. Ami viszont számomra meglepetést jelentett, hogy a 2*4 fizikai magos gépben is megállt a tudomány a 4 threadnél. Hogy emögött a Microsoft mesterkedését sejtsem-e, nem tudom. Sima Windows 2000 Server futott alatta, ami felismerte mind a 8 magot, de attól még lehet, hogy valami licenszelési okból az ütemező csak legfeljebb négynek hajlandó egyszerre munkát adni. Ezt meg majd moonman jobban tudja.

Ha valaki hozzáfér legalább 8 magos vashoz, amin újabb rendszer fut, szívesen átküldöm a tesztprogramot. A teszt természetéből adódóan viszont csak olyan gép jó, amin nem fut más feladat. Ha a brutális threadek beindulnak, még a kurzor sem reagál, nemhogy a titkárnők PowerPointos leveleinek kiszolgálása.

Konklúziók

Különösebben nincsenek. Szándékosan hasonlítottam össze almát körtével, és görögdinnyével. A régi Xeonokról eddig is tudtuk, hogy már elrepült felettük az idő vasfoga. Az Athlonok és a Core2-k viszonyáról annyi írás született már, hogy meg lehetne tölteni a /dev/null-t. Az új Xeonok meg hozzák a Core architektúra vívmányait, csak alacsonyabb órajelen, így alacsonyabb szálankénti teljesítménnyel. Ezekre a videofeldolgozási feladatokra tehát a legjobb szívvel valamelyik négymagos asztali processzort tudom ajánlani, szerver vasra felesleges költeni (kivéve ha nekünk írják ki a közbeszerzést).

A citrom-díj az Irwindale Xeonnak jár. Újabb, drágább modell, magasabb órajelen, mégis sokszor kikap régebbi, lassabb (?) Prestonia testvéreitől. Az meg egyenesen megszégyenítő, amikor egy 1,2 GHz-en járó ULV notebook proci döngöli a földbe.

Intel Core2 Duo E6850
AMD Athlon64 X2 3800+

A tesztelt rendszereket a munkahelyem biztosította számomra. No nem jófejségből, hanem hogy engem dolgoztassanak.