2024. március 29., péntek

Gyorskeresés

Középpontban az Intel Nehalem

  • (f)
  • (p)
Írta: |

Az Intel komoly csapást készül rámérni riválisára, de itt már nem csak az AMD léte a tét...

[ ÚJ TESZT ]

Ez az írás azért itt jelenik meg (és nem pl. a PH-n), mert a PH!-n a szerkesztőnek nem lehet szubjektív véleménye egy adott céggel, márkával, termékkel kapcsolatban, ezért az oldalon nincs hely a spekulációknak, pedig bizony én is sokkal szívesebben olvasok egy-egy olyan cikket, amiben a hozzáértő személy esélyt latolgat, találgat, eshetőségeket vázol fel. Érdemes az anandon vagy a techreporton a szerzők írásaiba belekukkantani, jobban bírom őket, mint a sima x grafikonos teszteket.

A 2008-as év sok szempontból vízválasztó lesz a számítástechnikában, és ez főleg a processzorokra igaz. Az AMD, ha sikerül neki, akkor átáll 45 nm-es gyártástechnológiára, és ekkor jelenhetnek majd meg az igazi, ütős K10-re alapozó procik. Az Intel bemutatja legújabb architectúráját, amit eddig Nehalem néven ismerhetünk. A Sun Rock is debütál, az IBM POWER6 is beindul, az új videokártyák teljesítményben rádupláznak elődeikre (SLI és CrossFire egyetlen áramköri lapkán), stb.

Vízválasztó azért lesz, mert az AMD-nek jelenlegi helyzetében, és a jövőbeni kilátásokat tekintve nincs túl sok esélye az életbenmaradásra, mondom ezt annak ellenére, hogy számomra elképzelhetetlen, hogy felvásárolják vagy hogy csődbe menjen, ez sztem biztosan nem fog megtörténni. Újságírói szempontból a Sun Rock és a Nehalem a legérdekesebb, utóbbival fogok most foglalkozni.

Az eddig rendelkezésünkre álló információkból ugyan nem tudhatjuk, hogy a Nehalem pontosan milyen is lesz, de azért nagyjából megsaccolható, hogy mire számíthatunk, és hogy az AMD-nek mire kell felkészülnie. Amit eddig tudunk:

- 2, 4, 8 processzormag egy lapkán (sziliciumszeleten)
- 4, 8, 16 logikai szál
- ebből kitalálható, hogy a HyperThreading ismét köztünk lesz
- Intel QuickPath architektúra
- integrált memóriavezérlő
- SSE4.2 utasításkészlet megjelenése

És amit a mostanában kiszivárgott slide-okról lehetett megtudni:

- 3-csatornás memvezérlő a Bloomfieldben (szerver), 2-csatornás a többiben
- 10-25%-kal magasabb egyszálas teljesítmény (valószínűleg a Penrynhez hasonlítva)
- 20-100%-kal magasabb többszálas teljesítmény (valószínűleg a Penryn-Yorkfield / Harpertownhoz hasonlítva)
- a Penrynnél 30%-kal alacsonyabb fogyasztás azonos teljesítményt feltételezve
- 4-8 MB megosztott gyorsítótár
- új lábkiosztás, ami inkompatibilis a jelenlegivel

Az írásban arra próbálok fényt deríteni, hogy a 10-25%-os egyszálas, és a 20-100%-os többszálas teljesítménynövekedés minek lesz köszönhető, illetve hogy szerintem minek lesz hozzá köze és hogy mindehhez milyen változtatásokra lesz szükség, ugyanis annyi biztosra vehető, hogy a Nehalem alapja a Core lesz.

Az egyszálas teljesítmény 10-25%-os növekedése könnyen betudható majd a nagy cache-nek és az integrált memóriavezérlőnek (egyszálon az egész gyorsítótárat egyetlen mag vezérli, eltekintve a háttérben futó folyamatoktól, melyek más magokat terhelnek), ezek önmagukban képesek 10-25%-os gyorsulást okozni, ha még emlékszünk az AMD K7-K8 váltásra, ott is szemtanui lehettünk egy hasonló átalakulásnak, igaz a cache mérete nem nőtt meg ilyen drasztikusan.

A 20-100%-kal magasabb többszálas teljesítmény sem elképzelhetetlen ha a mostani négymagos Intel procikat vesszük alapul. A natív négymagos design, azaz sokkal gyorsabb magok közti adatkommunikáció, jelentősen lecsökkent cache-koherenciából adódó adatforgalom, és az integrált memóriavezérlő, tehát sokkal alacsonyabb memória-késleltetés illetve magasabb memória-sávszélesség már bőven elegendő lehet a 20% eléréséhez, valószínűleg még többre is. A mostani Core alapú Xeonok nagyon sz@rul skálázódnak a rendszerbusz szűkössége miatt. A 100%-os gyorsulás eléréséhez már szükség lesz az SMT-re meg talán egy kis túlzásra a marketingesek részéről.

A Penrynnél 30%-kal alacsonyabb fogyasztás azonos teljesítményt feltételezve valószínűleg azt jelenti, hogy a Nehalem azonos vagy picit alacsonyabb órajelen kb. annyit fog fogyasztani, mint a Penryn, hiszen a teljesítménykülönbség az architectúrális differenciákból adódóan már ott van.

A futószalagot ért változtatásokról eddig nem tudok semmit, de elég valószínűnek tartom, hogy a változások, ha lesznek, azok mint az SMT implementálásából következnek majd. Az a kérdés, hogy ez az SMT a régi sokak által szeretett, mások által utált Netburst-ös HyperThreading, vagy valami új fejlesztés lesz (netán a HT továbbfejlesztése), olyan, mint példásul az IBM POWER5-ben debütáló, hatékonyabb, kifinomultabb az Intel megvalósításánál?

Valószínűnek tartom, hogy amit az Intel egyszer már kifejlesztett, azt nem fogja eldobni, helyette inkább újra felhasználja, erre utal az Intel honlapjáról vett idézet is: "Simultaneous multi-threading (similar to Intel Hyper-Threading Technology) returns to enhance performance and energy efficiency". Ha a zárójeles rész hiányozna, akkor talán másképp gondolhatnám a dolgokat. A másik dolog, hogy a POWER5-ös SMT megvalósításában oroszlánrészt vállal az oprendszer is (osztályozás alapján a thread-prioritások dinamikus vezérlése), amit maga az IBM fejleszt a procijaihoz (AIX), szóval erre nincs túl sok esély. Arra persze van, hogy a korábbinál kicsit okosabb lesz az új HT (több duplikált erőforrás), de az ki van zárva, hogy sokkal okosabb legyen.

A HT implementálása mivel jár? Kicsit hosszabb lesz a futószalag, mert a HT-hoz több belső, fizikai regiszterre van szükség (regiszterfile a regiszterátnevezés miatt), márpedig ha nagyobb a belső regiszterkészlet, akkor annak elérése is növekszik, és ezt kompenzálni kell. De további áldozatok is hozni kell. A HT fejlettebb órajeldisztribúciót feltételez és hatékonyabb elágazásbecslésre illetve ütemezésre is szükség lesz. Az SMT-hez két utasítás-pointerre (IP) van szükség és módosul a veremkezelés is.

Az elágazásbecslésnek azért illene javulnia, mert minél hosszabb a futószalag, annál nagyobb bűntetés hárul a processzorra egy a hibás elágazásbecslés után. Mindez természetesen tranzisztorokba kerül. A P4-ben állítólag 95%-os hatékonyságú volt az elágazásbecslés. A Pentium M megörökölte ezt a logikát, és megfejelte a loop stream detektorral illetve az indirekt elágazás-előrejelzővel. A Core szerencsére a Pentium M-re épül, tehát ezen a téren túl nagy probléma már nem lehet.

Az OoO végrehajtásnak, ütemezésnek javulnia kell, mert a HT-vel együtt már két logikai szál dolgozik a processzoron belül. Hogy ezt nagyobb vagy ugyanakkora de kissé leegyszerűsített Reservation Station/Reorder bufferekkel oldják meg, az egy jó kérdés. A méret növelése jelentős terhet ró a chip komplexitására, viszont ha az ütemezés leegyszerűsítése (megkötések bevezetése, kevésbé rugalmas vezérlés) mellett döntenek, akkor az a teljesítmény rovására mehet, mégha ezzel együtt az elérhető órajel nőne is. Szóval ebben a kérdésben csak találgathatunk, én inkább az erőforrások kiszélesítésére tippelnék, az Intel tranzisztorszám büdzséjébe 45 nm-en belefér.

A Core-ban a Reservation Station 32 egyszég széles, ráadásul ez kezeli a memóriaeléréseket is, míg a P4-ben külön RS-t rendeltek a memóriaportokhoz. Szerintem a Core RS-e kicsit keskeny két logikai processzornak, ezért növelni fogja az Intel.

A ROB-nak is változnia kéne, a Core-ban 96 egység széles. A P4-es ROB 126 bejegyzés tárolására lett felkészítve köszönhetően a nagyon hosszú futószalagnak. A Core futószalagja 14, a P4-é 20-31 lépcsős, ha tehát az arányokat veszem alapul, akkor a Core-ét is illene 110-120 környékére szélesíteni, sőt, akár még feljebb is hiszen a dekódolás sebessége 33%-kal magasabb (a Core-ban), és egy majdnem kétszer szélesebb szuperskalár felépítésről van szó (ez közrejátszik az RS szükségszerű kiszélesítésében is).

A kép kinagyítható

Sokan közületek biztosan már most utálják a Nehalemet, mert lesz benne HT, de a P4 egy teljesen más architektúra volt. A P4-es HT néha jó volt, és néha, erősen többszálra optimalizált alkalmazásokban nagyon nem volt jó. Ez annak köszönhető, hogy a Netburst összehasonlítva a maiakkal egy alapvetően keskeny felépítésű architektúra. 3 ALU, 2 (nem szimmetrikus) FPU és két load illetve store végrehajtó áll szemben a Core 3 ALU-s, 2 FPU-s és 3 SSE-s robosztus magjával, ráadásul ott a két store és egy load port is, látható tehát, hogy egy sokkal szélesebb designról van szó. A P4-ben a két logikai szál specifikus alkalmazások futtatása során egymással versenyzett az alig néhány végrehajtóért, és ha még emlékszünk rá, csak akkor működött igazán jól az SMT, ha mondjuk egy FP-intenzív mellett egy integer-intenzív szál futott, vagy ha csak a SIMD-végrehajtás volt a cél (két SIMD végrehajtó van két külön porton). A Core-ban sokkal több az erőforrás a futószalag back-end részén, ezért a HT újbóli implementálása szerintem okos gondolat.

A HT-használatért viszont további áldozatokat is hozni kell: a cache tartalmán két logikai szál osztozik, nő a cache-konfliktusok száma, és nagyobb memóriasávszélességre van szükség. Ráadásul az erőforrások magasabb fokú kihasználtsága miatt nő a fogyasztás is, bár ez az Intelnek 45 nm-en láthatóan nem okoz gondot.

Lépjünk tovább, vajon mire fel ez az óriási cache, mikor az IMC miatt már nincs rá olyan nagy szükség? Az AMD K8 és K10 példájából már tudhatjuk, hogy a cache mérete immár kevésbé releváns miután az IMC-nek köszönhetően a memória jóval közelebb kerül a processzorhoz. Szerintem a nagyméretű gyorsítótárakra egyrészt az SMT miatt van szükség, magonként két rendkívül adatéhes logikai processzort kell majd etetni. A másik, amire tippelnék az az, hogy az Intel az óriási méretű gyorsítótárakkal (és még 1-2 később tárgyalt implementációval) a Nehalemet arra készíti fel, hogy a szerverek világát egyszerűen lealázza. Jelen pillanatban ebben a szegmensben még nincs egyértelmű fölényben az Intel az AMD-vel szemben. Szerintem a Nehalem lesz az első olyan x86-os chip, ami valóban a 64-bites kiterjesztésre felkészítve látja meg a napvilágot, márpedig erre igazán a szerverek esetében van szükség. A különböző tudományos kutatások, űrkutatás, mindenféle titkosítás (amire az SSE4.2 is utal, AES-gyorsítás), 64-bites render, stb. igényli a 64 bites integert, a szélesebb adattípusok feldolgozása rendkívüli módon képes profitálni a minél nagyobb és szélesebb gyorsítótárból illetve load latencyből (hiszen egy átlagos alkalmazás max 32 bites integerekkel dolgozik). Persze ugyanez igaz a lebegőpontos és vektor számításokra is, melyek 64-80-128 bit széles operandusokkal szintén zabálják a sávszélességet, így a nagy cache csak jól jöhet (az SSE4.2-ben van olyan utasítás, ami egyszerre 256 összehasonlítást végez el). Ebből következően érdemes lenne a predekódolás szélességét is 16-ról 32 bytera növelni, hogy a macro-op fusion 64-bites módban is működhessen. Ha az egyenletbe bevonjuk az SMT-t is, akkor érthető, hogy mire fel ez nagy felhajtás a cache körül.

Integrált memóriavezérlő: ez egy sima AMD koppintás, hiszen a K8-ban volt először IMC (az x86-os piacon). Egyes híradások szerint 2 vagy 3 csatornás lesz a memóriavezérlő. Azt még jó lenne tudni, hogy az Intel itt a duál-tripla azaz 128-192 bites "egybe-channel" felé mozdul, vagy konfigurálhatóvá teszi, hogy 2-3 különálló és konkurens 64-bites csatornán folyhasson az adatkommunikáció (mondjuk 2x64/1x128 bit olvasásra és 1x64 bit írásra).

QPI: QuickPath Interconnect, alias HyperTransport Intel-módra, ismét egy koppintás (ismét csak az x86-os piacon), na nem mintha ez gond lenne, de kicsit későn eszmélt az Intel. Az AMD-nek a HyperTransport jelenleg az egyetlen komoly ütőkártyája az Intellel szemben, hiszen a többutas rendszerekben az AMD CPU-k sokkal jobban skálázódnak. A QPI megjelenésével ennek az előnynek befellegzett.

Érdekességképpen itt egy ábra, ami a jelenlegi és a Nehalemmel megjelenő rendszerarchitektúra felépítését vázolja fel előttünk.

A kép kinagyítható

A tradícionális északi híd eltűnik, és mint most az AMD-nél, egyetlen IO-vezérlő marad, ezt a QuickPath köti össze a processzorral.

Még valami: a régi (sokak számára ismerős) chip-architech.com oldal szerzője kedvtelésből a különböző architektúrák egyes részegységeit (ALU, FPU, LSU, cache, stb) képes a szilikonon ábrázolni, az Intel sajtókonferenciáján készült kép alapján pedig elkészítette a Nehalemét is. Biztosan vannak benne hibák (pl. még nem tudja senki biztosra, hogy az L2 lesz 8 MB méretű, vagy az L2 kicsi lesz, és L3-at pakolnak a chipre), de nagyon jó ez a kép.

A kép kinagyítható

Az "előrejelzés" szerint a mag kisebb lesz, mint két négymagos Penryn együtt, elvégre a cache kisebb, viszont helyette a processzorba kerül az északi híd, a QuickPath kapcsolatok és az integrált memóriavezérlő. A kép készítője szerint az SSE/FP utasításvégrehajtók is módosulnak, ezt nemtom mire alapozza (talán az SSE4.2 miatt van rá szükség), de tiszteletben tartom a véleményét. Ha így lesz, akkor csúnya vérontás lesz. Érdemes megfigyelni, hogy az AMD megoldásával ellentétben itt nem 2x2 mag található két sorban/oszlopban, hanem a négy mag egymás mellett egy sorban helyezkedik el, ez a felépítés viszont nem kedvez a cache-elérésnek, a "chipset" a mag közepén található, így a két szélső magig hosszabb út vezet. Elképzelhető, hogy az északi hídban a CPU-magok és a cache összekötetéséért egy IBM POWER-szerű, vagy ahhoz hasonló sok, de keskeny szélességű útvonalat irányító switch lesz a felelős? Majd meglátjuk...

Összességében ezek azok a lényegi újítások, melyek befolyással lesznek a teljesítményre, és okot illetve lehetőséget adnak a spekulációkra. Hogy mindebből mi valósul meg, az a jövő zenéje, mindenesetre az eddig látott információk alapján elég egyértelmű, hogy a Nehalem tényleg ütős lesz, és nem csak az AMD-nek, hanem mindenki másnak is fel kell kötnie a gatyáját, mert a Nehalem nagyon úgy tűnik, hogy már nem csak a desktop illetve low-end/mid-range szerverpiacon akar kispályázni, gondolok itt a nyolcmagos (16 szál SMT-vel) és 24 MB cache-sel készülő Becktonra (Nehalem-EX)... A Core architektúra nagyon erős, de a skálázódásbeli problémák miatt a többutas rendszerekben nem annyira kívánatos, mint amennyire lehetne, ha mondjuk már most natív négymagos, QPI-s, IMC-s képességekkel lenne felruházva. Ezek a változtatások az összes olyan téren előrébb mozdítják az Intelt, ahol eddig hátrányban volt (memória elérés, skálázódás), tehát a konkurenciának van mitől félnie. Biztos lesz aki hülyének néz, de sztem a Nehalem az első lépés azon az úton, ami az Itanium kinyírásához vezet. Az x86-ra épülő rendszerek elburjánzása a szerverpiacon megállíthatatlannak tűnik, ezzel a teljesítménnyel pedig sokan nem fogják tudni tartani a lépést. Az AMD gyengélkedésének lehet még egy olyan hatása, hogy lelassítja az Intel fejlesztési ütemét, de az is lehet, hogy az Intel komolyan gondolja ezt a tik-takk dolgot, és nyomulni fog tovább minden más tényező ellenére (talán már most sem az AMD-t tartják a mérvadónak teljesítményben, túlléptek rajta). Abban biztosak lehetünk, hogy ezek a dolgok (sok mag, sok szál, sok cache, sok gyors kapcsolat) nem a mobil és desktop gépek kiszolgálása miatt került a chipbe...

Az írásban olvasható dolgok az eddig leközölt tényeken és saját kútfőmön alapulnak, egyértelmű, hogy a spekulációt nem érdemes tényként kezelni. Ezt az írást vitaindítónak szántam, és nem egy "Intel rulez, AMD fúj" vagy hasonló értelmes "vita" kirobbantó okának. Ha vkinek ennél több és/vagy részletesebb infója van a Nehalemről, az plz jelezze.

Előzmények

  • AMD K10 TLB-hiba explained!

    Megpróbálok tiszta vizet önteni a pohárba, és elmagyarázni a K10-es TLB-hiba hátterét...

  • Véleményem 2007-ről

    Arról, ami történt, és ami 2008-ban történni fog a hardverbizniszben (szerintem)...

  • Ez lenne a fejlődés?

    Mivel a Prohardver! egy számítástechnikai fórum, ezért csak ezirányban felmerült kérdéseimet...

  • Jövő technológiák

    Már régóta lehet hallani, hogy a Moore törvényt nem lehet tovább tartani (igaz időközben...

Hirdetés

Copyright © 2000-2024 PROHARDVER Informatikai Kft.