Cell

[Petrik]

Promin, ale jestli ten tvuj kamarad rika, ze SPE chybi cache, tak IMHO patrne vubec nepochopil, jak Cell funguje a co to je SPE. V IBM mu to zrejme vysvetli. Jak to chapu ja, tak SPE je jakovy maly samostatny procesor, ktery ma misto bezne pomale DRAM operacni pamet typu SRAM 256kB, takze zadnou cache nepotrebuje, protoze neni co cachovat.

A proto je Pentium 4/Celeron "dost výkonné" CPU, jo?


dobrý vtip. Touto logikou by to znamenalo, že ve všech moderních CPU je out of order naprd, akorát žere zbytečně elektřinu, produkuje teplo, a snižuje výkon úplně zbytečně, protože by stačilo "líp to zkompilovat".

Mimochodem, posílal jsem tuhle diskusi kamarádovi, který studuje defacto návrh procesorů, a za rok jede do německa dělat doktorát, u kterého se bude podílet na vývoji CPU pro IBM, a dost se rozčilil, že je tahle diskuse hodně mimo . SPE prý chybí cache a podpora multithreadingu, a random acces přístupy do paměti jsou peklo se zpožděním v řádu stovek cyklů

[Rache]

Převod CD (22 skladeb) na C2D E4500@2,53+2GB/800 na mp3 320kBit trvalo 8m15s stejné cd nastavené na stejnou kompresi trvalo přímo v herním menu PS3 4m59s, výsledný soubor na pc měl 176MB na PS3172MB. Škoda, že nejde přímo na ps3 bez linuxu převést dvd na divx... Pro lepší porovnání použiju vícero softů a různý bitrate a postnu výsledky.

[Fox!MURDER]

Převod CD (22 skladeb) na C2D E4500@2,53+2GB/800 na mp3 320kBit trvalo 8m15s stejné cd nastavené na stejnou kompresi trvalo přímo v herním menu PS3 4m59s, výsledný soubor na pc měl 176MB na PS3172MB. Škoda, že nejde přímo na ps3 bez linuxu převést dvd na divx... Pro lepší porovnání použiju vícero softů a různý bitrate a postnu výsledky.

spis najit soft, co v tom linuxu vyuzije spe to by pak ficelo hodne hezky

[Caleb]

To jsou ponekud strohe informace - musel by byt pouzit stejny kodek a stejne nastaveni, aby byl vysledek porovnatelny.
Mne foobar na C2D 3,15GHz prevadi jedno hudebni CD z FLAC do MP3 Lame V0 kolem jedne minuty, quadcore by na to byl jeste vyrazne lepe, foobar totiz enkoduje tolik songu naraz, kolik jader mas.

[Rache]

to byl prvni nastrel ,vecer si s tim pohraju dukladne dejte navrh jaky konkretni soft pouzit.

[Fox!MURDER]

to byl prvni nastrel ,vecer si s tim pohraju dukladne dejte navrh jaky konkretni soft pouzit.

mas na tom linux? docela by me zajimalo, jak funguje ten ibmackej octopiler

[Rache]

mám na tom ydl 6.0 ale jsem linuxová nula s žádnýma znalostma, vyloženej klikač takže ti toho asi moc neprozradím leda bys měl náladu se stavit osobně a pohrát si s tím - alespoň bych něco pochytil

[Ryuu]

SPE nema cache schvalne. pretoze u cache nevies povedat ci budes mat dane data dostupne alebo nie, preto ma kazda spe 256kilo lokalnej pamate (pozor, nie je to cache!), kde kompiler v kazdom jednom okamihu vie co presne ma v tej lokalnej on chip pamati a kolko taktov bude trvat precitanie a zapis a teda moze robit reordering instrukcii...

No, ten compiler jsem nijak nestudoval, takze jsou to jenom moje domnenky, ale nerekl bych, ze compiler nejakym zpusobem spravuje tu lokalni pamet. Spis bych tipoval, ze je starosti programatora, aby se postaral o to, ze v lokalni pameti budou potrebna data.

Promin, ale jestli ten tvuj kamarad rika, ze SPE chybi cache, tak IMHO patrne vubec nepochopil, jak Cell funguje a co to je SPE. V IBM mu to zrejme vysvetli. Jak to chapu ja, tak SPE je jakovy maly samostatny procesor, ktery ma misto bezne pomale DRAM operacni pamet typu SRAM 256kB, takze zadnou cache nepotrebuje, protoze neni co cachovat.

No, tvrzeni "chybi mu cache" a "nema cache, protoze na typicke ulohy ji nepotrebuje" mi prijdou ekvivalentni. Obcas by na tom clovek proste rad provozoval veci, na ktere by se cache hodila.

SRAM neni o nic mene bezna nez DRAM. A jinak ta rychlost neni tim, ze je to SRAM, jako spis tim, ze je ta pamet tak mala. DRAM o stejne velikosti by mela +/- stejnou rychlost. SRAM ma hlavne tu vyhodu, ze neni potreba ji neustale refreshovat, takze se ti nemuze stat, ze se do ni zrovna chvilku nedostanes, protoze se ji kus obnovuje.

[THX]

No, ten compiler jsem nijak nestudoval, takze jsou to jenom moje domnenky, ale nerekl bych, ze compiler nejakym zpusobem spravuje tu lokalni pamet. Spis bych tipoval, ze je starosti programatora, aby se postaral o to, ze v lokalni pameti budou potrebna data.

Neviem ake presne moznosti ponuka programatorovi, mozno skutocne mozes si sam nahravat data do tej pamate, ale to je programovanie na este nizsej urovni ako povedzme C, prakticky skoro v zdrojovom kode.
Vdaka tomu ze je znama rychlost (pocet taktov na pristup, citanie, prepis atd.) do tej lokalnej pamate, tak moze kompiler robit nielen preusporiadavanie instrukcii, ale napr. aj prefetching dat. Ked pises program v C, tiez nerozhodujes na ktorej adrese presne v pamati chces mat ulozene dane data, o to sa stara kompiler. Podobne aj tu, proste napises zdrojak a ostatne nechas na kompiler.
Cim "deterministickejsi" je procesor pre ktory kompilujes, tym viac funkcionality mozes presunut z CPU do kompilera, viz. napr. uz spominany reordering, prefetching. Takto zjednodusis samotny procesor, znizis jeho cenu, mozes dosahovat vyssie freq. (viz 45nm cell ktory bezi snad na 4,5ghz - tiez viz power6 ktore su na tom podobne a tiez sli cestou "determiniziacie" a vyssich freq. - a myslim ze IBM vie velmi dobre co robi a na co sa ich procesory pouzivaju).

[Ryuu]

Neviem ake presne moznosti ponuka programatorovi, mozno skutocne mozes si sam nahravat data do tej pamate, ale to je programovanie na este nizsej urovni ako povedzme C, prakticky skoro v zdrojovom kode.

Vdaka tomu ze je znama rychlost (pocet taktov na pristup, citanie, prepis atd.) do tej lokalnej pamate, tak moze kompiler robit nielen preusporiadavanie instrukcii, ale napr. aj prefetching dat. Ked pises program v C, tiez nerozhodujes na ktorej adrese presne v pamati chces mat ulozene dane data, o to sa stara kompiler. Podobne aj tu, proste napises zdrojak a ostatne nechas na kompiler.

No, nevim jak ty, ale ja zdrojovy kody pisu naprosto bezne. Tak nejak po pravde si skoro ani nedokazu predstavit programovani bez toho :o)

Ale ted vazne. Nejak nechapu tu poznamku o nizsi urovni nez je C. Ccko ti umoznuje libovolne low nebo high level pristup, jak zrovna potrebujes. Rekl bych, ze zrovna tohle je jedna vec, kterou by nebylo uplne nejlepsi nechavat na prekladaci. Preci jen programator vi mnohem lip nez prekladac, ze ted se zrovna chysta pracovat s temihle daty a za chvilku bude potrebovat zase tamhleto.

Samozrejme, muze na to byt nejake higher level API, ktere se bude poloautomaticky samo starat o to, aby byla v pameti potrebna data. Spis bych to ale videl tak, ze si proste alokujes kus hlavni pameti, kus lokalni pameti a pak si budes mezi nimi presunovat data podle potreby.

At tak a nebo tak, tohle nevyresime, dokud se nekdo z nas nepodiva do dokumentace toho jejich uzasneho compileru. Jsem na to moc linej, takze to asi budu resit tim, ze se zkusim poptat par lidi, co s CELLem u nas neco delaji :o)

[THX]

Ziadne higher level API, ale skor lower level. O to ci tam tie data mat budes alebo nie sa velmi starat nemusis, pretoze kompiler vidi nie na 100 instrukcii dopredu ako CPU, ale ak chce tak aj na 10000 instrukcii dopredu a tak vidi ze kedy budes potrebovat tie data a moze ich teda prefetchovat. 256k je dost mala pamat, jej zaplnenie trva pomerne malo taktov. Ak teda pozera prekladac minimalne tento pocet taktov dopredu, tak potom si moze byt isty, ze sa mu nikdy nestane ze bude cakat za plnenim lokalnej ram (samozrejme - ak dokaze preusporiadat (coho je podmienkou ze tam budu take) instrukcie tak aby mal co robit CPU kym sa mu nacitaju data). Samozrejme to sa nie vzdy da a tak verim ze programator moze tiez urcit co a kedy v tej pamati bude mat - a to je napr. dalsia vyhoda oproti cache. Teda - pri kompilacii kompilerom sa ta pamat pouzije prinajhorsom rovnako ako cache, ale je tu dost dobra moznost omnoho lepsieho vyuzitia.

btw. cim vyssie higher level funkcie v c pouzijes, tym menej vies napr. co kde kedy a kolko tie funkcie v ram citaju; higher level = napr. regexp matching a zlozitejsie

[Fox!MURDER]

Ziadne higher level API, ale skor lower level. O to ci tam tie data mat budes alebo nie sa velmi starat nemusis, pretoze kompiler vidi nie na 100 instrukcii dopredu ako CPU, ale ak chce tak aj na 10000 instrukcii dopredu a tak vidi ze kedy budes potrebovat tie data a moze ich teda prefetchovat. 256k je dost mala pamat, jej zaplnenie trva pomerne malo taktov. Ak teda pozera prekladac minimalne tento pocet taktov dopredu, tak potom si moze byt isty, ze sa mu nikdy nestane ze bude cakat za plnenim lokalnej ram (samozrejme - ak dokaze preusporiadat (coho je podmienkou ze tam budu take) instrukcie tak aby mal co robit CPU kym sa mu nacitaju data). Samozrejme to sa nie vzdy da a tak verim ze programator moze tiez urcit co a kedy v tej pamati bude mat - a to je napr. dalsia vyhoda oproti cache. Teda - pri kompilacii kompilerom sa ta pamat pouzije prinajhorsom rovnako ako cache, ale je tu dost dobra moznost omnoho lepsieho vyuzitia.

btw. cim vyssie higher level funkcie v c pouzijes, tym menej vies napr. co kde kedy a kolko tie funkcie v ram citaju; higher level = napr. regexp matching a zlozitejsie

to je vsechno nadherny, az na to, ze by se ten kod nesmel vubec vetvit a vstupni data pro jedno SPU by nemohla zaviset na vystupnich datech jinych PPE/SPU ... pak vsechny tyhle vyhody jdou do haje ....

kompiler taky neni vsemocnej. imo by nejlepsi reseni byla kombinace obou pristupu - reordering/cache ala x86 a zaroven SRAM/compiler based optimizace ala cell ... jenze to je az moc narocny na vyvoj ...

[THX]

kompiler taky neni vsemocnej. imo by nejlepsi reseni byla kombinace obou pristupu - reordering/cache ala x86 a zaroven SRAM/compiler based optimizace ala cell ... jenze to je az moc narocny na vyvoj ...

tak mi napis v com je lepsi reordering v cpu oproti reorderingu v compileri a
v com je lepsia cache oproti onchip SRAM

kompiler sice nie je vsemocny, ale v tychto dvoch veciach (reordering, prefetching) ma v case kompilacie k dispozicii omnoho viac zdrojov (casu) a tak moze urobit omnoho viac...

A aj ked sa kod vetvi atd., proste prinajhorsom to bude fungovat ako cache - kompiler si napr. moze dovolit omnoho zlozitejsie vypocty predpokladov vetvenia ako by mohol robit CPU real-time. Navyse kompiler na rozdiel od CPU vidi aj samotny zdrojovy kod a z neho vycita kopec dalsich informacii...

[Petrik]

Ehm, mozna bych mel napsat, ze vsechny cache jsou IMHO vzdy realizovane prave pomoci SRAM, protoze ta ma radove rychlejsi pristup nez bezne pouzivane DRAM. Takze aby to bylo jasne: ty SPE maji vlastni RAM, ktera je HW totozna s napr. L1-cache u beznych CPU (=SRAM), ale vyhoda je prave v tom, ze ji nepouzivaji jako cache, ale jako RAM.

No, tvrzeni "chybi mu cache" a "nema cache, protoze na typicke ulohy ji nepotrebuje" mi prijdou ekvivalentni. Obcas by na tom clovek proste rad provozoval veci, na ktere by se cache hodila.

SRAM neni o nic mene bezna nez DRAM. A jinak ta rychlost neni tim, ze je to SRAM, jako spis tim, ze je ta pamet tak mala. DRAM o stejne velikosti by mela +/- stejnou rychlost. SRAM ma hlavne tu vyhodu, ze neni potreba ji neustale refreshovat, takze se ti nemuze stat, ze se do ni zrovna chvilku nedostanes, protoze se ji kus obnovuje.

[Petrik]

2TomasD: Zaprve tu vsichni dekujeme za nazorne a relativne srozumitelne vysvetleni problemu Je videt ze o cellu asi preci jen neco vis, takze se ti timto omlouvam

Ja jsem to proste predtim chapal tak, ze cache je potreba pouze pokud mam pomalou RAM, coz u SPE neni. Ze je hlavni pamet pomala je asi jasne, zrejme jsem automaticky predpokladal, ze neco ala SW cache se v cellu pouziva, prijde mi to docela logicke, ale asi to neni nic jednoducheho. Jednim z duvodu asi bude dost mala velikost 256kB localstoru. Kam bys tedy ty tu cache nejradeji umistil? Jednu velkou prad hlavni pamet, nebo vice malych ke kazde SPE? Nemuselo by se pak slozite resit synchronizace dat kese/kesi mezi SPE jako tomu je v pripade SMP? Mimochodem, vazne ma ten ringbus prenosovnku 100GBps? to si nejak porad neumim poradne predstavit...
Dalsi dotaz: co si myslis ze v budoucnu vyhraje? GPU + obyc CPU nebo neco ala cell?

[TomasD]

Ja jsem to proste predtim chapal tak, ze cache je potreba pouze pokud mam pomalou RAM, coz u SPE neni.

Ona je spis spravnejsi predstava takova, ze tam je pomala RAM a cache bez HW cache logiky. Coz v pripade hodne snadno predikovatelnyho pristupu do pameti umozni lepsi pristup (nejsi fyzicky omezenej velikosti cache line, kdyz vis prostorovat lokalita je jina atd), v pripade random access to je naopak o dost horsi.

Ze je hlavni pamet pomala je asi jasne, zrejme jsem automaticky predpokladal, ze neco ala SW cache se v cellu pouziva, prijde mi to docela logicke, ale asi to neni nic jednoducheho.

Slozity to neni, je na to prefabrikovana knihovna. Problem je, ze to je radove pomalejsi nez cache u normalnich CPU.

Jednim z duvodu asi bude dost mala velikost 256kB localstoru. Kam bys tedy ty tu cache nejradeji umistil? Jednu velkou prad hlavni pamet, nebo vice malych ke kazde SPE? Nemuselo by se pak slozite resit synchronizace dat kese/kesi mezi SPE jako tomu je v pripade SMP?

Tady bohuzel jen krypticky. Tech 256kB zabira neco jako 1/3 plochy SPE takze ano, je problem s mistem kam to umistit.
Velka cache pred hlavni pameti je (512KB). PPE jde do hlavni pameti pres cache a DMAcko kontroler co visi na ringbusu jde tudiz taky pres cache.
Slozite by se to resit muselo, dokonce mnohem slozitejc nez na normalni sbernici. Tam vicemene vsichni vidi veskerou komunikaci a muzou podle adresy co bezi po sbernici reagovat (viz MESI protokol). Tady je realna sance, ze data pujdou druhou stranou ringbusu a nebude na to videt.
Kam bych ji umistil ja, jak bych to resil synchronizaci atd. ti nereknu, sorry.

Mimochodem, vazne ma ten ringbus prenosovnku 100GBps? to si nejak porad neumim poradne predstavit...

100GBps je tak trochu podvod s cislama. Respektive, ono se uvadi i 300GBps, tak to je pak trochu vetsi podvod s cislama.
Jedno "zarizeni" (SPE, ale i jiny) ma teoretickou pristupovou rychlost 25GBps pri 3.2GHz procaku a ringbusu, kterej bezi na pulce. Kazdej ringbus cyklus se da vylozit/nalozit 16B. Takze kdyz si to vemes uplne teoreticky, ze ty SPEcka posilaj data do kruhu a vzdycky jen tomu hned vpravo, tak ta maximalni rychlost v jednom smeru je 25*pocet SPE GBps.
Pochopitelne tohle se zacne prudce kazit v momente kdy toho beha moc najednou (SPE potrebuje natlacit data do toho "vlacku" ale tam uz "jedou" jiny data z jinejch SPE), tak nekde u tech 100GBps pres celej ringbus v obou smerech to peakuje a pak uz to jde cely do haje.
Takze nepredstavovat jako klasickou sbernici, ale spis takovej jako system subsbernic mezi kdecim, kde muze najednou pobihat nekolik naprosto nezavislych transferu.
Maximalni co protlacis mezi konkretnim SPE a necim jinym je 25GBps a to mas jeste docela stesti. (mnohem peknejc a srozumitelnejc to je vysvetleny na anglicky wiki a je to spravne)

Dalsi dotaz: co si myslis ze v budoucnu vyhraje? GPU + obyc CPU nebo neco ala cell?

Pozor, CELL nenahrazuje GPU. V PS3 je k CELLu taky nejaka grafika, udajne zhruba na urovni 7950. Proste uz shader model 3, ale jeste ne unifikovany jako maj osmitisicovky (alespon ty co stoji za zminku, tj. 8800 ).
Moje sazka je na zpetnou kompatibilitu (to proste prodava), takze x86 multijadra multiprocesory a k tomu dedikovany chytry procaky (GPU, Larabee, CELL, neco takovyho)

[Petrik]

1)aha, ja myslel ze SPE je jakoby maly nezavisly procesor s vlastni RAM (=localstore) a ze hlavni RAM je pro nej neco jako datove uloziste kam si pres DMA saha pro data. On tedy muze pouzivat tu hlavni RAM skutecne jako RAM i presto ze je pripojena pres DMA radic? To zni dost komplikovane...

2)zrejme jsem poradne nepochopil tu SW cache, ja myslel ze to funguje tak, ze ty data, u kterych vi, ze je bude potrebovat, necha proste v local storu nebo ze je prefechne tak, aby az je bude potrebovat, tak je bude mit. ale to je jedno, neresme to.

3) ja myslel ze ta 512kB je jen pro PPU, pokud cachuje vsechno, musi byt dost narocne to managovat, nebo ne?

4) to uz zni realneji, ale i tech 25GB per SPE mi pripada jako docela slusny udaj, to nema ani lecktera L2 cache

5)to mi je jasne, ja mel na mysli pouziti pro jine nez graficke vypocty. Na jedne strane tu je snaha zacit pouzivat grafiky pro jine nez graficke vypocty, na druhe tu je snaha intelu a IBM vyvinout resp. protlacit do prodeje hybridni CPU ala Cell. Bude myslim dost zajimave jak tento ousboj dopadne u superpocitacu, chystany roadrunner ma byt hybridni opteron/cell, nejaky jiny ma naopak pouzivat nejake GPU.

[TomasD]

Errr.. hele, ale tohle sou bezny verejny informace, furt nic co by museli vysvetlovat v IBM.

ad 1) Ono zavisi jak si to predstavujes. Pokud mas program co ma vsechny data i program ve 256kB, tak to je nezavislej procesor. Coz vetsinou nema, takze musi komunikovat se zbytkem sveta. Ten pak ma namapovanej do normalniho adresniho prostoru a poruznu hrabe.

ad 2) SW cache funguje tak, ze si normalne v kusu local storu naemulujes normalni X-cestnou cache. Vcetne tagu, validity bitu, nejakejch dylek cache line atd.
Takze kdyz chces neco pres cache, tak najdes tag a validity bit, pres ne zjistit jestli to tam mas. Kdyz jo tak to natahnes z localstoru, kdyz ne tak zahajis DMA transfer a spokojene cekas az se to natahne.

ad 3) Jako ze by PPU slo do hlavni pameti pres cache, kdezto DMA primo? To by bylo dost husty tohle synchronizovat, aby v hlavni pameti byly vzdycky updatovany zaznamy. Tj. nejaka WTWNA by tam musela bejt.
Ne, normalne proste cache ma dva porty (nebo jeden prepinaci, to nevim) a DMA i PPU pristupujou do hlavni pameti skrz tu cache. Je to vyrazne jednodussi nez kdyby tam jeden sel primo a jeden pres cache

ad 4) Jo, slusny to je.
ad 5) Neni superpocitac jako superpocitac, zavisi na tom co presne chces superpocitat.

[Ryuu]

Ehm, mozna bych mel napsat, ze vsechny cache jsou IMHO vzdy realizovane prave pomoci SRAM,

Diky za upozorneni, ale tak nejak mam trochu tuseni o tom, jak se cache realizuje.

protoze ta ma radove rychlejsi pristup nez bezne pouzivane DRAM.

Mam za to, ze jsem tu uz psal, ze mezi DRAM a SRAM o stejne velikosti neni v zasade zadny vetsi rozdil v rychlosti. DRAM muze oproti SRAM ztracet cas tim, ze je nutne zapojit jeste dodatecne zesilovace, oproti tomu ale zase je ta pamet celkove mensi (myslena plocha cipu), takze jsou kratsi datove cesty. Tady bude dost mozna asi zalezet na pouzite vyrobni technologii, takze v jedne bude rychlejsi DRAM, ve druhe SRAM. Ale i kdyz bude SRAM rychlejsi, rozhodne to nebude ani o rad.

Vyhoda SRAM je predevsim v tom, ze neni nutne periodicky obnovovat obsah jejich pametovych bunek. Ono pak docela zamrzi, kdyz si clovek chce sahnout do pameti a ona ho posle nekam s tim, ze ted ma zrovna svoji periodu...

Takze aby to bylo jasne: ty SPE maji vlastni RAM, ktera je HW totozna s napr. L1-cache u beznych CPU (=SRAM), ale vyhoda je prave v tom, ze ji nepouzivaji jako cache, ale jako RAM.

Ze to oboji ma SRAM pametove bunky bych sice nepovazoval za HW totoznost, ale budiz. Nicmene si nevsimam, ze bych tu tohle nejak zpochybnoval. Ale kdyz uz jsi s tim zacal, tak RAM misto standardni cache neni nutne vyhoda. Pro urcite ulohy se hodi vic to, pro jine zase ono. Vsecko je vzdycky nutne posuzovat vzhledem k tomu, na co chce clovek danou vec pouzivat. Nicmene je fakt, ze v tomhle pripade bych asi nechtel resit synchronizaci tech cachi.

K tomuhle ucelu je v SDK primo SW cache

Jen ciste ze zvedavosti. Ta SW cache asi nijak neresi koherenci, takze kdyz jeden SPE zapisuje nekam, co druhy cte, tak ma asi smulu a zmena se k nemu nedostane, spravne?

Velka cache pred hlavni pameti je (512KB). PPE jde do hlavni pameti pres cache a DMAcko kontroler co visi na ringbusu jde tudiz taky pres cache.

Jsou nejaky verejny informace o tom, jak to DMA chodi pres cache? Tam bych docela tipoval neco jako ze kdyz se to v cache najde, pracuje se s ni, a kdyz ne, nacte se to stranou a do cache to nejde. Preci jen, kdyby to slo vsecko pres cache, SPEcka by se s PPEckem o tu cache dost praly, pricemz streamovy data vetsinou cachovat nepotrebujes, protoze to proste jednou nactes, prechroustas a pak zase vyplivnes.

Slozite by se to resit muselo, dokonce mnohem slozitejc nez na normalni sbernici. Tam vicemene vsichni vidi veskerou komunikaci a muzou podle adresy co bezi po sbernici reagovat (viz MESI protokol).

<rejp>Na to pozor. MESI nevyzaduje sdilenou sbernici, da se implementovat prakticky na cemkoliv. Kdyz uz pouzivat nejakej protokol na ukazku bus snoopingu, je lepsi ten WT-WNA </rejp>

[JonnZ]

IBM predstavila 5-krát výkonnejšieho nasledovníka Cellu
http://www.dsl.sk/article.php?article=5732

[Petrik]

IBM Roadrunner zkusebne spusten:
http://www.zive.cz/Bleskovky/IBM-Roa...5/default.aspx

[THX]

Tiez nova spurs engine karta: 4 SPE 1,5ghz cell prekona v spracovani videa Quad Core2 3ghz.
http://www.tomshardware.com/news/son...-cpu,5617.html

[TomasD]

Promin, ale jestli ten tvuj kamarad rika, ze SPE chybi cache, tak IMHO patrne vubec nepochopil, jak Cell funguje a co to je SPE. V IBM mu to zrejme vysvetli. Jak to chapu ja, tak SPE je jakovy maly samostatny procesor, ktery ma misto bezne pomale DRAM operacni pamet typu SRAM 256kB, takze zadnou cache nepotrebuje, protoze neni co cachovat.

Byl sem Keyem varovan, ze kdyz jako svuj prvni post se pustim do flamovani, tak budu za kokota. Alespon bude mit cemu se smat.

Zkusim k tomu neco rict, aniz bych porusil NDA.
Budu mluvit vylucne o CELLu, nikoliv o PS3 (tj. CELL + grafika) a to hlavne proto, ze delame prevazne na bladech kde jsou pouzitelny presny performance countery. Plus nemame to game developer SDKcko.

V cem je CELL fakt dobrej (a na to je ostatne stavenej) jsou streamovy operace.
Uplne idealni modus operandi je, ze prace na datech je rovnomerne rozdelena mezi vsech 8 SPE. PPE taha do pameti,prvni to taha z hlavni pameti, neco udela, soupne do local store souseda. Ten neco udela, soupne do local store souseda.
Pripadne si to druhy sahne pro data tomu prvnimu. Takze ringbus je vytizenej vicemene naplno jednim smerem a datove cesty se krizi bud vubec, nebo minimalne. PPE akorat (pres message) resi, kdyz nekomu dojde prace a predchozi stage jeste nic nema.
Tohle je idealni stav. Rekneme ze si z local store (pro jednoduchost) odloupnes 128kB na kod, takze na data zbyde 128kB. Ty si rozdelis na 4x 32kB, 2 vstupni a 2 vystupni buffery. Kdyz zpracujes jeden vstupni buffer do vystupniho, tak das echo ze jsou data pripraveny a zacnes, zpracovavat druhej vstupni buffer a pres DMA si natahnes novy data do prvniho.
Zaroven si nasledujici SPEcko veme tvuj vystupni buffer, vsichni jsou happy, zmeri se GFLOPSy a predhodi se verejnosti.

Co tohle ale predpoklada je, ze se pracuje na velkejch souvislejch blocich dat. Treba MPEG, nebo nejaky ZIPy nebo neco v tom stylu.

Prusvih nastane, kdyz mas random memory access pattern, tj. nevis moc dopredu co vlastne budes chtit a jeste hur, nechces najednou kibyty ale spis jen treba 8 floatu. A pak jinejch 8 odjinud.
Tenhle memory pattern ma treba raytracer, kde mas silnou casovou i prostorovou koherenci, ale ty data jsou vesmes maly (kolem 128b co potrebujes najednou) a ne uplne idealne rozlozeny.
Tam je problem jednak v trojuhelnikach (ty sou buh vi kde v pameti a ty co spolu fyzicky souvisej nemusej vubec bejt vedle sebe), ale hlavne v desnym mnozstvi neprimy adresace.
Hlavni pointa je akceleracni struktura (strom), kde mas node. Ten nactes, udelas s nim nejaky dve operace a podle toho jdes do leveho nebo praveho potomka (nebo obou). Vemes teda pointery v tom nodu a nactes dalsi node. Prusvih je, ze od momentu kdy nactes ten prvni do momentu kdy vis kam jit uplyne opravdu malo cyklu, ne dost na to abys prefetchnul do pameti ty potomky. Pokud bys chtel kontrolovat jestli uz je nemas od minula, tak to je prave cache

Trochu odbocim, kdyz se dela raytracing na normalnim CPU, tak rozdil mezi cache-aware a ne-cache-aware akceleracni strukturou je cca 5-10%.

Kazdopadne v momente kdy je pristup do pameti spatne predikovatelnej (hlavne jde o spoustu pointeru, ze se neco natahne, precte z toho pointer toho co se ma natahnout dal) tak jde CELL bez cache do kytek.
K tomuhle ucelu je v SDK primo SW cache, ktera se da bud pouzit rovnou (hit info tusim kolem 7-10 taktu, ziskani dat kolem 60-70 taktu, cache miss ve stovkach) nebo ofinetunit kdyz clovek vi co presne potrebuje. Tim se to da srazit rekneme na 7 a 40.
Dalsi problem CELLu, kdyz je SIMD je, ze pokud mas v SIMD 4 adresy, tak nemuzes udelat zadnej vector load ala G80. Proste se musi SIMD rozebrat a vybrat po jednom. A to i kdyz treba zrovna jsou vsechny ty adresy stejny a realne by stacil jeden load (G80 ma na tohle broadcast).
SRAMka ma jen jeden quadword read a jeden quadword write port a nic vic k tomu, takze se proste nacita po jednom. To docela kazi pouziti 4-way SIMD na jakoby 4 vypocetni vlakna, protoze proste ty pristupy do pameti jsou pak hrozny brzdy.

Dalsi problem je, ze DMAcko ma relativne nesikovny ovladani, kdyz potrebujes nacist najednou treba 10 quadwords z 10ti ruznejch adres (je tam k tomu nejaka struktura, kterou vybudujes a predhodis jeji adresu DMAcku, ale neumi treba rict "a ted nacti 8 quadwordu pocinaje adresou HP 0x1234567 na adresu LS 0x1000".

V momente kdy teda clovek uz potrebuje cache a dojde k tomu ulradrahymu cache missu, tak se typicky prepne vlakno. SPEcko nema hw podporu vlaken, takze se bud clovek hodne snazi to preklenout nejak softwarove, nebo se to SPEcko nekolik set taktu dost nudi.

Jeste dve veci co si malokdo uvedomuje. V ty SRAMce nejsou jen data. Je tam i program a stack.
Stack docela omezuje hloubku rekurzivniho algoritmu.
Pamet programu zase omezuje to jak slouzitou vec tam clovek muze mit. Hlavne hodne templatovany kody jsou problem, kterej na PCcku clovek vubec nevidi. Proste to je spousta kodu, kterej muze zrat i docela dost hodne z tech 256kB. Je tusim ve vyvoji (mozna uz je nejaka verze venku) tool/SDKcko/kernel patch, kterej by umoznoval dotahovat kod z hlavni pameti jak je treba, ale v soucasny dobe je typickej modus operandi to, ze se celej kod narve do SPE.

Shrnuto podtrzeno, CELL je super na streamovy aplikace, na praci na velkejch blocich souvisly pameti. Jakmile tam je hodne random access, velky prepinani vlaken atd, tak to zacne trpet na tom, ze nema cache a ze hlavni pamet je fakt dost daleko.

Co mi vysvetlili v IBM tu psat nebudu. Ale to jak funguje SPE a ze mam uplne spatnej algoritmus, mam ho zahodit a napsat misto toho neco peknyho streamovyho, tak to to fakt nebylo.