64 bites processzorok

Már több mint négy éve jelent meg az első 64 bites x86-os processzor, az Athlon 64, mégsem foglalkoztunk különösebben a 64 bites kiterjesztés témájával. Minek az, mire jó, és különben is, mi az? Amikor az AMD előállt az Athlon 64-gyel, még nem vehettük biztosra, hogy mi fog történni, hiszen aki kicsit is jártas volt a témában, tudhatta, hogy az Intel bizony másképpen képzelte el a 64 bitre való migrálást. És ha az Intel valamit elképzel, akkor az az esetek többségében később úgy is lesz. Ezúttal viszont nem jött be a papírforma.

Az Intel 1978-ban legyártotta az első 8086-ost, az első 16 bites x86-os processzort. 16 bites volt, mert a belső regiszterkészlet 16 bit méretű adatok tárolására volt képes, és a végrehajtó egységek már fel tudtak dolgozni 16 bites adatokat (a memóriacímzés 20 bites volt, de ez most mellékes). Egy évvel később az IBM PC-ben a 8088 debütált, mint a 8086 keskenyebb (16 helyett 8 bit széles) adatbusszal ellátott változata, és gyakorlatilag innentől kezdve számítjuk az x86 felemelkedését. Ezután jött a 286-os, amely a „bitesség” kérdésében nem nyújtott újat, de jóval több memóriát volt képes megcímezni. 1985-ben elkészült az Intel 386DX, az első 32 bites x86-os processzor. 32 bites volt, mert regiszterkészlete 32 bit méretű adategységek tárolására lett felkészítve, ráadásul már 32 biten címezte a (maximum 4 GB) memóriát is, így akkortájt igazi fenevadnak számított. A számítástechnika ezekben az időkben nem fejlődött olyan gyorsan, mint mostanság, ezért a 386, később a 486 és a Pentium egyes verziói egy–három év különbséggel debütáltak.

Szépen telt-múlt az idő, míg 1989-ben az Intel mérnökeinek agyából kipattant az ötlet, hogy kreálni kellene egy teljesen új, 64 bites architektúrát. Ennek okát két tényezőben látták: egyrészt ekkor már javában folyt az első x86-os szuperskalár processzor fejlesztése, és úgy gondolták, hogy az x86-os architektúrák a későbbiekben túlságosan komplexszé válnak, ami gátat fog szabni az órajelemelésnek, így a teljesítménynövelésnek. Másrészt Moore törvényéből kiindulva azt gondolták, hogy 10 évvel később olyan tranzisztorszám-büdzsé áll majd rendelkezésükre, amiből könnyedén kigazdálkodhatnak majd egy nagyon erős, utasításszinten párhuzamosított architektúrát. Ezért az Intel 1989-ben elkezdett dolgozni az EPIC-en, amely a mai IA-64 alapjául szolgál az Itanium processzorokban. Erre később még visszatérünk.

Az évek folyamán egyre több architektúrába építették be a 64 bit támogatását, a MIPS 1991-ben, a DEC 1992-ben, a SPARC 1995-ben, a PowerPC 1997-ben, a Power 1998-ban gazdagodott ezzel, de az x86-ról nem szóltak a hírek. Ehelyett az Intel 94-ben tudomásunkra hozta, hogy dolgozik az IA-64-en, melyet az x86 leváltójaként vizionált. Az Intel úgy tervezte, hogy mint az x86 megalkotója, ő lesz annak eltiprója is, és helyette az IA-64-et fogja befuttatni. A probléma ezzel csupán csak az volt, hogy az x86-alapú processzorok az asztali PC-kben egyre csak terjedtek, ezért az x86 eldobásával szükségszerű lett volna az összes már megírt alkalmazás újraírása, újrafordítása. Ez természetesen senkinek nem lett volna ínyére, hiszen csak azért, mert az Intel azt mondja, nem öltek volna újabb milliókat már megírt alkalmazásokba. Ráadásul ekkor már nem csak az Intel gyártott x86-os processzorokat, ott volt az AMD, a Cyrix, később VIA stb.

Ismét ugorva picit az időben, 1999-be jutunk, amikor az Intel nyilvánosságra hozta a IA-64 utasításkészletet (ISA), és már azt hihették, hogy minden rendben megy, amikor az AMD előállt az x86-64 ötletével. Az Intelnek ennek ellenére is eltökélt szándéka volt az x86 leváltása, ezért az Itaniumot úgy tervezte meg, hogy az x86-tal kompatibilis legyen. Igaz, az Itanium sebessége x86-os kódot futtatva egy Pentiuméval egyezett meg, de ez nem okozott gondot számukra, mert csak egy átmeneti időszakban lett volna szükség erre az emulátorra, később az IA-64-gyel az Intel teljesen uralma alá vette volna a PC-piacot, így mint egyedüli és kizárólagos IA-64-tulajdonos, busás pénz ütötte volna a markát, miközben a kisebb processzorgyártók eltűntek volna a süllyesztőben. Az Intel terve meghiúsult, és ennek egyedül az AMD az oka, hiszen az AMD állt elő az x86 64 bites kiterjesztésével, amellyel most közelebbről is megismerkedünk.

Hirdetés

Mitől 64 bit a 64 bit?

Amikor arról van szó, hogy egy adott processzor 16, 32 vagy 64 bites, az mindössze annyit jelent, hogy az általános célú (GP, azaz general purpose) regiszterek 16, 32 vagy 64 bit szélesek, azaz ennyi egymás mellett elhelyezkedő 1-est és 0-t képesek eltárolni egy egységként. Ebből következően a processzor végrehajtó egységei (VE) képesek az adott szélességű adatok feldolgozására. Remélhetőleg a bináris számrendszert a Prohardver! olvasóinak már nem kell bemutatni, de ha már itt tartunk, akkor megemlítjük, hogy 32 biten – ha nem alkalmazunk különféle számábrázolási trükköket – 2³²–1-ig lehet elszámlálni, míg egy 64 bites processzor esetében ez az egész szám maximálisan 2⁶⁴–1-re emelkedik. A regiszterek felelősek az egész számok és a memóriacímek (melyek egyébként ugyancsak egész számok) tárolásáért. Ezek a processzorban található, nagyon kis méretű memóriarekeszek, melyek a processzor órajelén járnak, ebből következően a központi egység gyakorlatilag egyetlen órajel alatt képes belőlük adatot kiolvasni, vagy beléjük adatot írni, tehát a leggyorsabb memóriáról van szó, amivel találkozhatunk egy rendszerben. Amikor 64 bites programról vagy kódról beszélünk, akkor az annyit jelent, hogy az a program 64 bites adatokkal dolgozik. Ugyanez igaz az utasításokra is, a 16, 32 vagy 64 bites utasítások 16, 32 vagy 64 bites adatokon, operandusokon végeznek el különböző műveleteket.

32 bit

Megpróbáltuk egyszerűen ábrázolni, hogy miről szól ez az egész. Amikor elindítunk egy alkalmazást, az a memóriába kerül utasítások és adatok folyamaként. A processzor ezeket az adatokat és utasításokat dolgozza fel. Amikor egy 32 bites processzorról beszélünk, az egész számok kezelése és a memória megcímzése 32 biten történik, tehát az adatok 32 bit szélesek. Az utasítások mérete nem lényeges, mert azok (szinte) ugyanakkorák 64 biten is. Az adatok/utasítások a memóriából a rendszerbuszon keresztül a processzorba kerülnek (tekintsünk el a hiányzó másodszintű gyorsítótártól az egyszerűség kedvéért), a processzoron belül az adatok az adatcache-be, az utasítások az utasításcache-be kerülnek. Az adatcache-ből az adatok tovább vándorolnak a regiszterek felé (melyek egyelőre 32 bit szélesek), majd innen a végrehajtó egységek felé veszik az irányt, amelyek az utasítások által meghatározott módon egy, két vagy akár több adaton, vagyis operanduson elvégzik a műveletet. Az eredmény szépen visszakerül a regiszterekbe, illetve a cache-be, és a folyamat kezdődik elölről.

64 bit

Egy 64 bites processzorban 64 bit széles általános használatú regiszterek vannak, tehát a processzor képessé válik a 64 bites adatok feldolgozására. Az alkalmazás a memóriába kerül, itt már 32 és 64 bit széles adatokat is találhatunk. Az adatok és utasítások eljutnak a processzor gyorsítótárjaiba, innen ismét kétfelé veszik az irányt. Az adatok a regiszterekbe kerülnek, és itt lényeges, hogy a 64 bites adatok tárolására már rendelkezésre állnak 64 bites regiszterek is, melyek később az utasításokkal „párosítva” ismét a végrehajtó egységekben landolnak, ahol vegyesen 32 és 64 bit széles adatok keletkeznek. A képen az is jól látszik, hogy a szélesebb operandusok szállításához, tárolásához gyorsabb, szélesebb és nagyobb memóriára, rendszerbuszra és gyorsítótárakra van szükség.

Az x86-64 kiterjesztés

Ennyit a szép színes rajzocskákról, és a 64 bitről, lássuk a száraz tényeket és adatokat, melyek már konkrétan az x86-64, tehát az AMD 64 bites kiterjesztésének jellemzői. A 64 bites regiszterekben 64 bit széles memóriacímek férnek el, ezért szükség lesz egy dupla széles utasítás- vagy programmutatóra (instruction/program pointer) is, amely az éppen végrehajtandó utasítás helyére mutat a memóriában (RIP). Az x86-64 gyakorlatilag az x86 64 bitre történő terjesztése, ami azt is jelenti, hogy kompatibilis a már meglévő 32 bites architektúrával. Ennek igen komoly jelentősége van, hiszen nem kell kidobni a már meglévő hardvereket és programokat a futtatáshoz, míg az IA-64 széleskörű bevezetésével ezt nehezen kerülhettük volna el. Használatára végül az Intel is rákényszerült, mert nem hagyhatta, hogy az AMD egyedüliként kínáljon 64 bites x86-os asztali, sőt szerverprocesszort, igaz, az Intel úgy tüntette fel a dolgot, mintha saját fejlesztését adná el Extended Memory 64 Technology (EM64T) név alatt.

A kiterjesztés ugyanakkor azt is jelenti, hogy a kiterjesztett (azaz x86-64) mód használatával a már meglévő regiszterek nem csak dupla (32 helyett 64 bit) szélességűekké válnak, de számuk is megduplázódik (8-ról 16-ra), legalábbis ez a helyzet a GPR-ek esetében. A SIMD-regiszterek (XMM) nem szélesedtek tovább (128 bit), de számuk megduplázódott (8 helyett 16), az x87-es számításokhoz használt regiszterek (ST/MM) szélessége (80 bit) és száma (8) viszont egyáltalán nem változott. A virtuális memóriatartomány címmérete 64 bitre, a fizikai 52 bitesre növekszik, viszont az egyes implementációk esetében lehetnek eltérések, például az Athlon 64 processzorok valójában virtuálisan 48, fizikailag pedig 40 bitet használnak.

Miért jó mindez nekem? Vagy a programozónak?

A GP regiszterek szélességének megduplázása egyrészt a megcímezhető memóriatartomány növelése miatt fontos. 32 biten maximálisan 4 GB a megcímezhető memória mérete. Biztosan találkoztak már páran azzal a jelenséggel, amikor egy 4 GB memóriával telipakolt gépen az operációs rendszer csak 3,5–3,8 GB-ot látott. Ez annak tulajdonítható, hogy a címzésben részt vesz a videokártyán található memória mennyisége is, ezért azt a 4 GB-ból (2³²) le kell csippenteni. Egy 64 bites processzoron, ha 64 bites operációs rendszert használunk, többé ez nem fordulhat elő. Az igaz, hogy egyelőre nincs túl sok 1–2 GB-nál több memóriával szerelt PC/notebook, de valamikor valaki azt mondta, hogy 640 kB memória elég lesz mindenre, tehát ne higyjük azt, hogy ez így marad az idők végezetéig. Ennek a tulajdonságnak jelenleg inkább a szerverek világában van jelentősége (pl. óriási adatbázisok, szimuláció, modellezés stb. esetén). A széles memóriacímeknek van egy hátránya is, hiszen ha dupla széles számokkal dolgozunk, akkor azok több tárterületet foglalnak el a memóriában, a gyorsítótárakban, tehát ha véletlenül egy ilyen tárolókomponens válik szűk keresztmetszetté a rendszerben, akkor ez csökkentheti a teljesítményt, feleslegesen.

A regiszterszélesség-duplázás másik fontos mellékhatása, hogy 64 bites egész számokkal dolgozhatunk. Ha egy átlagos asztali PC-t veszünk alapul, ennek gyakorlatilag nincs semmilyen hatása ránk nézve, hiszen az átlagos, mindennapi használatban lévő programok bőven megelégednek a 32 bites egész számokkal is. Viszont vannak területek, ahol jól jöhet ez a tulajdonság: titkosító algoritmusok, esetlegesen 64 bites színmélységgel dolgozó, képalkotásra készített alkalmazások, CAD/CAM tervezőprogramok esetében vagy különböző tudományos számításokat végző kutatási projektekben, és még lehetne őket sorolni – ezek is inkább a szerverek, munkaállomások világában elterjedtek, mintsem az otthon, Quake 3-ra használt masinákon.

Elképzelhető egy olyan forgatókönyv, amikor 32 bites processzoron futtatunk 64 bites kódot. Könnyen belátható, hogy ilyenkor milyen előnyei vannak a 64 bites processzornak. Vegyük például két 64 bites integer betöltését. Egy 32 bites processzoron ehhez négy regiszterre és négy load műveletre van szükség, miközben egy 64 bites processzoron csak két regiszter és két load segítségével végezzük el ugyanazt a munkát. Ugyanez igaz a store-okra is. Két 64 bites integer összeadásánál a 64 bites processzor egyszerűen összeadja két regiszter tartalmát, míg egy 32 bites processzoron szükség van egy sima összeadásra, egy carry flages összeadásra, majd két loadra, ami az eredmény alsó és felső 32 bitjét betölti két regiszterbe, vagyis eszméletlen módon képes megnőni az egymástól függő utasítások száma, és akkor még nem ejtettünk szót a szorzásról, osztásról, ahol tovább romlik a helyzet. Természetesen ezt csak szemléltetésképpen jegyeztük meg, valójában 32 bites processzoron 64 bites kódot futtatni eleve elvetemült ötlet.

A mi szempontunkból sokkal fontosabb a regiszterek számának megduplázása, ami viszont érzékelhető teljesítménytöbblettel jár abban az esetben, ha a programozó kihasználja ezt a lehetőséget. A processzor – nevezzük úgy – saját memóriakészlete megduplázódott. Az x86 egyik legnagyobb baja, hogy kevés regiszterrel rendelkezik. Az IA-64 például 128 GPR-t tartalmaz, de hogy maradjunk a PC-k világánál, a PowerPC 970-ben (G5) 32 integer regiszter található, tehát négyszerese az x86-énak, és akkor még nem szóltunk az FP és SIMD regiszterekről. Minél kevesebb a regiszter, annál inkább a cache-re és a memóriára kell hagyatkozni, ezek elérése pedig lényegesen lassabb a regisztereknél. Ha a programozó számára több regiszter áll rendelkezésre, hatékonyabb kódot képes írni, amiben kevesebb a memóriaelérés. A regiszterek kihasználtságának köszönhetően javul a CPU hatékonysága, miközben a rendszerbusz terhelése csökken, ami ez esetben elvárható és pozitív jelenség. Az x86 esetében éppen a kevés regiszter miatt kezdték el alkalmazni a regiszter-átnevezés technikát, ennek segítségével a WAR (write-after-read) és a WAW (write-after-write) függőségeket lehet csökkenteni. A processzorban a programozó számára is látható architekturális regisztereken felül található adott számú belső, csak a CPU számára látható regiszter is, melyeket akkor használ, amikor az OoO végrehajtás dolgozik (például x regiszter tartalmát ki kell írni adott memóriacímre, az utána következő utasítás pedig x regiszterbe be akar olvasni egy adatot, de nem teheti meg, amíg az első utasítás végre nem hajtódott, holott nincs is köztük függőség – ilyenkor a CPU bevet még egy belső regisztert, hogy az utasítások végrehajtása folyamatos legyen). A regiszter-átnevezés ellenére is jó, ha minél több programozható regiszter áll rendelkezésünkre, hiszen így a programozó számára megadatik a lehetőség, hogy saját kezűleg, statikusan optimalizálja a függőségeket a processzor helyett, amely az OoO végrehajtás révén tenné meg ugyanezt.

Üzemmódok

Az x86-64-es processzorok három úgynevezett üzemmódot ismernek. Legacy módról beszélhetünk, amikor 32 bites operációs rendszert használunk, és ez alatt 32 bites programokat futtatunk. Ebben az esetben nem használhatjuk az x86-64 újításait, lényegében úgy dolgozunk, mintha mi sem történt volna (erről szól a visszafelé kompatibilitás). Ha long módba „kapcsolunk”, amihez szükség van egy 64 bites OS-re, már kihasználhatóvá válnak az x86-64 adottságai. Kompatibilis almódnak nevezzük azt, amikor 64 bites operációs rendszer alatt 32 bites programokat futtatunk. Ezesetben a program nem fordítódott újra, ezért nem tud profitálni az x86-64-ből, viszont nem is kellene, hogy különbséget érezzünk a 32 bites módhoz képest. Ahhoz, hogy kihasználhassuk teljes egészében az x86-64-et, 64 bites almódot kell használni, azaz a programot újra kell fordítani vagy újra kell írni, hogy használja az új regisztereket, címzést stb. Az üzemmódtól függ, hogy az alapértelmezett operandus- és címzésszélesség pontosan mennyi is, legacy módban természetesen maximum 32 bit, kompatibilis módban szintén, és csak 64 bites módban élhetünk a 64 bites címzéssel, viszont az integer operandusok szélessége alapértelmezés szerint továbbra is 32 bit, ami egy praktikus megfontolás következménye, hiszen a 64 bites egész számolásra ritkán van szükség, feleslegesen pedig nem érdemes terhelni a memóriát, rendszerbuszt, gyorsítótárakat, regisztereket.

Emiatt a 64 bites operandusok használatát külön jelezni kell a kódban, erre hivatott a REX prefix (előtag), ez 1 bájtos méretével növeli a kódot, az AMD számításai szerint 64 bites módban az utasítások átlagos hossza 0,4 bájttal nő. Az Intel a REX prefix használatával kapcsolatban kiemeli, hogy a kód méretének növekedése miatt nőhet a cache-missek száma, ezért ha az adott algoritmus megvalósításához elegendő a nyolc „megszokott” regiszter, akkor ne erőltessük a REX prefix használatát. A prefix értéke 40-tól 4F-ig terjedhet, és az opkódban az utasításhoz minél közelebb kell elhelyezkednie. Egy ADD EAX,8 gépi kódban 83 C0 08 lenne, viszont ha 64 bites számmal dolgozunk, akkor az ADD RAX,8 már 48 83 C0 08-ként lesz végrehajtva.

Buktatók

Ilyen nincs túl sok, de azért van egy-két dolog, amit ki lehetne emelni. Az egyik a REX prefix használatával kapcsolatos. Mint tudjuk, alkalmazása növeli a kód méretét, márpedig ez nem tesz jót a Core processzoroknak, melyek órajelenként 16 bájtnyi utasítást hívnak be elődekódolásra. Az AMD a K10-ben a fetch szélességét (talán éppen emiatt) 32 bájtra növelte, tehát esetében ez nem okoz akkora bonyodalmat, viszont a Core 64 bites módban így átlagosan kevesebb utasítást képes végrehajtani.

Szintén a Core processzorokat érinti, és a REX prefix használatából fakad a tény, hogy 64 bites módban nem működik hatékonyan a macro-op fúzió. Mit jelent ez? A macro-op fúzió segítségével a Core az olyan gyakori x86-os utasításpárokat (macro-op), mint például cmp vagy test és jmp/ja/jae stb. (összehasonlítás és ugrás, feltételes elágazás) összevonhatja egyetlen utasításba (micro-op), ezzel pedig csökken a processzorra háruló munka, így adott idő alatt nő az elvégzett utasítások száma. Az Intel szerint az utasítások körülbelül 15%-a feltételes elágazás, ami jól hangzik a macro-op fúzió szemszögéből, de tudni kell azt is, hogy ez a funkció csak akkor igazán hatékony, ha az utasítások hossza 4 bájtnál rövidebb (így a CPU órajelenként 4 vagy 4+1 utasítást képes behívni, hiszen 16 bájt széles az előbehívó), emiatt a mérnökök úgy tippelik, hogy a macro-op fúzió hozzávetőleg 4–5%-ot segít a processzornak. Mindez azt jelenti, hogy 64 biten a Core processzorok teljesítménye elméletben csökkenhet 4–5%-ot, mert a REX prefix növeli a kódot (amikor kihasználjuk a szélesebb/több regisztert), így az utasításbehívó többé nem képes optimálisan működni, azaz 4 utasítás/ciklus behívást végrehajtani. De ugyanez elmondható az SSE kódra is, amelynek átlagosan 6 bájt körül alakul az utasításszélessége, igaz, ott ritkábban fordulnak elő feltételes ugrások.

Tesztkonfiguráció

Tesztprogramok

• Szintetikus tesztek

• FRAPS 2.9.2

• Konvertálás-kódolás

• TMPEGEnc XP v4.4 + DivX 6.8
• iTunes v7.5

• Tömörítés, fotó- és videofeldolgozás

• 7-Zip v4.57 32 bit és 64 bit
• WinRAR v3.71
• Adobe Photoshop CS3
• Adobe Premier CS3
• Sony Vegas 7.0

• Renderelés

• POV-Ray v3.7 beta23 SSE2 és 64 bit
• Cinebench 10 32 bit és 64 bit
• 3ds max 2008 32 bit és 64 bit
• Lightwave 9.3 32 bit és 64 bit
• Maya 2008 32 bit és 64 bit

• Játékok

• Crysis 32 bit és 64 bit
• Bioshock
• CMR Dirt
• Lost Planet: Extreme Condition
• World in Conflict

• További tesztek

• ABBYY FineReader v9
• Apache v2.2.6
• Reaper v2.019
• Sun Java 6.3 32-bit és 64-bit + JATMARK
• Fritz benchmark

Legutóbbi processzortesztünkben már Windows Vistát használtunk a Phenom teljesítményének felméréséhez, és számos újabb verziójú, friss alkalmazást vetettünk be a naprakészség jegyében. A programokat és az eredményeket átmentettük 64 bites tesztünkbe is, de ahol volt rá lehetőség, 64 bites módban, 64 bites Windows Vista alatt az alkalmazás 64 bites változatát teszteltük le. Négy évvel az x86-64 bemutatkozása után már számos fejlesztő portolta programját 64 bites x86-ra, de még mindig nem elég magas ez a szám, ezért ahol erre nem volt lehetőségünk, ott a long mód kompatibilis almódját kellett választanunk, azaz 64 bites operációs rendszert használva a 32 bites alkalmazást teszteltük le újra. Sejthető, hogy ebben a módban sebességnövekedést aligha várhatunk, így igazán érdekesnek azok a programok bizonyulnak, melyeket már tényleg 64 bites módban tesztelhettünk. A programlistából jól látható, hogy egyetlen alkalmazási terület van, ahol a fejlesztők maradéktalanul gondoskodtak a 64 bites verzióról, és ezek a 3D-s tervezőprogramok csoportja, míg más programcsoportok esetében csak egy-egy applikációnak létezik 64 bites változata. A Javara írt program annyiban más, hogy esetében nem a programkód, hanem a JVM határozza meg a sebességet. A Sun JVM-nek van 64 bites változata, ezért ezt vettük igénybe a teszteléshez is.

A processzorokat ezúttal úgy válogattuk össze, hogy minden manapság használatos x86-os architektúra képviseltesse magát, tehát elsősorban a 32 és 64 bites végeredmények különbségére voltunk kíváncsiak, szemben sok-sok processzortípus egymáshoz viszonyított sebességével. Így kiderítettük, hogy az egyes architektúrák hogyan viselkednek 32, illetve 64 bit alatt, ebből pedig felvázolható, hogy az adott felépítésre alapozó típusok különböző órajelű variánsaitól mit várhatunk el.

Tömörítés, videokódolás

A tömörítőprogramok közül csak a 7-Zipnek van x64-es (azaz 64 bites) változata. A WinRAR-nak nem különösebben tetszett a 64 bites mód, elég komoly mértékű lassulásoknak lehettünk a szemtanúi. A 7-Zip kicsit másképpen viselkedett, az AMD processzorokon gyorsított, míg az Intel lapkái betömörítésnél kicsit lassabbak voltak 64 biten, viszont a kitömörítésnél gyorsultak.

A TMPGEnc-nek nincs 64 bites változata, ennek ellenére az MPEG-2 és DivX konvertálásban is gyorsultak a CPU-k (kivétel a Pentium D) egy pindurkát 64 bit alatt, de ezek a különbségek teljesen észrevehetetlenek.

Az iTunesnak a 7.5-ös verzióját teszteltük, amelynek nincs 64 bitre fordított változata, viszont azóta megjelent a 7.6, ennek pedig már létezik ilyen verziója. Mindenesetre a 7.5-ösben nincs különbség a 32 és 64 bites tesztek között.

3D-s tervezés, renderelés

Mint láthattuk a programlistában, csak a renderprogramok csoportjában hiánytalan a 64 bit támogatása, az összes alkalmazásnak létezik x64-re írt verziója. Ez azonban még nem jelenti azt, hogy maradéktalanul örülhetünk, ugyanis mint kiderült, ez nem minden esetben jelent jót. Vegyük például a POV-Rayt, ami az Athlont kivéve az összes processzoron lassabban futott, mint SSE2-vel. A nagy nevek, úgy mint 3ds max, Lightwave vagy Maya már profitáltak a 64 bit előnyeiből, bár nem minden processzor esetében egyértelmű a helyzet, például az Athlon 64-re nem volt jó hatással se a 3ds max, se a Maya 64 bites változata. A Core CPU-k viszont Lightwave alatt stagnáltak, míg az AMD processzorok ugyanitt gyorsultak. Egyedül a Cinebench viselkedett úgy, ahogy az elvárható és álmainkban is szerepel; itt lényegében az összes CPU gyorsult 64 biten, méghozzá nem is kevesett. Ránézésre is látszik, hogy itt a Phenom volt az ász, nem kevesebb, mint 21%-ot nőtt a pontszám egy sima újrafordítás következtében, így a 2,2 GHz-es CPU majdhogynem beérte a 2,66 GHz-es Core 2 Quad 32 bites eredményét.

Fotó- és videofeldolgozás, további programok

Az általunk tesztelt fotó- és videofeldolgozó programok közül egyiknek sincs 64 bites változata, a 32 bites verzió körülbelül ugyanúgy viselkedett, mint 32 bites operációs rendszer alatt, bár a Photoshop picit lassult, nem tudjuk, minek hatására.

További mindennaposan használt programokból szemezgettünk, ezek is igen vegyesen viselkedtek. A Finereader szövegfelismerővel 64 biten katasztrofális eredményeket mértünk ki, a processzorok 20–40%-ot lassultak, aki ezzel a programmal dolgozik, lehetőleg 32 biten használja. A Reaper zeneszerkesztőre nem volt hatással a váltás. Az Apache webszerver-tesztje minimális mértékben gyorsult 64 biten, a különbség elhanyagolható. A JATMARK egy Javára írt renderelő benchmark, nincs 64 bites változata, viszont itt nem is ez a lényeg, hanem a JVM, amelynek viszont van. Ez jól látszik az eredményeken, a teszt 64 biten sokkal (20–30%-kal) gyorsabban futott, mint 32 biten. A Fritz benchmarknak sincs 64 bites változata, ez az eredményeken is tükröződik.

Játékok

A játékok közül csak a Crysisnak van direkt 64 bitre fordított indítója, amit ki is próbáltunk. Az a vicces, hogy bár ez az egyetlen ilyen játék (azok közül, amelyekkel tesztelni szoktunk), mégis ez volt az egyetlen, amelyik 64 biten lassult, méghozzá nem is keveset. Ugyanakkor nem hagyhatjuk figyelmen kívül, hogy a játékok szereplésébe, ha minimális mértékben is, de beleszól a videokártya meghajtóprogram is, tehát elképzelhető, hogy a 64 bites NVIDIA Forceware-rel vannak problémák (bár ez nem túl valószínű, látva a többi eredményt).

A többi játékban nem vettünk észre nagyobb különbséget, csak a CMR DIRT gyorsul konzekvensen 64 bit alatt, de az sem sokat. Azért nagyon jól látni, hogy ez a játék a magok számával együtt skálázódik, a 2,2 GHz-es négymagos Phenom éppen olyan gyors alatta, mint a 3,2 GHz-es, de kétmagos Athlon 64. Még jobb a helyzet a Lost Planet alatt, itt már a Phenom a gyorsabb (CPU-limitált beállítások mellett).

Összevetés, összegző grafikonok

Jöjjenek kedvenc grafikonjaink, melyeken a Phenom 9500-hoz viszonyítva ábrázoltuk a többi processzor teljesítményét 32 és 64 bit alatt egyaránt. Nagyon jól látni, hogy mely alkalmazási területeken használható ki jelenleg (2008 elején) a 64 bites kiterjesztés, és melyek azok a területek, melyeknek még fejlődniük kell – itt elsősorban a programozókon áll vagy bukik a dolog. Gyakorlatilag csak a renderprogramok profitálnak a 64 bit meglétéből, tehát ha arról van szó, hogy valaki ezzel foglalkozik, azaz dolgozik a gépén, akkor számára érdemes lehet váltani. Szerencsére mára eljutottunk odáig, hogy lassulásokkal csak egy-két kirívó esetben találkozunk, tehát a 64 bites operációs rendszer használata inkább előnyökkel jár.

Konklúzió

Mint látható az összesítő grafikonon, az egyes tesztelt processzorok, melyek különböző adottságokkal megáldott architektúrákat reprezentáltak, 32 és 64 biten közel azonos teljesítményt nyújtottak, az átlagos gyorsulás 64 biten 1–3% volt, de ennek is nagy része a renderprogramok alatt elért időeredményeknek köszönhető, tehát összességében egy átlagos felhasználó szemszögéből inkább arról van szó, hogy a 32 és 64 bites Vista nagyjából ugyanolyan gyors.

Egyesek arra számíthattak, hogy azok a processzorok, melyek az x86-64 kiagyalójától, az AMD-től származnak, 64 bit alatt relatíve jobban teljesítenek majd, és így talán képesek lesznek befogni a rivális lapkáit. Ez a következtetés elméletben működhetne, ha azt vesszük alapul, hogy az AMD fejlesztette ki az x86-64-et, így az AMD jobban, régebb óta ismeri a kiterjesztést, tehát következetesebben tud rá optimalizálni, de mint láthattuk, az x86 kiterjesztésében nincs semmilyen ördöngősség, így azok az optimalizációk, melyek az egyik processzorban benne vannak, ugyanúgy belekerülhetnek egy másikba is, és a mérleg egyensúlyba kerül. Az AMD-hívők második reménye, illetve az Intel-szimpatizánsok félelme a REX prefixszel, és a macro-op fúzió hiányosságaival kapcsolatban fogalmazódhatott meg, de mint láthattuk, még a macro-op fúzió hiányos működése sem vetette vissza komoly mértékben a Core processzorokat. A Core architektúra 64 bit alatt ugyanúgy gyorsult/lassult, mint az AMD K8/K10 processzorok, tehát az állás egál.

El lehetne azon morfondírozni, hogy az x86-64 megváltás vagy sorscsapás a PC-piac egészére nézve, elvégre a kiterjesztés nem más, mint sokadik toldozása-foldozása az x86 ISA-nak: a 8086-ban debütáló 16 bites CISC utasításkészlet 32 bites ráncfelvarrásának a 64 bites prolongálása, eképpen sokadik kiegészítése, ha az idők folyamán megjelent SIMD-utasításkészleteket is ide vesszük. Bevezetése arra mindenképpen jó volt, hogy költséghatékony és mondhatni vonzó alternatívát nyújtson az egyre bővülő x86-os világnak, de ez az egész csak az x86-ból fakadó problémák elodázása, és nem észérvek vezérlik a használatát, hanem a piac és a pénz. Az IA-64 bevezetésével egy totálisan új, az alapoktól áttervezett architektúrára ült volna át a PC-piac egésze, de az Intelnek esélye sem volt a lassú, körülményes ISA-t bevezetni, miközben a még mindig x86-os, de egyre fejlettebb processzorok teljesítménye és a rájuk írt alkalmazások száma évről évre nő. És talán örülhetünk is, hogy az Intel ezirányú terve megbukott, mert ha egyedüliként kínált volna IA-64-es processzorokat, az az áraknak biztosan nem tett volna jót. Az Intel már elkészült, az AMD pedig készül az x86 újabb ráncfelvarrására, az Intel bevezette az SSE4-et, amely 54 új utasítást tartalmaz, az AMD pedig a következő generációs architektúrában (Bulldozer) mutatja be az SSE5-öt nem kevesebb, mint 170 új utasítással (ez már szinte egy új ISA), melyek között lesznek például FMAC/IMAC-re használatosak is, amit a POWER 1998, az IA-64 pedig 2001 óta ismer. Csak ennyi a lemaradás...

Egy kis meglepetéssel kedveskedünk az olvasóknak – ez az első AMD64/Athlon 64 reklám, amit felleltünk a neten, még 2003-ból... Az eredeti, tömörítési hibák nélküli verzió innen letölthető.

fLeSs

A tesztben szereplő processzorokat az EndWare Kft. biztosította számunkra.