Ha a nemrégiben bemutatott Intel Atomra gondolunk, akkor a kis gépekbe szánt megoldások jutnak eszünkbe. Pedig a most bejelentett Intel Nehalem is lehetett volna "atom", csak más kontextusba helyezve: atomcsapás az AMD fejére. Mert bár ez első pillantásra talán nem látszik, az Intel ismét nagyot durrantott, és ez a megállapítás nem csak magára a processzorra érvényes, hanem a köré épülő rendszerekre is. Nehalem kódnév alatt egy olyan processzorarchitektúrát fogunk megismerni, ami a mobilprocesszoroktól kezdve a high-end szerverekig mindenhol megpróbál majd az AMD nyakára rálépni.
Az Intel tikk-takk névre keresztelt taktikája mindenki számára ismert: a Pentiumok csúfos bukása után az Intel felsővezetése elhatározta, hogy többé nem kíván a másodhegedűs szerepében tetszelegni a piacon sem az eladások, sem a teljesítmény tekintetében. A páros években bemutatkozik egy új architektúra (ez a takk), a páratlan években pedig megjelenik a piacon ennek az alacsonyabb csíkszélességen gyártott változata (ez a tikk). Amikor elindult a tikk-takk "program", 2006-ban az Intel előhozakodott a Core architektúrával (Merom). 2007-ben bemutatta a Core 45 nm csíkszélességen gyártott változatát, a Penrynt. 2008-at írunk, tehát itt az idő valami újra, ez pedig a Nehalem. A Nehalem tehát nem szimplán egy geometriai "frissítés", hanem egy új fejlesztés. Azt persze az Intel sem tagadja, hogy az új generáció alapja a Core architektúra, amely – mint tudjuk – a Pentium M-ből fejlődött ki, ennek elődje pedig a Pentium 3 lehetne, ami az 1995-ös Pentium Pro jelentős átalakuláson keresztülment változata, tehát a Nehalem belsőleg igen messzire nyúlik vissza. Létező gyökerek ezek, ám igencsak távoliak.
A Core architektúra, illetve ennek 45 nm-es variánsa, a Penryn korábban már bemutatásra került, ezért a most következő felsorolásban szereplő újítások megértéséhez érdemes ezeket a korábban íródott cikkeket újra átnézni. A kérdés egyszerű: mit változtattak meg a Core-on? Azon a Core-on, ami sokak számára, ha nem is tökéletes, de gyakorlatilag bőven megfelel a mindennapi igények kielégítésére. A lista hosszú, de röviden össze lehet foglalni az alapkoncepciót: szokás szerint növelték az adott mennyiségű fogyasztásra vetített órajelenként elérhető teljesítményt. Konkrétabban, címszavakban:
Csapjunk a közepébe, először is lássuk a futószalagot, a teljesítményt befolyásoló újításokat a front-endtől a back-endig! Az utasítások előbehívásáért felelős terület némileg megváltozott. Az előbehívó továbbra is 16 byte széles, de az elágazásbecslő javult; egyrészt az L2 elágazásbecslő színre lépése miatt (másodszintű BTB, azaz Branch Target Buffer), másrészt az RSB (Return Stack Buffer) továbbfejlesztésének köszönhetően. Ezekkel az újításokkal nem csak magának a becslésnek a pontosságán javítottak, hanem a rosszul megjósolt elágazásokból fakadó cikluskiesésekből is sikerült lefaragni; az Intel szerint ez egyszerűen a legjobb elágazásbecslő logika, ami létezik (mi mást mondanának). A macro-op fúzió is jobb lett, mint volt, ez már a JL/JNGE, JGE/JNL, JLE/JNG és JG/JNLE utasításpárokat is képes összefűzni, ráadásul működőképes 64-bites üzemmódban. (Ami zavarbaejtő, ugyanis az előbehívó szélessége változatlan, márpedig a Core 2 esetében azért vetették el a használatát, mert a prefixek miatt az előbehívó nem képes optimálisan működni.) A Core 2-ben az előbehívó után és a dekódoló előtt található a 18 utasítás tárolására képes Loop Stream Detector (végülis egy mini-cache), ami a tizennyolc x86-os utasításnál (macro-op) rövidebb (és külső szubrutinra nem mutató) ciklusok tárolásával és újravégrehajtásával gyorsítja a futást. A Nehalemben található LSD már a dekódolók után helyezkedik el, és 28 micro-op tárolására lett felkészítve (különböző mérések szerint ez kb. 20-23 x86-os utasításnak felel meg). Az a tény, hogy az LSD immár az x86-os utasítások (macro-opok) helyett a belsőleg használt RISC-szerű utasításokat (micro-op) tárolja lehetőséget ad a futószalagon előtte elhelyezkedő részegységek (elágazásbecslés, előbehívás, dekódolás) lekapcsolására, ráadásul a dekódolás lépésének kihagyásával közvetlenül áll összeköttetésben az OoO-motorral, ami szintén gyorsulást hoz magával. A Dedicated Stack Manager és a dekódolás nem változott semmit, három szimpla és egy komplex dekóder végzi a munkát (arról nem szól a fáma, hogy a szimpla dekóderek okosabbak lettek-e).
A Nehalem felépítése [+]
A dekódolást követően az utasítások (az LSD után) a ReOrder Bufferbe (ROB) kerülnek. A Nehalemben található ROB-ot 96-ról 128 bejegyzés szélességűre bővítették. Erre a Nehalemnek szüksége is van a Hyper-Threading-technológia miatt, amiről később még szó esik. A függőségek kivizsgálása után, miután elérhetővé válnak az operandusok, az utasítások a Reservation Stationbe (ütemező) kerülnek, ami szintén szélesedett, 32 helyett 36 bejegyzés tárolására képes. Az ütemező az utasításokat/operandusokat a végrehajtó egységek felé továbbítja, ezek száma változatlan a Core 2-höz képest, összesen 3 porton keresztül áramlanak át az adatok (Port 0/1/5) a három lebegőpontos, két egészszámos, illetve három SSE végrehajtó felé. Az ötös porton található végrehajtó kiegészült egy-egy lebegőpontos és integer biteltolást végző blokkal, de ezt leszámítva a végrehajtók nem változtak semmit.
A Reservation Station összesen hat porttal rendelkezik, a fentebb tárgyalt három porton felül további három (Port 2/3/4) szolgál az utasításbeolvasásra vagy kiírásra (Load, Store Address, Store Data). A parancsok végrehajtása után a végeredmény a gyorsítótárak felé veszi az irányt, az itt "feltorlódó" utasítások először a load és store gyorstárakba kerülnek, melyek szintén kiszélesítésre kerültek jórészt a Hyper-Threading-technológia bevezetése miatt: a load puffer 32-ről 48, a store puffer 20-ról 32 bejegyzés szélességűre bővült. Ami magát a futószalagot illeti, ezek a főbb újítások, de még van pár dolog, amiről említést kell tennünk.
A Hyper-Threading egy olyan funkció, amire egyesek szívesen emlékeznek vissza, míg mások nem rajonganak érte; a Pentium 4-et jónéhány esetben lelassította. Amit meg kell érteni, az az, hogy a Core architektúra (azaz a Nehalem) jóval szélesebb back-end résszel rendelkezik, több a végrehajtó egység, több a potenciálisan kihasználatlanul álló erőforrás, tehát a HTT – ellentétben a Pentium 4-es tapasztalatokkal – ténylegesen javíthat a Core (Nehalem) processzorok teljesítményén. Először is a Hyper-Threading technológia megjelenésének hatására be kellett következnie pár változásnak. A Hyper-Threading miatt duplikálták a regiszterfájlokat, az RSB-t és a Large-page iTLB-t. Felparticionálták, azaz a szálak között statikusan felosztották a Load és Store puffereket, a ROB-ot és a Small-page iTLB-t. Az egyik legérdekesebb a Nehalemben, hogy vannak olyan részegységek, amelyekért az egyes programszálaknak versengenie kell, ezek a Reservation Station, a gyorsítótárak, az adat TLB és a másodszintű TLB. A futószalagon egyedül a végrehajtóegységeket képtelenség megosztani, azok egyszerűen csak végzik a dolgukat, ami jön, azt végrehajtják. Ha belegondolunk, akkor a ROB statikus felosztása révén az a 128 bejegyzés tárolására képes kis puffer nem is olyan egetverően nagy, hiszen két szálnak kell rajta osztoznia, tehát egy-egy szál 64 darab bejegyzést birtokolhat egyszerre. Annyit sikerült még megtudnunk, hogy amikor csak egy szálon folyik a munka, olyankor az az egyetlen szál használhatja a teljes ROB-ot. A dinamikusan felosztott Reservation Station 36 egységnyi szélessége sem éppen kiemelkedő, de éppen ezért dinamikus a megosztás: az RS-t az a szál használhatja, amelyik a program viselkedése alapján a legjobb eredménnyel, leggyorsabb végrehajtási idővel kecsegtet.
A cache-hierarchia is jelentős átalakuláson ment keresztül. Az elsőszintű gyorsítótárhoz csak kis mértékben nyúltak hozzá, a Nehalemben a Core 2-höz hasonlóan 32-32 kB adat és utasításcache található, melyek 8 és 4 utas csoportasszociatív tárak, és bár ezek kicsit lassabbak a Core 2-ben találhatónál (3 helyett 4 ciklusnyi az elérési idő), több cache-blokk olvasási hibát engedélyeznek. Ellenben a Nehalem másodszintű gyorsítótárának mérete a töredéke a Core 2-ben találhatónak, mindössze 256 kB, és szintén 8 utas csoportasszociatív. A kis mérethez nagy sebesség társul, az L2 cache-nek csökkent a késleltetési ideje. A harmadszintű gyorsítótár megjelenése újdonság: 8 MB méretű, 16 utas csoportasszociatív, megosztott a processzormagok között és inkluzív, azaz az összes L1 és L2 gyorsítótárban megtalálható információt tárolja: az Intel szerint ez sokkal jobb megoldás, mint az AMD által alkalmazott exkluzív cache, mert így az adatkeresgéléshez szükséges forgalom csökkenthető, bár azt nem teszik hozzá, hogy így a kihasználható terület viszont kisebb. Az L3 cache-ben való keresgélést cache-cellánként négy "core valid" bit segíti, melyek megmutatják, hogy a keresett információ megtalálható-e valamelyik gyorsítótárban vagy sem.
Már eddig is rengeteg újdonságról esett szó, de van még valami, ami gyakorlatilag már önmagában is kiemelkedő jelentőségű. Az Intel évtizedek után úgy döntött, hogy végleg megválik a rendszerbusztól. A Nehalem az első olyan Intel processzor, amely pont-pont összeköttetésen keresztül kommunikál a rendszer többi elemével, ez pedig a QuickPath Interconnect (QPI). Ez a megvalósítás ismerősen hangzik, hiszen az AMD már a K8-tól kezdve egy ehhez hasonló linket használ (HyperTransport), de úgy tűnik, hogy az Intel nem kért ebből, hanem inkább egy saját szabványt fejlesztett ki. A QPI A HT-linkhez hasonlóan egy csomag alapú, magas sávszélességet és alacsony késleltetést kínáló protokoll, mely full-duplex (kétirányú), maximálisan 25,6 GB/s-os adatáteresztő képességgel rendelkezik. A QPI megjelenése a mobil, illetve asztali processzorok szempontjából kevésbé lényeges kérdés, a szerverek piacán viszont annál fontosabb, hiszen a rendszerbusz megléte volt az Intel processzorok köré épülő szerverek skálázódásának egyik legnagyobb problémája, és ez most a QPI bevezetésével kiiktatásra került.
Egy szintén jelentőségteljes újítás az integrált DDR3-as memóriavezérlő (IMC, Integrated Memory Controller) bevetése. Az AMD által még a K8-asnál bemutatott specialitást az Intel megfejelte egy harmadik csatornával, ami így 1066-os memóriákkal maximálisan 32 GB/s-os sávszélességet kínál, egyben jelentősen lecsökkentve a memóriaelérés idejét is. Az FB-DIMM támogatás valószínűleg csak a szerverváltozatok sajátja lesz (Beckton vagy Nehalem EX), egyelőre be kell érni a DIMM, UDIMM és RDIMM modulokkal.
A QPI és az integrált memóriavezérlő oda-vissza kölcsönhatásban áll a processzor egyes elemeivel. Például az Intelnek többé nincs szüksége batárnagy gyorsítótárakra csak azért, hogy kiküszöbölje a rendszerbusz lassúságát, azt a sokmillió tranzisztort ehelyett felhasználhatja valami okosabb dologra is. A háromlépcsős gyorstár (a Nehalem L3-asa közel a processzor órajelén fut, a K10-eséhez képest alacsony a késleltetése) és az IMC rendkívül gyors hozzáférést ad az adatokhoz, amire az SMT miatt, főleg szerverkörnyezetben szükség is van. Összességében az látszik, hogy az Intel nem bízott semmit a véletlenre.
Végül, de nem utolsósorban a Nehalemben debütál az SSE4.2 SIMD-utasításkészlet, ami hét új utasítást tartalmaz: egy részük az XML, illetve szöveg, azaz stringfeldolgozásra specializálódott, továbbá tartalmaz speciális területekre fókuszáló, különböző mintafelismerő instrukciókat is (pl. kézírás felismerés [ATA], génkutatás [Popcnt] stb.). A CRC32-es utasítás a háttértárolók és hálózati adatfeldolgozás felgyorsítására szolgálnak. Egyelőre nincs túl sok program, ami kihasználná ezeket, de az SSE-utasításkészletek közül eddig egy sem merült feledésbe, és mindig csak a megjelenésüket követően kerültek kihasználásra.
Miután már ismerjük a Nehalem futószalagját, van még valami, ami igazán érdekessé teszi az egész architektúrát: ez pedig a moduláris felépítés. Az Intel egy olyan rendszerarchitektúra megalkotásán fáradozott, mely a piac összes szegmensében képes helytállni, mindezt úgy, hogy ne kelljen különböző további fejlesztésekkel, járulékos költségekkel terhelni a céget. A processzortervezésnek ez az új módozata, ami korántsem az Intel találmánya, egy, már szélesebb körben alkalmazott paradigma. A Nehalem az Intel első olyan fejlesztése, melynek értelmében a processzor egyes funkcionális elemeit, ez esetben a magokat, a gyorsítótárakat, a QPI linkeket, a memóriavezérlőt, energiamenedzsmentet stb. külön-külön fejleszthetik; jól definiált interfészek és a gyártáselőkészítéssel összehangolt tervezési rendszerek teszik lehetővé, hogy ezen elemekből többféle igényt kielégítő processzorok születhessenek. Gondoljunk csak az előző generációra, a notebookon át a szerverekig egyazon architektúra hajtotta meg a különböző rendszereket, pl. a Meromot találjuk meg a notebookokban, ennek asztali változata a Conroe, a szerverekbe pedig a Woodcrest került: néhány kisebb differenciát leszámítva ezek egyetlen fejlesztésen alapultak.
A Nehalem az Intelnek lehetőséget ad arra, hogy tetszőlegesen összekombinált processzorokat készítsen, pl. a notebookba felesleges az L3 cache, nincs szükség integrált memóriavezérlőre, a QPI-linkek száma is alacsonyabb, viszont jól jöhet egy integrált videovezérlő, ennek megfelelően alakítható ki egy-egy termékszegmens. A Nehalem négymagosként mutatkozik be, de később megjelennek majd a két- (belépőszintű asztali rendszerek) és nyolcmagos, (azaz 16 párhuzamos utasításszál végrehajtására alkalmas) szerverekbe szánt változatok is. A processzor ilyen irányú felépítése természetesen magában hordozza a chipsetek jelentőségének csökkenését is, az egyforma magok és különféle chipsetek párosításait a standard chipsetek és eltérő magok fogják felváltani.
Az új architektúrát az energiamenedzsment terén is továbbfejlesztették, megjelenik a processzorban a Power Control Unit, azaz PCU, egy mikrokontroller, egy miniprocesszor a processzoron belül, ami a központi egység egyes részegységeinek az áramellátásáért és monitorozásáért felelős. Ez az adott szituációnak megfelelően külön-külön szabályozza a magok, az északi híd és a harmadszintű gyorsítótár hőmérsékletét és fogyasztását. A PCU alapjában véve az AMD K10-es energiamenedzsmentjéhez hasonlóan működik, tehát a processzormagok járhatnak egymástól eltérő órajelen, de a feszültség mindig a legjobban leterhelt processzoréhoz igazodik. Viszont van különbség is, méghozzá az, hogy a PCU képes az egyes processzormagokat alvó állapotba (C6 state) küldeni, vagyis teljesen átamtalanítani azokat, amikor nincs rájuk szükség, ezzel elfojtva még a szivárgási áramból fakadó fogyasztást is. A Nehalemben található PCU az energiamenedzsment terén sokkal gyorsabban dolgozik, mint elődei, ami azt jelenti, hogy a processzor egyes részegységeinek állapotváltása közti időkiesés (latency) is alacsonyabb.
Az új processzorok egyik legszembeötlőbb funkciója a Turbo mód, amit szintén a PCU tesz lehetővé. A Turbo mód nem újdonság, hiszen a mobil Penryn lapkák már ismerték ezt a funkciót Enhanced Dynamic Acceleration Technology néven, de a gyakorlatban szinte sehol sem működött a szoftveres támogatás hiánya miatt. A Nehalem Turbo módja azonban más, mert a PCU egy hardver, nincs szüksége külső segítségre. A funkció bekapcsolását követően a PCU figyelemmel kíséri a processzor kihasználtságát, majd amint a futtatott folyamatoknak nincs szüksége a processzor összes erőforrására, a nem használt magokat lekapcsolja. Ennek megfelelően a fogyasztás csökken, azonban a Turbo módot aktiválva az éppen leterhelt magok órajelét a rendszer dinamikusan megemeli, amíg a processzor el nem éri a specifikációkban megadott tipikus hőtermelési (TDP) értékét. A Turbo mód akár négy aktív processzormag esetében is megemelheti az órajelet, amíg a PCU úgy érzékeli, hogy a hőmérsékletek rendben vannak és az aktuális fogyasztás a maximált érték alatt van. Alapértelmezett beállítások mellett természetesen nem kell drasztikus teljesítménynövekedésre számítani.
| Processzor megnevezése | Intel Core i7 | Intel Core 2 Quad | AMD Phenom |
| Architektúra Családnév Kódnév |
Core Nehalem Bloomfield |
Core Penryn Yorkfield |
K10 Stars Agena |
| Órajel | 2666-3200 MHz | 2333-3200 MHz | 2000-2600 MHz |
| Támogatott memória | DDR3-1066 (DDR3-1333) | DDR2-800 / DDR3-1066/1333 | DDR2-800/1066 |
| Gyártástechnológia | 45 nm Hi-K + Metal Gate | 45 nm Hi-K + Metal Gate | 65 nm SOI |
| Tranzisztorszám (millió) | 781 (Bloomfield) | 2 x 410 (2 x Wolfdale) | 463 (Agena) |
| Magméret (mm2) | 265 (Bloomfield) | 2 x 107 (2 x Wolfdale) | 285 (Agena) |
| Stepping | C0 | C0 | B2 |
| L1 cache | 4 x 32 kB adat (8 utas) és 32 kB utasítás (4 utas) | 2 x [2 x 32 kB adat és 32 kB utasítás (8 utas)] | 4 x 64 kB adat és 64 kB utasítás (2 utas) |
| L2 cache | 4 x 256 kB (8 utas; 256 bit) |
2 x 6 MB megosztott (24 utas; 256 bit) |
4 x 512 kB (16 utas; 256 bit) |
| L3 cache | 8 MB megosztott (16 utas; 256 bit) |
nincs | 2 MB megosztott (32 utas; 128 bit) |
| SIMD | MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2 | MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 | 3DNow!(+), MMX, SSE, SSE2, SSE3, SSE4a |
| Egyéb támogatott technológiák | C1E, EIST, Execute Disable Bit, EM64T, Intel VT | C1E, EIST, Execute Disable Bit, EM64T, Intel VT | DDPM, SPL, CoolCore, Enhanced Virus Protection, x86-64, AMD-V |
| Rendszerbusz órajele | maximum 6,4 GT/s QuickPath Interconnect (azaz 6400 MT/s =3200MHz) | 333 MHz FSB – 1333 MHz QPB | 1800 MHz HyperTransport |
| Feszültség | ~1,12 V | 1,25 V | 1,25 V |
| TDP | max. 130 W | max. 130 W | max. 145 W |
Az Intel a már jól bevált, először a Penryn megalkotása során használt 45 nm-es (high k kapuoxid és fémalapú kapuelektróda) gyártástechnológiával építette fel a Nehalemet. A processzor 781 millió tranzisztorból áll és 265 mm2 alapterületű, ami a tömegtermelési szempontokat figyelembe véve kifejezetten nagynak számít. Ez már majdnem akkora, mint a K10 alapjául szolgáló Agena, de nem hagyhatjuk figyelmen kívül, hogy az Intel lapkája már 45 nm-en, míg az AMD processzora még 65 nm-es csíkszélességen készül.
| Processzor megnevezése | Core i7-965 Extreme Edition | Core i7-940 | Core i7-920 |
| "Core" órajel (CPU-magok) | 3,2 GHz | 2,93 GHz | 2,66 GHz |
| "Uncore" órajel (L3 cache, északi híd) | 2666 MHz | 2133 MHz | 2133 MHz |
| L3 cache mérete | 8 MB | 8 MB | 8 MB |
| Támogatott memóriatípus | DDR3-1066 | DDR3-1066 | DDR3-1066 |
| QPI-link sebessége | 6,4 GT/s | 4,8 GT/s | 4,8 GT/s |
| "FSB" | 133 MHz | 133 MHz | 133 MHz |
| TDP | 130 W | 130 W | 130 W |
| "Overspeed" védelem aktiválva | Nem | Igen | Igen |
| Bevezető ár | 999 USD | 562 USD | 284 USD |
A Nehalem felsőkategóriás változata, a Bloomfield három taggal indul útjára. Az új generáció Core i7 néven kerül forgalomba, míg a legek legje, a csúcskiépítés továbbra is Extreme Edition utótaggal ellátva látja meg a napvilágot. A Core i7 előtag után szokás szerint egy szám jelzi majd az adott modell családon belüli helyzetét, így tehát a Core i7-920 lesz a legalacsonyabb, 2,66 GHz-es órajelű verzió, a Core i7-940 középre ékelődik be 2,93 GHz-es frekvenciájával, a Core i7-965 Extreme Edition pedig 3,2 GHz-en teljesíti be sorsát. Érdemes egy pillanatra elgondolkodni és elmélázni az órajelek kérdésén: a két nagy processzorgyártó már évek óta nem gyártott 3,2 GHz-nél magasabb órajelű processzort, szemük előtt szinte csak és kizárólag az utasítások párhuzamos futtatásának felpörgetése lebeg a magok számának emelésével. A három Core i7-es az órajeleket leszámítva specifikációit tekintve minden tekintetben megegyezik egymással, a belső felépítés, a gyorsítótárak mérete, a QPI-linkek száma és még az úgynevezett FSB órajele is, ami a Core i7 processzorok esetében 133 MHz.
A Nehalemmel kapcsolatban éppúgy, mint az AMD processzorok esetében, nincs értelme FSB-ről beszélni, csak egy úgynevezett alapórajelről, amit felszorozva eredményül kapjuk a processzor, a memória és az "uncore" (uncore clock multiplier), azaz a processzormagokon kívül elhelyezkedő részegységek órajelét. Ez a rendszerbusz vagy "FSB" a Nehalem esetében alapértelmezés szerint 133 MHz-es órajelet vesz fel, így tehát kiszámolható, hogy a Core i7-920 huszas szorzóval rendelkezik (20 x 133), a memória DDR3-1066-os módra való beállításához pedig nyolcas szorzóra (8 x 133) van szükségünk - az alaplapok BIOS-ában ezt fogjuk viszontlátni.
A most bejelentett három típus közül a Core i7-965 Extreme Edition kiváltságosnak számít, ugyanis a processzorban található "uncore" területek, a harmadszintű gyorsítótár és az északi híd 2,66 GHz-es órajelen jár (míg az olcsóbb modellekben csak 2,13 GHz-en), ráadásul a túlhajtást megakadályozó "Overspeed" védelmet is deaktiválták benne. Ez annyit jelent, hogy a Core i7-940 és i7-920-as processzorok szorzóját nem módosíthatjuk felfelé, és a memóriaszorzó sem állítható nyolcnál, azaz 1066 MHz-es órajelnél magasabbra. Tapasztalataink azt mutatják, hogy ez elég rossz hatással van a tuningra.
Intel Core i7-965 Extreme Edition [+]
Az új architektúra, azon belül is a Bloomfield a korábbi Intel Core 2 processzorokhoz nagyon hasonló tokozásban kerül forgalomba, viszont a chip alapterülete nagyobb, és az alján a megszokott 775 helyett 1366 érintkezőt találunk, azaz a Bloomfield alapú processzorok LGA1366-os foglalatba illeszkednek. A foglalatváltásra szükség volt, hiszen a QPI-linkek és az integrált memóriavezérlő processzorba való beépítése révén jóval több adatvezetékre van szüksége a CPU-nak.
A Core i7-920 hűtője balra, Core 2 Quad QX6700 hűtője jobbra [+]
A Core i7-920-as mellé csomagolt gyári Intel hűtő első ránézésre alig különbözik egy mostanság használatos Core 2 Quad gyári légkavarójától. Alapterülete alig nagyobb, a kupakkal egy rézbetét érintkezik, de az ezt körülvevő lamellák alumíniumból vannak, tehát semmi extra. Arról azonban ne is álmondjunk, hogy az LGA775-ös processzorhoz megvett hűtő illeszkedni fog az LGA1366-os foglalatba, a négy lefogató messzebb van egymástól, tehát az LGA775-ös hűtő nem passzol bele az új alaplapokba, melyek közül hármat most közelebbről is meg fogunk ismerni.
A három bemutatásra váró alaplap az Intel újdonsült X58-as chipkészletére épül - természetes, hogy egy ilyen szinten megváltozott architektúra mellé egy teljesen új lapkakészletre volt szükség. Tudható: a hasonló koncepciójú AMD K8/K10 alá kifejlesztett chipsetek évek óta szinte változatlanok, csak extráikkal tudnak egymás fölé nőni, a memóriavezérlő átkerült a processzorba, így a klasszikus értelemben vett chipkészletek egyik leglényegesebb funkciójára többé nincs szükség. Az északi híd szerepe lecsökken, és legfőbb, illetve lényegében egyetlen komolyabb feladatául a processzor és a különböző perifériák közti adatforgalom irányítását kapja.
Ezalól az X58 sem kivétel. Az új chipkészlet elsőként támogatja a Core i7-es processzorokat (melyek a beépített memóriavezérlő révén közvetlenül csatlakoznak a memóriához, de ehhez a chipkészletnek semmi köze), a processzor és az északi híd között pedig egy maximálisan 25,6 GB/s-os sávszélességet kínáló (6400MT/s=3200MHz/1000*64bit/8) QPI-link helyezkedik el. Az északi híd legfőbb feladata a CPU, a grafikus vezérlők és a perifériák közti kommunikáció vezénylése, az X58 támogatja a CrossFire és az SLI többkártyás üzemmódokat is, de az SLI-t csak abban az esetben, ha az alaplap gyártója megvásárolja az ehhez szükséges licencet az NVIDIA-tól. Az északi és a nemrégiben bemutatkozó ICH10-es déli híd között a jó öreg 2 GB/s-os áteresztőképességű Direct Media Interface található. A déli híd az X58 mellett is csak arra képes, amire egy P45-ös alaplapon, az IDE-csatlakozást már nem támogatja, hat darab, NCQ és RAID 0, 1, 0+1 és 5 tömböket is kezelő SATA-300-as portot kínál fel, 12 USB port kivezetésére ad lehetőséget, és egy-egy natív gigabites hálózati vezérlőt, illetve HD-audiót támogat.
A teszteléshez rendelkezésünkre álló idő szűkössége miatt az alaplapokkal nem volt időnk behatóbban megismerkedni, ezért itt és most csak arra koncentrálunk, amit sikerült róluk kideríteni. A működésük egyébként sem volt makulátlan, olyan alaplapokról van szó, melyeket egy még meg sem jelent processzor alá szántak, a bétás BIOS-ok kiforrottságát pedig jól ismeri mindenki... Az Intel a Nehalemet a csúcsszegmensbe szánja; az alaplapok felszereltsége, illetve ára is ezt tükrözi. Mindhárom típus az X58-as chipkészlet köré épül, és ismerve az Asust és az MSI-t, sejthető, hogy mindent megtesznek azért, hogy vásárlóik elégedettek legyenek. Az Asus P6T Deluxe, az MSI Eclipse, illetve a processzorhoz mellékelt Intel DX58SO került terítékre.
Az alaplapok csomagolása [+]
A hozzávalók (Asus / MSI) [+]
Egy számítástechnikai boltban járva elsőként az alaplapok csomagolása szúr szemet a vevőnek, ezen a téren az Asus és az MSI általában igyekszik valami szépet alkotni: a P6T Deluxe doboza kinyitható, mint egy képeskönyv, az MSI Eclipse dobozán pedig egy sugárnyalábszerű jelenség látható. A mellékelt kellékek tekintetében mindkét gyártó beladott apait-anyait, itt már nincs helye a zsugoriságnak, a leírásokon és meghajtóprogramokat tartalmazó CD-ken kívül találunk IDE, floppy és SATA-kábeleket, hátlapi takarólemezt, molex-SATA tápcsatlakozó-átalakítót, illetve CrossFire-hidat, amiből az Asus csak egyet, az MSI viszont kettőt csomagolt a dobozba. Az Asus mellékel még egy három USB portos hátoldali kivezetést, az MSI viszont a FireWire és SATA kivezetésekre is gondolt. Az Intel DX58SO-ból csak egy OEM változatot kaptunk kézhez, amihez csak néhány kábel járt, de a dobozos változathoz valószínűleg több mindent adnak majd (egyelőre nem tudjuk, hogy mit, mert az alaplap nem szerepel a gyártó weboldalán).
Asus P6T Deluxe / MSI Eclipse / Intel DX58SO [+]
A három alaplap három különböző egyéniség. Mindhárom fekete NYÁK-on nyugszik, és a gyártóra jellemző körítéssel rendelkezik. Amit talán érdemes azonnal kiemelni, az a memóriafoglalatok száma és elhelyezkedése. A Nehalem memóriavezérlője háromcsatornás, és ez az alaplapokon is kézzelfogható jelenség: az Asus és az MSI hat-hat memóriafoglalattal rendelkezik, fekete-sárga és kék-fekete színnel elválasztva őket egymástól. Az Intel DX58SO-n csak négy foglalat található, de ezen a típuson is jól látható, hogy a négyből három foglalatnak ugyanolyan színe van. A háromcsatornás memóriavezérlő hallatán nem kell megrémülni, ugyanis a Nehalem két memóriamodullal is tökéletesen elboldogul (hogy ez milyen hatással van a teljesítményre, azzal később foglalkozunk). Az Asus és az MSI szokásukhoz híven egy hőcsöves rendszerrel kötötte össze a lapkakészlet két tagját, illetve a processzor mellett található mosfeteket, az Asus még egy kis felszerelhető ventilátort is mellékelt hozzá, ha esetleg tuningra kerülne sor. A heatpipe-okkal nem volt különösebb problémánk, de az MSI Eclipse-en a gyári Intel hűtő miatt kicsit görbítgetni kellett a lamellákon, az MSI-nek talán illene erre odafigyelni (a gyári hűtőről van szó, a különböző speckó hűtők felszerelése más kérdés). Mindhárom alaplap a foglalatok és csatlakozók garmadájával lett felszerelve, a CrossFireX kiépítése szempontjából talán az MSI Eclipse sikerült a legjobban, hiszen a PCIe x16-os foglalatok messzire kerültek egymástól, míg az Intel DX58SO ezt a módot egyáltalán nem is támogatja, hiszen csak két PCIe x16-os bővítőhelyet találunk rajta.
Asus P6T Deluxe OC Palm [+]
Az alaplapok a legkülönbözőbb módokon segítenek a túlhajtásban. Az Asus P6T Deluxe-on 16+2 fázisú VRM található, és az alaplap mellé csomagoltak egy OC Palm nevezetű kis bizgentyűt, ami olyan, mint egy tévétávirányító, de tévé helyett az alaplap tuningszekcióját irányíthathatjuk vele valós időben, programok és BIOS nélkül (a tévétávirányítótól azért is különbözik, mert USB-n keresztül csatlakozik az alaplaphoz). A P6T Deluxe természetesen támogatja az EPU-t is, ami a rendszer terhelését figyeli, és ehhez igazítja a tápellátást, illetve felkínálja nekünk az Express Gate néven ismert (1, 2, 3) mini SSD-re előtelepített Linux rendszert is chatelésre, képnézegetésre, internetezésre felkészítve. A Power és Reset gombok lassan szokványossá válnak ebben a szegmensben.
Az MSI Eclipse a második generációs, DrMOS név mögött meghúzódó fejlettebb alkatrészeket kínálja, melyek kisebb hőtermelés mellett gazdaságosabban üzemelnek, az alaplapon is kevesebb helyet foglalnak, és tuningban szintén extra lendületet biztosítanak. Az alaplap 6+2 fázisú VRM-mel rendelkezik, a gyártó egy utólag felszerelhető LED-es (diagnosztikai) kijelzőt mellékelt hozzá (D-LED 2 kijelző), ami az alaplap különböző állapotait és a processzor hőmérsékletét jelzi ki számunkra (1, 2, 3, 4); ehhez elvileg járna egy külső burkolat is, de mi ilyet nem találtunk a dobozban. Az Eclipse-ről sem hiányozhatnak a külsőleg hozzáférhető Power és Reset gombok, mellettük találjuk a D-LED 2 gombot, amivel váltogathatunk a D-LED-en megjelenő üzenetek között. Nem a tuninghoz kapcsolódik, de meg kell említeni, hogy a gyártó az MSI Eclipse mellé Creative X-Fi hangkártyát mellékel, ami jól szól, de szoftveres megoldás.
Az Intel DX58SO-hoz nem kaptunk semmiféle csecsebecsét, amivel játszadozni lehetne, és az alaplap is inkább csak az alapfunkciók meglétére összpontosít, s bár a 6 fázisú VRM-ről és a Power gombról itt sem kell lemondani, ezeket leszámítva az alaplap nem egy Asus/MSI szint, már ami a különböző technológiákat, fejlesztéseket és jól hangzó reklámokat illeti.
Csatlakozók (Asus / MSI / Intel) [+]
A hátlapi panelek alaposan megváltoztak az elmúlt időszakban. A PS2-portokat már csak az MSI tekinti szívügyének, az Asuson már csak egy van belőle, az Intel DX58SO-n pedig egy sem. A PS2-portok helyett lehetőségünk van rengeteg USB használatára, és az eSATA, illetve FireWire csatlakozók is egyre általánosabbak. Az Asus és az MSI ezeken kívül két Ethernet aljzattal rendelkezik, ráadásul az Eclipse-en van még CMOS Clear gomb is. A szokásos audioportok az MSI-ről a külső hangkártya miatt hiányoznak. SPDIF portokat találunk az Asuson és az Intelen is, az MSI esetében ezt ismét csak a külső hangkártyán kell keresni (egyetlen optikai kimenetet találunk rajta).
BIOS
| Alaplap típusa | Asus P6T Deluxe | MSI Eclipse | Intel DX58SO | |
| BIOS típusa | AMI | AMI | AMI | |
| Beállítható FSB (internal base clock) | 100-500 MHz | 100-800 MHz | 133-240 MHz | |
| Szorzó (csak Extreme Edition) | 12x és 63x között | - | 12x és 63x között | |
| Állítható PCIe órajel | 100-200 MHz | 100-200 MHz | 100-110 MHz | |
| QPI Data Rate | 4800, 5866, 6400 | 4800, 5866, 6400 GT | 4,8, 5,866, 6,4 GT/s | |
| DRAM szorzók ("lockolt" CPU-k esetében maximum DDR3-1066) | DDR3-800, DDR3-1066, DDR3-1333, DDR3-1600, DDR3-1866, DDR3-2133 | 6, 8, 10, 12 | 6, 8, 10, 12 | |
| UCLK (uncore clock ratio) | 2133 és 5600 között 133 MHz-es lépésekben | - | szorzóval | |
| Beállítható feszültségek | ||||
| CPU | 0,85000 V és 2,1000 V között, 0,00625 V lépés | -320 mV és +630 mV között 0,010 V lépés | 1,0000 V és 1,6000 V között 0,0125 V lépés | |
| RAM | 1,5 V és 2,46 V között, 0,02 V lépés | 1,20 V és 2,77 V között 0,01 V lépés | 1,50 V és 2,1 V között, 0,02 V lépés | |
| QPI | 1,2000 V és 1,90000 V között, 0,00625 V lépés | -320 mV és +630 mV között 0,010 V lépés | 1,150 V és 1,800 V között 0,025 V lépés | |
| További feszültségek | CPU pll: 1,80 V és 2,50 V között 0,02 V lépés IOH: 1,10 V és 1,70 V között 0,02 V lépés IOH PCIe: 1,50 V és 2,76 V között 0,02 V lépés ICH: 1,10 V és 1,40 V között 0,10 V lépés ICH PCIe: 1,50 V és 1,80 V között 0,10 V lépés DRAM data ref voltage on CHA/CHB/CHC: 0,395x, 0,630x, 0,005x DRAM ctrl ref voltage on CHA/CHB/CHC: 0,395x, 0,630x, 0,005x load line calibration CPU differential amplitude CPU clock skew IOH clock skew | CPU pll: 1,00 V és 1,80 V között 0,05 V lépés ICH voltage: 0,78 V és 1,73 V között 0,010 V lépés IOH voltage: 0,70 V és 2,13 V között 0,01-0,05 V lépés DDR_vref_ca_a/b/c: 0,435 V és 1,125 V között 0,05 V lépés DDR_vref_dq_a/b/c: 0,435 V és 1,125 V között 0,05 V lépés CPU amplitude control: 700, 800, 900, 1000 mV PCI Express amplitude control: 700, 800, 900, 1000 mV CPU clock skew MCH clock skew | Dynamic CPU Voltage Offset (mV): 0 és 494 között 6-7 mV-os lépés IOH voltage override: 1,100 V és 1,500 V között 0,025 V lépés TDC current limit override (amps): 0 és 500 között TDP power limit override (watts): 0 és 500 között | |
Asus P6T Deluxe BIOS [+]
MSI Eclipse BIOS [+]
Intel DX58SO BIOS [+]
Ami a tuningot illeti, nem jutottunk sokra az alaplapok közül egyikkel sem, egyrészt az alaplapi BIOS-ok kiforratlansága miatt, másrészt pedig azért, mert az Intel csak későn tájékoztatott minket a túlhajtás mikéntjéről, de arra azért sikerült rájönnünk, hogy a Nehalemet nem olyan pofonegyszerű túlhajtani, mint egy Core 2 Duót vagy Athlon 64-et. A Core i7-965 órajelét háromféleképpen lehet megemelni: szorzóemeléssel, "FSB"-emeléssel vagy természetesen úgy, ha mindkettőt megváltoztatjuk. Az "FSB"-t mindössze 150 MHz-ig sikerült túlhajtani annak ellenére, hogy a memória és a QPI szorzóját visszább vettük: ez végül 3,6 GHz-es órajelet eredményezett. Szorzóemeléssel sem jutottunk előbbre, ugyan az alapértelmezés szerinti 24-es szorzó helyett sikerült a 25-ös szorzót beállítani, de a maximálisan elérhető órajel 3,6 GHz maradt.
A Core i7-920-ban már működik a túlhajtást megakadályó funkció (Overspeed protection), így a szorzó állítására nincs módunk, tehát csak az "FSB" emelésével van esélyünk a plusz MHz-ek kifacsarására, és végülis a 160 MHz-es FSB-t, azaz a 3,36 GHz-es órajelet akár tekinthetnénk sikeresnek is, de ennél azért többre számítottunk, főleg a Core 2-esek után. Napokkal a tesztelés után kaptunk egy dokumentumot a túlhajtásra vonatkozóan, miszerint az Intel alaplapban még a túlhajtást megelőzően a TDC current limit override (amps) és TDP power limit override (watts) opciók értékét meg kell emelni, mindezt a Turbo Boost opció bekapcsolása után. Ezzel két problémánk van: először is a BIOS-ban nincs Turbo Boost opció, a helyén Intel Dynamic Speed Technology menüpont látható (lásd a fényképeket), de ettől még el lehetne tekinteni, mivel csak a menüpont neve más. Másrészt a limit megemelésével (illetve minden mással, ami a képen látható) mi is megpróbálkoztunk, de nem jártunk sikerrel. Az Asus P6T Deluxe-szal kb. ugyaneddig jutottunk, az MSI-vel pedig még odáig sem, hogy tuning: a BIOS elmentése után fekete képernyő fogadott minket. Összegezve mindezt, egyelőre nincsenek túl jó tapasztalataink, de ezek remélhetőleg csak az alaplapok és a saját hibáink miatt alakultak így, és később már tapasztaltabban, kiforrott BIOS-okkal sikerrel fogunk járni.
Egy kis ízelítő a Core i7-920 teljesítményéből 3364 MHz-en [+]
Tesztkonfiguráció
| Intel Nehalem tesztrendszer | Core i7-965 EE, 940 és 920 processzorok (4 x 256 kB L2) Intel DX58SO alaplap (BIOS 2260) Intel Chipset Driver v9.1.0.1007 2 x 1024 MB Samsung DDR3-1066 és 1x1024 MB Crucial DDR3-2000 memória 1066 MHz-en 7-7-7-21 időzítésekkel | |||||
| Intel Core 2 tesztrendszer | Core 2 Extreme Q6700 és QX9770 processzorok (2 x 4 MB illetve 2 x 6 MB L2) Asus P5E3 Deluxe alaplap (BIOS 1404) Intel Chipset Driver v9.1.0.1007 2 x 1024 MB Samsung DDR3-1066 memória 1066 MHz-en 7-7-7-21 időzítésekkel | |||||
| AMD K10 tesztrendszer | Phenom 9850 tuningolt változatai 2,66 (13x205) és 3,2 GHz-en (16x200) [4 x 512 kB L2; 2 MB L3] MSI DKA790GX Platinum alaplap (BIOS v1.2) ATI Catalyst 8.9 SB driver 2 x 1024 MB CSX Diablo DDR2-1200 memória 1066 MHz-en 5-5-5-15-2T időzítésekkel (unganged mód) | |||||
| Videokártya | Radeon HD 4850 ATI Catalyst 8.9 | |||||
| Merevlemez | Samsung Spinpoint T166 500 GB (HD501LJ; SATA; 7200 rpm; 16 MB cache) | |||||
| Operációs rendszer | Windows Vista Ultimate 32-bit SP1 | |||||
| Tápegység | Cooler Master 700 watt | |||||
Tesztprogramok
A tesztek során a Turbo mód ki volt kapcsolva. Ezt fontos megjegyezni, mert tesztünkben a processzorok teljesítményét azonos órajelen szerettük volna feltérképezni, a Turbo móddal viszont a Nehalem előnyhöz jutott volna.
Először a fogyasztást vizsgáltuk meg; az Inteltől közel egy éve kiszivárgott diák szerint a Nehalem fogyasztása azonos teljesítményt feltételezve kb. 30%-kal alacsonyabb a Penrynénél. A két architektúra közti teljesítménykülönbséget még nem ismerjük, mindenesetre az látszik, hogy azonos órajelen már üresjáratban is többet fogyaszt a Nehalem, a differencia kb. 15-20%-os. Ez elég magas értéknek számít, de azt azért tegyük hozzá, hogy a Penryn fogyasztás szempontjából talán túlságosan is jól sikerült, és a Nehalemnek ez még mindig csak az első kiadása (stepping), másrészt a konkurenciánál még így is jobban teljesít, hiszen a Phenomnak még magasabb a fogyasztása. Igaz, az AMD is hamarosan bejelenti processzorának 45 nm-es változatát, de az még odébb van.
A terhelt értékeket látván nem derült fény újabb meglepetésre, a Nehalem továbbra is a Penryn és az Agena (K10) közé pozicionálja magát. A kétszálas mérésekkel annyit azért sikerült kiderítenünk, hogy a Nehalem fogyasztása a használt magok számával szépen skálázódik (úgy, mint a K10-é); a Core 2-vel ugyanis az a probléma, hogy nem volt képes a magokat külön szabályozni, tehát ha az egyik duplamag leterhelődött, akkor a másik kettős is fűtött. Teljes terhelés alatt a Nehalem fogyasztása kb. 20-30%-kal magasabb, mint a Penryné, tehát ahhoz, hogy a fent említett állítás beigazolódjon, a Nehalemnek igencsak gyorsnak kell lennie. Ha a Nehalem fogyasztását megpróbáljuk kimatekozni, akkor az jön ki, hogy a 3,2 GHz-es Nehalem kb. 70-80 wattot disszipálhat (teljes rendszer fogyasztása terhelve mínusz teljes rendszer C1E-s fogyasztása plusz a Nehalem C1E-s fogyasztása [kb. 10-20 watt] mínusz a többi komponens [RAM-ok, alaplap, chipset, táp] terhelés miatt megnőtt fogyasztása).
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:
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.
Az utasításvégrehajtással kapcsolatos különbségek feltérképezésére szintén az Everest tesztjeit vettük elő. Itt különösen érdekes lehet a Hyper-Threading használata, hiszen ezekből a tesztekből kiderül, hogy a Nehalem esetében kínról vagy áldásról van szó. Hogy az egyes eredmények hátterét megértsük, felvettük a kapcsolatot a program készítőivel.
A CPU Queen egy egyszerű, egész számokkal dolgozó benchmark, amely a processzorok elágazásbecslési képességére fókuszál, és a „nyolc királynő egy sakktáblán” feladványra épül (10 x 10-es sakktáblán). A teszt MMX-, SSE2- és SSSE3-optimalizált, és kevesebb mint 1 MB memóriát foglal le. Ebben a tesztben az elágazáskezelés képességei határozzák meg a pontszámot. Nemcsak a branch prediction táblák és a becslés pontossága, illetve a return stack mérete, hanem az is, hogy az utasításkészlet támogatja-e valamilyen módon maguknak az elágazásoknak az elkerülését (van-e CMOV vagy PABSB utasítás), illetve képes-e egyszerre párhuzamosan több bábu helyzetével számolni. A Nehalem HT nélkül éppen olyan gyors, mint a Penryn, viszont HT-vel elhúz mellőle.
A CPU Photoworxx különböző digitális fotófeldolgozási műveleteket hajtat végre a processzorral (kitöltés, forgatás, random stb.). Ez a teszt főleg a processzorok integer számolási végrehajtási egységeit dolgoztatja meg a memória-alrendszerrel egyetemben, ezért nem skálázódik olyan jól több processzormag esetén. A teszt csak alap x86-os utasításokat használ. A Photoworxx a legösszetettebb teszt, többféle méretű képpel dolgozik, sok minden számít benne, de leginkább az átlagos memóriaelérés ideje a döntő. Sokat jelentenek a jobb prefetcherek, és itt számít a legtöbbet a memória és a cache-ek hatása. A Nehalem fejlettebb gyorsítótárjainak és gyorsabb memóriaelérésének köszönhetően könnyedén veri az előző generáció képviselőit még kikapcsolt HT mellett is.
A CPU ZLib is egy integer benchmark, amely a publikusan elérhető ZLib fájltömörítési algoritmussal méri le a processzor és a memória-alrendszer teljesítményét, ez a teszt is csak alap x86-os utasításokat használ. Itt inkább a CPU sebessége, illetve képességei számítanak (dekódolás szélessége, out-of-order load támogatása, ugrásbecslés, reordering ablak mérete), mint a memória sebessége. A Nehalem HT nélkül ismét olyan gyors volt, mint a Penryn, de HT-vel 27%-ot gyorsult. Tekintetbe véve a HT megvalósításáért "felszámolt anyagköltséget" (tranzisztorszámot, ami valószínűleg igen alacsony), ez nagyon jó eredmény.
A CPU AES is egy integer benchmark, amely az AES (azaz Rijndael) adattitkosító algoritmust használja. A teszt Vincent Rijmen, Antoon Bosselaers és Paulo Barreto publikusan elérhető C kódját használja ECB módban. A benchmark alap x86-os utasításokat, és összesen 48 MB memóriát használ. Itt is inkább a CPU sebessége a fontos, illetve kiugróan az out-of-order load képesség számít (a hardveres AES támogatást leszámítva persze). A Nehalem itt is a Penryn sebességét hozza, már amennyiben kikapcsoljuk a HT-t. HT-vel 4%-kal gyorsabb.
Az FPU Julia a processzorok 32 bites (egyszeres pontosságú) lebegőpontos teljesítményét méri le a „Julia” fraktál segítségével. A benchmark kódja assemblyben íródott, és extrém mértékben használja ki az egyes AMD és Intel SIMD-utasításkészleteket (x87, 3DNow!, 3DNow!+, SSE). Az eredmények okán előző tesztünkben sokat töprengtünk, ugyanis nem értettük, hogy a K10 miért ennyivel lassabb. Végül a program készítői adták meg a magyarázatot, miszerint a Julia bench beleszalad a K8/K10-nek abba a korlátjába, hogy az architektúra nem bírja, ha cserélődnek az SSE regisztereknél az adattípusok. A Core-on ez nem gond, és emiatt gyorsabb/rövidebb kódot lehet írni.
Az FPU Mandel a 64 bites (kétszeres pontosságú) lebegőpontos teljesítményt méri le a „Mandelbrot” fraktál egyes frame-jeinek kiszámolása révén. Ez a benchmark is assemblyben íródott, és hasonlóan az FPU Juliához, kihasználja az egyes SIMD-utasításkészleteket (x87 vagy SSE2). Itt a Nehalem még HT nélkül is gyorsabb a Penrynnél. A Julia benchez képest a K10 itt azért szerepel jól (pontosabban fogalmazva nem vérzik el úgy, mint a Juliában), mert a Julia belső ciklusa egyszerre 8 pixelen dolgozik, a Mandelé viszont csak 4 pixelen, emiatt a típusváltást (int/float) kiváltó kód Mandelban rövidebb és gyorsabb az AMD CPU-kon.
Az FPU SinJulia a 80 bites (kiterjesztett pontosságú) lebegőpontos teljesítményt méri le a „Julia” fraktál módosított változatának kiszámolásával. A kód assemblyben íródott, és erősen kihasználja a trigonometrikus és exponenciális x87-es utasításokat. Míg a Juliánál a raw 32 bites lebegőpontos MUL/ADD/MOV képességek számítanak, addig a SinJuliánál a legpontosabb 80 bites mód kihajtása a lényeg, és a transzcendens utasítások (sin, cos, ex) megvalósítása. Teljes végrehajtási idő szempontjábol a sin, cos, ex sebessége a döntő, amiben egyébként a P6 leszármazottai hagyományosan gyorsabbak. A Nehalem itt majdnem kétszer gyorsabb a Penrynnél.
A szintetikus tesztekből levonhatjuk a tanulságot, miszerint a Nehalem valódi előrelépés a Core 2-höz képest. A cache-hierarchia gyorsult, a memória alrendszer jelentősen átalakult, és az integrált memóriavezérlőnek köszönhetően a kiszolgálók, illetve szerverek világában is megállja majd a helyét. Ami a futószalagot illeti, a Nehalem nem lett sokkal gyorsabb a Penrynnél, legalábbis abban az esetben, ha a Hyper-Threadinget kivonjuk az egyenletből. Ugyanakkor a HT szerves részét képezi az új architektúrának, így azzal együtt kell értékelnünk; márpedig ebben az esetben szintén jelentős fejlesztésnek lehetünk a szemtanúi. Arra nem számíthatunk, hogy a Nehalem az asztali alkalmazásokban 50-100%-kal veri majd elődjét, de a 10-30%-os előny benne van a pakliban.
A 7-Zip azért jó tömörítő, mert akár 16 szálon is képes számolni, azaz képes kihasználni a Nehalem összes adottságát. Ez az eredményeken meg is látszik, a Nehalem verhetetlen. Ugyanez látható a WinRAR benchmarkjában. Ebben a két tesztben a memória elérése és a többszálas működés az új architektúra malmára hajtja a vizet.
A különböző konvertálóprogramokban elért eredmény nagyban függ attól, hogy ismerik-e az egyes SIMD utasításkészleteket. A TMPGEnc és a DivX 6.8 már támogatja az SSE4.1-et, de az SSE4.2-t még nem (igaz, ez elvileg nem tartalmaz olyan utasításokat, melyeknek a konvertálásban hasznát vehetnénk). Az MPEG2-be konvertálás során a Nehalem nem volt olyan nagyon meggyőző, pl. a Core 2 Quad Q9450 gyorsabbnak bizonyult a Core i7-920-nál, talán azért, mert ez a teszt még négy szálat sem képes teljesen leterhelni, ugyanakkor a 3,2 GHz-es változatok csatáját már a Nehalem nyerte meg, ami arra utal, hogy az új architektúra jobban skálázódik. A DivX 6.8-as konvertálásban viszont a Nehalem vitte el a prímet, köszönhetően a Hyper-Threadingnek és persze a futószalag kisebb fejlesztéseinek. DivX-ben az Intel processzorok a MPSADBW és PHMINPOSUW utasításoknak köszönhetően ilyen gyorsak, az AMD SSE4a-ja ezeket nem támogatja.
A következő három konvertálásra használt program még nem támogatja az SSE4-et, ráadásul a WME9 maximálisan négy, az iTunes pedig két szálat kezel, ezért a Nehalem a futószalagon elvégzett kisebb változtatásoknak köszönhetően lehet gyorsabb a Penrynnél. Az x264-es konvertálás képes akár nyolc szálon is számolni, így a Nehalem simán elhúz.
A renderelés egy tradicionálisan több szálra optimalizált alkalmazásterület, ennélfogva a Nehalemnek is fekszik. Ezen a téren nagyon jól érzi magát az új architektúra, nemhiába, mert ekkora teljesítményre a különféle, renderelést alkalmazó munkák során szükség is lehet.
Az Adobe alkalmazások tipikus példái az Intel processzorokra optimalizált programoknak. A filmkészítésre is használt Adobe Premier Pro és Sony Vegas nagyon jól fut a Nehalemen, a 2,66 GHz-es Core i7-920 gyorsabbnak bizonyult még a 3,2 GHz-es Penrynnél is. Az Adobe Photoshopnak is tetszett a Nehalem, bár itt már nem volt akkora az előnye, de ez betudható annak is, hogy a tesztscript jópár olyan szűrőt is tartalmaz, melyeket csak egy szálon lehet számolni. Mindenesetre az új architektúra itt is nagyot alakított.
További néhány, kevésbé szokványos vagy kisebb körben alkalmazott programot vetettünk be a processzorok közti különbségek kimérésére, ezek közül – leszámítva a JATMARK java benchmarkot – az összes képes akár 8 szálon is dolgozni. A Nehalem itt is legyorsulta a többieket, volt ahol nem is kicsit, az Apache webszerver benchmarkjában az integrált memóriavezérlőnek köszönhetően esélye sem volt a többieknek.
A játékok az az alkalmazásterület, ahol inkább a videokártya dominál, mint a processzor, a játékok a magas órajelet és a nagyméretű, klasszikus, gyors gyorsítótárat részesítik előnyben, miközben egy-két játékmotort leszámítva még mindig csak egy vagy két magot képesek kihasználni. Mi azért megpróbáltunk ismertebb, lehetőleg több szálon is működni képes motorokat letesztelni, ezeket is többnyire két felbontásban. Mint látható, kis felbontásban, gyenge grafikus beállítások mellett a Nehalem a leggyorsabb, és processzortesztről lévén szó, ez az elsődleges. De ha feljebb állítjuk a felbontást és a grafikai részletességet, mondhatni olyan szintre, ami a minimálisan elvárható egy Radeon HD 4850-től (ugyanis ezzel teszteltünk), akkor már korántsem olyan nagy a Nehalem előnye; azonban ez természetes, erre lehetett számítani.
A konvertálóprogramok vagy több szálon képesek számolni, vagy extrém módon használják ki a(z Intel) SIMD utasításkészleteket. Átlagolva az eredményeket ezek a tulajdonságok azt eredményezték, hogy 2,66 GHz-es Nehalem pariban van a 3,2 GHz-es Penrynnel. Szerintünk, ha valaki sokat konvertál, akkor azt nézze meg, hogy az általa leggyakrabban használt program mennyire párhuzamosított, és hogy milyen mértékben támogatja az egyes SIMD utasításkészleteket. A legújabb verziójú konvertálóprogramok már jórészt elég fejlettek ebből a szempontból.
A három letesztelt fotó- és videofeldolgozó programban is a Nehalem volt a nyerő.
A renderprogramok általánosságban szépen skálázódnak a magok, illetve feldolgozószálak számával, és bizony ez az eredményeken is meglátszik: a Nehalem verhetetlen volt.
A játékokkal kapcsolatban már nem egyszer kifejtettük véleményünket, ezen a téren a videokártya a leglényegesebb kérdés; ugyanakkor, ha a processzorok teljesítményét vizsgáljuk, akkor a Nehalem lett itt is a befutó. Igaz, ez volt az egyetlen terület, ahol nem volt olyan nagyon nagy az előnye, ami egyrészt a Penrynben található óriási gyorsítótárnak köszönhető, másrészt pedig annak, hogy a végértékelésbe beleszámítottuk a VGA-limithez közelebbi beállítások eredményeit is.
| Core i7-965 Extreme Edition | |||
| Memóriavezérlő | Kétcsatornás mód | Háromcsatornás mód | Különbség a háromcsatornás mód javára (%) |
| Everest benchmark (MB/s) - memóriaolvasás memóriaírás memóriamásolás | 12 160 11 886 12 984 | 12 846 11 874 16 585 | 5% 0% 27% |
| 7-Zip benchmark be/kitömörítés (MIPS) | 10 880 16 778 | 15 428 17 656 | 41% 5% |
| WinRAR benchmark (KB/s) | 3395 | 3497 | 3% |
| TMPGEnc HDV -> MPEG-2 konvertálás (mp) TMPGEnc HDV -> DivX konvertálás (mp) WME9 AP HD MOV -> WMV DVD (mp) HD MOV -> x264 (fps) iTunes WAV->MP3 (mp) | 58 36 85 92,62 50 | 58 36 84 94,18 50 | 0% 0% 1% 1% 0% |
| Photoshop CS3 (mp) Premier Pro CS3 render (mp) Sony Vegas 7 render (mp) | 59 74 48 | 58 74 44 | 2% 0% 8% |
| POV-Ray render (mp) Cinebench 10 (pontszám) 3ds max 2008 v-ray render (mp) Lightwave 9.3 render (mp) Maya 2008 render (mp) | 67 15 068 56 49 64 | 67 15 301 55 48 63 | 0% 1% 2% 2% 2% |
| Reaper render (mp) ABBYY Finereader 9 beolvasás (mp) Apache 2.2.6 bench (kB/s) Fritz benchmark (kilo nodes/s) Java JATMARK render (mp) | 40 52 2875 11 747 131 | 42 41 3115 11 753 130 | 5% 21% 8% 0% 1% |
| Crysis 800x600 / 1280x1024 (fps) UT3 1280x1024 (fps) GRID 800x600 / 1280x1024 (fps) Lost Planet 1280x720 (fps) WIC 800x600 / 1280x1024 (fps) | 76 / 36 173 139 / 91 42 95 / 55 | 76 / 36 173 153 / 94 42 118 / 56 | 0% / 0% 0% 10% / 3% 0% 24% / 1% |
A végső következtetések levonása előtt megvizsgáltuk, hogy a Core i7 hogyan viseli, ha csak kétcsatornás üzemmódban vesszük használatba, hiszen azok, akik Core 2 alapú rendszerüket szeretnék lecserélni, nagy valószínűséggel csak két memóriamodullal rendelkeznek, és nem árt tudni, hogy mit veszítünk, már ha egyáltalán veszítünk valamit a triple-channel működéshez képest. A tesztekből kiderült, hogy az átlagfelhasználónak olyan nagyon nem kell aggódnia, a harmadik memóriamodul és az ezzel párhuzamosan aktiválódó harmadik memóriacsatorna révén nem lesz számottevően gyorsabb a rendszer. A memóriaintenzív benchmarkokban (ilyenek az Everest tesztjei, a tömörítők és az ABBYY Finereader) kimutatható, egyes esetekben igen nagy is volt a különbség, de a programok többsége nem lassult le jelentősen, sőt a legtöbb semennyire. A háromcsatornás üzemmód használata a kiszolgálók és szerverek világában lehet kifizetődő, ahol a sávszélesség minden, hiszen erről szól a QuickPatch Interconnect bevezetése is.
Nem kétséges, hogy az Intel a Nehalemmel igencsak fején találta a szöget, az új Core processzoroknak sikerült nem csak a teljesítmény, de a fogyasztás tekintetében is felülmúlni a rivális Phenom, illetve Barcelona-alapú Opteron lapkákat. Ezen nem különösebben lepődtünk meg azok után, hogy már a Penryn-alapú Core processzorok is túl nagy falatnak bizonyultak az AMD számára, legalábbis az asztali CPU-k szegmensében. A QPI és az integrált memóriavezérlő önmagukban is komoly, előremutató fejlesztések, de nem képesek ellensúlyozni az üresjáratban vesztegelő végrehajtóegységek problémáját, amivel az AMD-nek is szembe kell néznie mostanában. Bár erről nem beszélnek a hírek és a téma nincs reflektorfényben, azért ha tüzetesebben átvizsgáljuk a Nehalem Hyper-Threadinggel és anélkül elért eredményeit (és mellétesszük a Penryn számait), nagyon jól látszik, hogy ez a kis plusz mennyit képes javítani egy adott architektúra teljesítményén. Könnyen elképzelhető, hogy egy Hyper-Threadinggel kiegészített Penryn asztali környezetben a Nehalemhez hasonló teljesítményt nyújtana, szerintünk ugyanis, ha az asztali alkalmazásokat vesszük alapul, akkor ez a kulcs a Nehalem sikeréhez. A QPI használata a rendszerbusszal szemben nem jár látványos előnnyel (ahogy ez igaz a HyperTransport-linkekre is), az integrált memóriavezérlő közelebb hozza a memóriát a processzorhoz, de ez nem minden.
Az AMD sajnos már a Conroe-alapú Core 2 processzorokkal sem tudta felvenni a versenyt, a Penryn lapkákkal pedig csak tágult a két gyártó közti szakadék, na most akkor mit lehetne mondani a Nehalem beharangozója után? Az agresszív árazás ugyan segít az AMD piaci részesedésének megőrzésében, de ez csak időhúzás, ha végre komoly profitot akarnak bezsebelni, akkor ez nem mehet így tovább. Hamarosan piacra dobják a 45 nm-en gyártott K10-es lapkákat (először csak szervervonalon), de ez az eddig kiszivárgott információk alapján valószínűtlen, hogy befogja a Nehalemet.
Nem számítunk a Nehalem architektúra gyors elterjedésére, mert az új processzorcsalád túl gyors és túl új ahhoz, hogy az Intel olcsón adja, és minek vinné le az árakat, ha már a Penryn is elég a rivális ellenében? Nem véletlenül utaltunk az Opteronokra, ugyanis a QPI és integrált memóriavezérlő megjelenésével az AMD Opteronok két aduásza - ami a HyperTrasport-linkek és az integrált memóriavezérlő alkalmazásából ered - semmivé válik, a Nehalem skálázódása – bár erre vonatkozó adataink még nincsenek – valószínűleg lesz olyan jó, mint az Opteronoké, és ha ez így lesz, akkor az AMD-nek a K10-es rajtját megelőző évekig tartó malmozása komoly következményekkel járhat.
Egy-egy adott CPU vagy GPU architektúrát mindig csak maximum tetszett minősítéssel szoktunk ellátni, és ez így van a Nehalem esetében is, azonban a Core i7-920 szerintünk ajánlható megvételre, hiszen versenyképes áron kerül piacra. Ajánlható, mert mint általában, a legolcsóbb verzió (esetünkben az i7-920) túlhajtható a legdrágább változat (esetünkben az i7-965 EE) órajeleire, így ár/teljesítmény arányban biztosra vehetően ez lesz a legvonzóbb az emberek számára.
 |  |
| Intel Core i7-920 | Intel Nehalem |
fLeSs
Az Intel Nehalem tesztrendszert az Intel, az Asus alaplapot az Asus hazai képviselete, az MSI alaplapot pedig az MSI bocsátotta rendelkezésünkre.