dez#36
"A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot."
Ezt a Cellel is meg lehet tenni. Annál is inkább, mert XDR vezérlője van, amihez sokkal kevesebb vezeték kell. Most is többcsatornás.
"A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer."
Na ne mondd, tényleg? Akkor mondanál egy olyan fordítót, ami automatikussá teszi a cache-manipuláció optimizálást? Csak mert én nem tudok ilyet. Mellesleg a Larrabee-ban a megszokottnál spécibb utasítások vannak erre.
"A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas."
Az is fontos, hogy ne legyen használhatatlan a kód, szóval elkerülhetetlen az optimizálás. Pontosabban, eleve ezt figyelembe véve kell megírni a kódot. Más szóval, a hagyományos kódok bár elfutnak rajta, de igencsak lassacskán.
"Nem igaz, ez csak az adatok lokalitasatol fugg."
De igaz, egy adott szóhoz tartozó cache-line mindig hosszabb, mint maga a szó, hiszen különféle kiegészítő adatokat is tárolni kell.
"Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas."
Mi kötelező? Nem tudom, mire gondolsz.
"Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik."
Igen, a HW SMT kompenzálja az in-order rendszert. Azonban, ennek megvan az ára is: párhuzamosan végrehajtható szálanként külön regiszterbank, ami igencsak megnöveli a magméretet. A Larrabee-nél ráadásul 4 párhuzamos szál van, és gondolom 512 bitesek a regiszterek is.
"Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi."
A gond ott van, hogy az amúgy sem nagy cache-t is 4-felé kell osztani.
"(tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)"
Nem baj, mert nincs is rá szükség. A double-bufferes feldolgozás viszont minden további nélkül megoldható, elhanyagolható overheaddel.
"A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany"
Ezt az SMT nem igazán befolyásolja, mivel az a 16 db művelet párhuzamosan hajtódik végre.
"tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett."
Nem, egyátalán nem ezért. Hanem azért, mert túl sok helyet igényelne, ha több ütemező és branch unit lenne. Azaz ez egy kompromisszum.
Az SPU-k 4db SP FP vektorműveletet tudnak párhuzamosan.
"Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program."
Lásd amit fent írtam. Megfelelő tervezés és optimizálás nélkül itt is lassú lenne a kód.