Gyurkity Péter

A Power6 és a Cell révén folytatódhat az órajel verseny

Az IBM és partnerei februárban ismertetik terveiket következő generációs szerverchipjeikről, de az Intel és a Sun sem kívánnak lemaradni, ezért új részletekkel szolgálnak saját fejlesztéseiről.

A San Franciscóban megrendezendő International Solid State Circuits Conference számos érdekes információval szolgál majd az érdeklődőknek, legalábbis a napokban közzétett beharangozó szerint. Az IBM Power6 chipjéről rántja le a leplet, a Sonyval és a Toshibával közösen a második Cellről árulnak el újabb részleteket, ezzel egy időben pedig a Sun, az Intel és számos egyéb gyártó is szolgál némi információval az új jövevényekről. Az előzetes értesülések szerint jövőre folytatódhat az órajelnövelési verseny, legalábbis a szerverek szegmensében, ahol minden eddiginél nagyobb frekvenciákat sikerülhet elérni.

A kék óriás például 4 és 5 GHz közötti órajelet és 700 millió tranzisztort ígér a Power6 esetében, amely a számításérzékeny feladatoknál ennél is nagyobb lehet majd. A fogyasztás eközben 100 watt alatt marad, vagyis ezen a területen is versenyképes marad a jelenlegi csúcspéldányokkal, nem kell attól tartani, hogy a magasabb órajel elviselhetetlen étvággyal jár együtt. Az IBM-Sony-Toshiba hármas közös fejlesztése, a Cell is megkapja utódát, amely szintén előrelépést jelent ezen a területen. A második generáció példányai a 6 GHz-et is túlléphetik, javul a memóriakezelés, a 65 nanométeres gyártástechnológia pedig tűrhető fogyasztást sejtet.

Az Intel saját 80 magos processzorának továbbfejlesztésével készül az eseményre. A chip méretében lecsökkent (303 helyett már csak 275 négyzetmilliméter), órajele 4 GHz, 100 millió tranzisztort foglal magába, teljesítménye pedig eléri az 1,28 teraflopot, mindezt 98 wattos fogyasztással. A "network-on-chip" architektúra egyik legfontosabb feladata annak vizsgálata, hogyan mozgatható több terabájtnyi adat nagy sebességgel az egyes magok, illetve a mag és a memória között.

A konferencián a Sun a Niagara 2 processzorát mutatja be, amely 8 magra és 500 millió tranzisztorra épül. Az AMD négymagos Barcelona sorozatáról beszél majd, amely az Intel négymagosaira lesz a válasz.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • dez #54
    Mégiscsak szerepelt:
  • dez #53
    Azzal még nem nagyon találkoztam, de van LinPack, meg jópár más: link
  • dez #52
    "Pedig korrekt, a G5-re se volt optimalizálva: a debugos kódhoz képest az optimalizált kód 5%-ot sem gyorsul."
    Na de értsd már meg, hogy a G5 out-of-orderes, rendes branch-prediction van benne, stb. Így ezek tekintetében nem kell külön optimizálni, azaz sokkal jobban tud alkalmazkodni az "egyszeri" kódhoz is, mint a PPU. Ezért ugyanazt a kódot ráengedni a PPU-ra különös kegyetlenség, kiszúrás. :D Ami helytakarékosságból ki van belőle tranyó szinten spórolva, fordító szinten kell amennyire csak lehet pótolni. Ez eleve így van kitalálva.

    "Az általános esetek azok amelyek minden programban szerepelnek.
    pl. a kernel hol használ SIMD egységet vagy egy kereső stb?"

    Jaj, ne csináld már. Most az, hogy nem minden programnak van rá szüksége... De pl. minden normális, hétköznapi médiafeldolgozó, lejátszó program SIMD-es. Meg még jópár másik is. Jó, nem ez a legáltalánosabb eset, de nem is annyira speciális. Szóval az általános integer teljesítmény mellett ez is fontos adat. És ebben a PPU-ban lévő VMX azonos órajelen is jóval gyorsabb lehet, mint a P3-ban lévő SSE.

    "Te tévedsz :)"
    Ha én, akkor velem együtt még nagyon sokan...

    "16 bites FP-t, csak néhány célprocesszor használt pl. Nvidia FX sorozat.
    A 16 bites FP egyszerűen használhatatlan, még a 32 bites integer is lényegesen jobb."

    Jaj. Csak annyira használhatatlan, hogy az IEEE szabványban is benne van (IEEE 754).

    Half-precision floats are used in cases where neither the range nor the precision of 32 bit floating point numbers are needed, but where some dynamic precision is required. Two common uses are for image transformation, where the range of each component (e.g. red, green, blue, alpha) is typically limited to or near [0.0,1.0] or vertex data (e.g. position, texture coordinates, color values, etc.).

    The main advantage of half-precision floats is their size. Beyond the considerable potential for memory savings, processing a large number of half-precision values is more cache-friendly than using 32 bit values.

    (link)

    "Nyílván ezért erőltetik a Power sorozatban a 64 bites FP-t, mert elég a 32 is.
    Nem azt mondtam, hogy mindenre elég.

    "Szerinted miért nem csak cellből építik? Ugyanannyi opteron lesz benne, mint cell."
    Visszakérdezek: minek használnak szerinted ott Cellt egyátalán? Miért nincs azok helyett is Opteron? Jobban megérné, ha csak a DP-ből indulunk ki.

    "Fognak fejleszteni PS3-ra ez nem kérdes, de a megtérülés már problémás lesz. Az EA-nak nyílván nem gond, ha 10 projektből 5 bukás, a másik 5 finanszírozza, de a kisebb cégek(ami magyar szinten akár sok milliárd ft forgalmút is jelenthet), egy egy játékba bele is bukhatnak."
    Jahh, hát nagy fához nagy fejsze kell. De a faanyag is annyival több lesz. :)

    "Aha, persze."
    Nem én találtam ki, hanem Mike Acton (Highmoon Studios). Goto cellperformance.org.

    "Arról még nem is beszéltünk, hogy általános számítógépes felhasználásra már csak azért is alkalmatlan a cell, mert egyszerre 10+ program is futhat, melyek hiába optimalizáltak szarrá külön-külön, együtt pont kiütik egymást, azaz nem 10-edére csökken a teljesítményük, hanem lényegesen rosszabb lesz."
    Miért is lesz ebben annyival rosszabb a Cell, illetve a PPU, mint más procik? Főleg hogy a multithreadinget itt HW SMT támogatás is segíti.

    "Erre még egy egyszerűbb hw esetén is van jó pár példa, P4 esetén a HT sok programnál érdemes volt kikapcsolni, mert egy-egy közbe iktatott más thread annyira megborította, hogy drámaian esett a teljesítmény."
    Drámai esésről nem tudok, csak pár %-ról (1 fő szál esetén), mert ugye a háttérprocessek folyamatosabban futottak, foglalva a proci "erőforrásait", szakaszosság helyett. 2 fő szál esetén viszont hozta a formáját (közelítette az 50-50%-ot, azaz beérte az Athlonok hasonló körülmények között mutatott teljesítményét :P).
  • Power #51
    Kiváncsi leszek mikor publikálnak(ha egyáltalan valaha is) SPECint/SPECfp értékeket.
  • Power #50
    "Valós, de nem korrekt, mert egyátalán nem optimizál a PPE-re. Ha optimizálna, valószínű kicsit mások lennének az arányok."
    Pedig korrekt, a G5-re se volt optimalizálva: a debugos kódhoz képest az optimalizált kód 5%-ot sem gyorsul.

    "Nagyon is hozzátartozik ez is, mivel sok program alkalmazza a SIMD egységet pl. x86-on is"
    Az általános esetek azok amelyek minden programban szerepelnek.
    pl. a kernel hol használ SIMD egységet vagy egy kereső stb?

    "Ez tévedés. A bugyutább, sőt nem is olyan bugyuta játékokhoz még a 16 bites FP is elég. Lásd újfent cellperformance.com
    2 éve írtam egy feedbacket IBM-éknek a Cell DP vs. SP teljesítményéről, azt válaszolták, sok tudományos alkalmazáshoz elég az SP is. Tudsz róla, hogy Cellekből és Opteronokból most épít szuperszámítógépet?"

    Te tévedsz :)
    16 bites FP-t, csak néhány célprocesszor használt pl. Nvidia FX sorozat.
    A 16 bites FP egyszerűen használhatatlan, még a 32 bites integer is lényegesen jobb.
    2 éve írtam egy feedbacket IBM-éknek a Cell DP vs. SP teljesítményéről, azt válaszolták, sok tudományos alkalmazáshoz elég az SP is. Tudsz róla, hogy Cellekből és Opteronokból most épít szuperszámítógépet?
    Nyílván ezért erőltetik a Power sorozatban a 64 bites FP-t, mert elég a 32 is.
    Szerinted miért nem csak cellből építik? Ugyanannyi opteron lesz benne, mint cell.

    "Abban még nem, de 10-esben igen. Ha minden úgy lenne a Cellel kapcsolatban, mint egyesek mondják, egészen pontosan 0 csoport fejlesztene PS3-ra. Ezzel szemben csak azok nem fejlesztenek, akik a lehető legkisebb ráfordítással akarnak üzletet csinálni. Szerencsére nem mindenki így gondolkodik."
    Fognak fejleszteni PS3-ra ez nem kérdes, de a megtérülés már problémás lesz. Az EA-nak nyílván nem gond, ha 10 projektből 5 bukás, a másik 5 finanszírozza, de a kisebb cégek(ami magyar szinten akár sok milliárd ft forgalmút is jelenthet), egy egy játékba bele is bukhatnak.

    "Nem feltétlenül lesz ebben nagy változás. Leginkább az elején kell kitalálni a megfelelő adatformátumokat, adatkezelési útvonalakat, stb"
    Aha, persze.

    Arról még nem is beszéltünk, hogy általános számítógépes felhasználásra már csak azért is alkalmatlan a cell, mert egyszerre 10+ program is futhat, melyek hiába optimalizáltak szarrá külön-külön, együtt pont kiütik egymást, azaz nem 10-edére csökken a teljesítményük, hanem lényegesen rosszabb lesz.
    Erre még egy egyszerűbb hw esetén is van jó pár példa, P4 esetén a HT sok programnál érdemes volt kikapcsolni, mert egy-egy közbe iktatott más thread annyira megborította, hogy drámaian esett a teljesítmény.


  • dez #49
    Továbbá van egy ilyen is: IBM XL C/C++ compiler, ami még inkább Cellre "hangolt".
  • dez #48
    Egyébként most olvastam a Cell SDK doksijában, hogy a mellékelt GCC nem az eredeti, hanem saját fejlesztés (és itt nem csak az SPU-s extensionokra gondolnak). Na hát ezzel kellene fordítgatni dolgokat, és utána méricskélni.
  • dez #47
    (Jobb esetben.)
  • dez #46
    Hol? A GPU-k is SP-ben csinálnak mindent (T&L, vertex- és pixelshaderek, dx10-ben geometria is).
  • BiroAndras #45
    "Hova kellene ez egy játékban?"

    Sokszor a single precision miatti kerekítési hiba kényelmetlen.