Hirdetés

Új hozzászólás Aktív témák

  • dezz

    nagyúr

    válasz Jim Tonic #48 üzenetére

    A Larrabee-nek csak az egyik baja, hogy x86-on alapul. Ez önmagában még nem olyan hatalmas probléma, mivel az x86-os (+ x64 + SIMD-ek) kód átfordításra kerül egyfajta RISC kódra, és a továbbiakban azzal dolgoznak a magok. Bár ehhez szükség van egy összetett dekóder egységre (itt magonként), ami szintén foglalja a helyet.

    A másik dolog, ami talán fontosabb, hogy itt minden mag a szokásos CPU-s felépítést követi, ami cseppet sem hatékonyabb azoknál, ha nem teljesen általános integer kódról van szó, hanem elsősorban számításokról. Hiába van 32db belőle, 32 proci sem ér fel egy kisebb GPU-val sem ebben.

    Ezen belül az egyik dolog, hogy a szokásos cache memóriával operál, ahol egy bájt hasznos adathoz több bájt kiegészítő információt is el kell tárolni. Ellenpélda: a Cell prociban sima (statikus) RAM memória van az SPU-k mellett (jelenleg 256kB/SPU). Így ugyanakkora területen többszörös tár helyezhető el.

    A másik, hogy a Larrabee-ben minden mag a CPU-knál szokásos módon címezheti és férhet hozzá a külső memóriához. Ez jót tesz a kényelemnek és a könnyű programozhatóságnak (sok kód változtatás nélkül futtatható), azonban cseppet sem erőforrás-kímélő, nem kényszeríti rá a programozókra az optimálisabb kódolást, és az előbb említett, szokásos, nem helykímélő cache mechanizmust is igényli.

    Harmadik, hogy mivel még a kisebb L1 cache (10-20 kB) is sok helyet igényel, bonyolult és ugyancsak nem helykímélő ugrás-becslő logikára van szükség a L2-höz, vagy épp külső memóriához való hozzáférések számának csökkentése érdekében. A Cell SPU-i esetén erre nincs szükség.

    Így lehet 1-1 Celles SPU a hozzátartozó srammal együtt is jóval kisebb, mint 1-1 Larrabee-s mag -> azonos területen jóval több fér el belőlük -> jóval nagyobb hatékonyság.

    [ Szerkesztve ]

Új hozzászólás Aktív témák