:

Szerző: Bodnár Ádám

2001. november 29. 19:01

Hiba csúszott az AMD számításaiba

Az AMD az Athlon XP processzor bejelentésekor hozta nyilvánosságra új paradigmáját, amely az addig elterjedt teljesítmény=órajel felfogást hivatott megváltoztatni. Azonban az AMD által javasolt új egyenlet semmivel nem visz közelebb a tényleges teljesítményhez. Cikkünkben megmutatjuk, miért.

Az AMD az Athlon XP processzor bejelentésekor hozta nyilvánosságra új paradigmáját, amely az addig elterjedt teljesítmény=órajel felfogást hivatott megváltoztatni. A vállalat által széles körben propagált elmélet szerint a processzorok teljesítményét nem lehet pusztán az órajelükkel mérni, ami természetesen igaz is.

Azonban az AMD által "javasolt" új egyenlet, a

    teljesítmény=órajel*órajelenként végrehajtott utasítások száma
legalább olyan messze áll a valóságtól, mint a fent említett ekvalizáció. Cikkünkben megmutatjuk, miért.

Teljesen természetes, hogy az AMD nagy hangsúlyt fektet az órajelenként végrehajtott utasítások számára (instructions per clock, röviden IPC), hiszen a cég Athlon processzorai ebben kétségtelenül jobbak, mint a rivális Pentium 4. Igaz, ami igaz, a Pentium 4 még a Pentium III-nál is kevesebb utasítást hajt végre egy órajelciklus alatt, de ezt ellensúlyozza a magasabb órajele. Visszatérve az AMD-hez, a vállalat szerint az IPC és az órajel segítségével pontosan leírható egy processzor számítási teljesítménye. Azonban ez távolról sem igaz.

Egy adott processzor -- vagy számítógép -- teljesítménye a gyakorlatban az alkalmazások futási sebessége. Vagyis azt kell vizsgáljuk, egy adott program mennyi idő alatt fut le a rendszeren. Az AMD által favorizált egyenlet formájába öntve ez a következőképp írható le:

    teljesítmény=1/futási idő
A program futási ideje pedig a végrehajtandó utasítások és a végrehajtott utasítások hányadosa, azaz
    futási idő=programutasítások/végrehajtott utasítások
Az egy másodperc alatt végrehajtott programutasítások összessége az, amelyet az AMD egyenlete leír, azaz
    végrehajtott utasítások=órajel*IPC
A fenti egyenleteket összevonva az alábbi képletet kapjuk:
    teljesítmény=(órajel*IPC)/programutasítások

A fenti képletből látható, hogy egy processzor számítási teljesítménye az órajel vagy az IPC növelésével illetve a rajta futó alkalmazás utasításainak csökkentésével, optimalizálásával növelhető. Ennek fényében azt kell mondjuk, hogy az AMD eredeti képlete számos olyan körülményt nem vesz figyelembe, amelyek egyre inkább meghatározzák a modern processzorok számítási teljesítményét. Lássuk, melyek ezek.

[oldal:A spanyolviasz és az ő feltalálása]

A kaliforniai chipgyártó által propagált összefüggés mindaddig pontosan adja meg két processzor egymáshoz viszonyított számítási teljesítményét, ameddig azok teljesen azonos felépítésűek és azonos program fut rajtuk.

Azonban itt jönnek be a képbe a -- főként a nagy számítási teljesítményt igénylő multimédiás és grafikus alkalmazások futtatását felgyorsító -- SIMD (single instruction multiple data) utasításkészletek, mint az MMX, SSE vagy az AMD által alkalmazott 3DNow!. Mivel ezek az utasítások bizonyos processzorokban jelen vannak, másokban pedig nincsenek, és processzoronként eltérő módon hajtódnak végre, ezért a programutasítások száma és végrehajtási ideje processzorról processzorra változhat.

Vegyük azt az egyszerű esetet, amikor az egyik processzor rendelkezik pl. SSE utasításkészlet támogatással, a másik pedig nem. Könnyen előfordulhat, hogy ugyanaz a program az SSE-t támogató processzoron jóval kevesebb utasítást igényel, mint a másikon, és a két processzoron mégis azonos idő alatt hajtódik végre. Az AMD értelmezése szerint ilyenkor az SSE nélküli processzor teljesítménye nagyobb, de a valóságban a két chip egyforma gyorsan hajtotta végre a programot -- ergo a számítási teljesítményük megegyezik.

Akkor miért nem használunk olyan tesztprogramokat, amelyekben nem szerepelnek processzor-specifikus SIMD utasítások? Azért, mert a benchmark program lényege, hogy minél pontosabb képet adjon egy adott chip valós alkalmazások futtatásakor nyújtot teljesítményéről. Ha a benchmark program nem veszi figyelembe az adott processzor egyedi tulajdonságait, amelyek az alkalmazások futását befolyásolják, az a benchmark egyszerűen rossz.

Az egyes utasítások végrehajtási ideje egymástól eltérő -- bizonyos egyszerű egész utasítások a Pentium 4-en a kétszeres órajelen üzemelő ALU-k miatt akár fél órajelciklus alatt lefutnak --, sőt egy utasítás végrehajtási ideje kontextustól függően változhat, például attól függően, hogy az operandus megtalálható-e az első vagy másodszintű cache-ben. Ha egy programrész által igényelt adat csak a virtuális memóriából tölthető be, egy utasítás végrehajtása akár több millió órajelciklust is igénybe vehet.

Könnyen belátható, hogy az IPC a futtatott utasítások, azaz a program függvénye. Ráadásul ez mindössze egy statisztikai érték, amely a gyakorlatban nem mérhető, csupán egy adott alkalmazás futtatása után, a programkód és a végrehajtásához szükséges idő ismeretében kiszámítható. Mint ilyen, a teljesítmény mérésére vagy meghatározására bármilyen összefüggésben tökéletesen alkalmatlan.

Az AMD a teljesítmény=órajel*IPC egyenlettel igazából csak újra feltalálta a spanyolviaszt, azaz a MIPS (million instructions per second) értéket, amelyet még az 1960-as években vezettek be, és amely a fent említett problémák miatt már a 90-es évek közepén teljesen elavultnak számított.

[oldal:Itt a megoldás!]

Bizonyára sokan most azt mondják, miért nem keresünk olyan programokat, amelyek a valódi alkalmazásokhoz hasonló utasítássorozatokat tartalmaznak, és miért nem használjuk ezeket a teljesítmény meghatározására? A valódi alkalmazásokhoz pedig a leginkább hasonló programok -- maguk a valódi alkalmazások. Nyilvánvaló, hogy egy processzor vagy számítógép programfuttatási sebességét csak ilyen szoftverekkel lehet mérni.

Természetesen mi sem találtuk fel a spanyolviaszt. Számtalan széles körben elterjedt alkalmazás létezik, amelyet teljesítménymérésre használnak -- ezeket nevezhetjük SYSmarknak vagy Quake-nek, esetleg Primordiának, teljesen mindegy. Van azonban egy széles körben elterjedt, a legnagyobb gyártók által is használt "egyetemes", gyakorlatilag ipari szabványnak számító tesztprogram, ami nem más, mint a SPEC (Standard Performance Evaluation Corporation).

A SPECcpu a processzorok számítási teljesítményét hivatott mérni. A programcsomagban külön helye van a fixpontos és a lebegőpontos sebességet mérő programoknak, amelyeknek közös tulajdonsága, hogy nyílt forrásúak, platformfüggetlenek és valódi problémák megoldására készítették őket. A SPECint csomagban tömörítők, fordítóprogramok, szövegszerkesztők találhatók, a SPECfpu alkalmazások között pedig többek között geometriai és fizikai modellezés, végeselem-analízis valamint grafikus alkalmazás futtatása.

Hogy a SPEC benchmark mennyire elterjedt, mi sem mutatja jobban, hogy a csúcskategóriás, sokezer dolláros, szerverekbe szánt processzorok (Sun UltraSPARC, HP PA-RISC, IBM Power sorozat, stb.) számítási teljesítményét is ezzel mérik a cégek. Vérre menő csaták dúlnak a gyártók között, kinek a processzora éri el a legnagyobb SPEC értékeket, gondoljunk csak a Sun Microsystems múlt heti bejelentésére, amely az UltraSPARC III kiemelkedő SPEC teljesítményét méltatta. Természetesen nem csak a legfelső kategóriás chipekről állnak rendelkezésre SPEC adatok, a www.spec.org weboldalon a PC-s világban is használt Intel és AMD processzorok benchmark-eredményei is elérhetők.

Az AMD-nek egyáltalán nincs szüksége a felhasználók oktatására, félrevezető egyenletekre vagy a True Performance Initiative kezdeményezésre, hiszen láthatóan nyitott kapukat dönget.

Szólj hozzá a fórumban!

Milyen technológiai és munkaerőpiaci hatások érhetik a backendes szakmát? Május 8-án végre elindul az idei kraftie! meetup-sorozat is (helyszíni vagy online részvétellel).

a címlapról

Hirdetés

Security témákkal folyatódik az AWS hazai online meetup-sorozata!

2024. április 26. 17:28

A sorozat május 28-i, harmadik állomásán az AWS-ben biztonsági megoldásait vesszük nagyító alá. Átnézzük a teljes AWS security portfóliót a konténerbiztonságtól a gépi tanulásos alkalmazások védelmén át, egészen az incidenskezelésig.