Cell

[lullu]

..no on na ten disk prachsprostě swapuje ..o výměně za 7200rpm jsem uvažoval snad stokrát, ale je to celkem drahej špás na to, že člověk ani neví, jak dostatečně velkej to bude mít v praxi přínos, drobný zlepšení tam ale podle recenzí je.. pokud máš firmware <2.10, tak díky klukům z ps2dev dostaneš v linuxu přístup k 254MB videopaměti, což taky trošku pomůže a pak už mě napadaj takový věci jako i-ram nebo swap na usb flashkách v raidu ..a v poslední řadě ssd hdd, kterej by tomu pomohl asi nejvíc, jenže je zatim neúnosně drahej kurnik..

[Petrik]

http://gravity.phy.umassd.edu/ps3.html
http://www.smh.com.au/news/articles/...?page=fullpage
16 x PS3 = 400 x PC

Na to, ze to je vlastne 486ka (podle Eagla), pro kterou se neda programovat, to neni uplne spatne, ze?

[Rache]

We have done tests of algorithms and Nvidia cards are four to five times faster than the Cell chip, which is 20 times faster than an ordinary high end computer.....

[Fox!MURDER]

http://gravity.phy.umassd.edu/ps3.html
http://www.smh.com.au/news/articles/...?page=fullpage
16 x PS3 = 400 x PC

Na to, ze to je vlastne 486ka (podle Eagla), pro kterou se neda programovat, to neni uplne spatne, ze?

jenze tady tomu nikdo neupira tenhle tezce specifickej druh vykonu. ano, je to vykonny, ale ten vykon je pouzitelnej tak akorat na ty vedecky vypocty. z casti jeste na hry. na normalni pouzivani je to 486ka presne, jak to eagle tvrdil...

[THX]

ale vobec nie
3,2ghz je dost vykonu
no a co ze to nema reordering instrukcii, ked pri kompilacii su uz tie instrukcie preusporiadane prave pre tento CPU...
Na bezne pouzitie ten vykon v pohode staci, na velmi specificke veci to ma SPE.

[Fox!MURDER]

ale vobec nie
3,2ghz je dost vykonu
no a co ze to nema reordering instrukcii, ked pri kompilacii su uz tie instrukcie preusporiadane prave pre tento CPU...
Na bezne pouzitie ten vykon v pohode staci, na velmi specificke veci to ma SPE.

a proc teda apple od powerpc utekl k intelu, kdyz jsou to tak vykony procesory

[Rache]

Podle mě jedním z klíčových rozhodnutí pro migraci k intelu byla snaha o postupné sesazení microsoftu z jeho jakoby neotřesitelné pozice, protože peníze který dělá na prodeji OS microsoft jsou tak nechutně velký, že nenažranej Jobs má asi taky chuť se do budoucna přiživit, je otázka jestli současná oficiální nemožnost použití osx na jakémkoli intel/amd systému je dána pouze snahou dělat šišky na prodeji "toho správného" rozumí se u applu koupeného hw a nebo je to zapříčiněno širší nekompatabilitou a nevyladěnost systému. Těžko říct co Jobs zamýšlí, ale vzhledem k tomu jakým způsobem je u applu všechno zpoplatněno nějaká velká konkurence mrkvosoftu nehrozí..

[Keymaster]

3,2ghz je dost vykonu

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

no a co ze to nema reordering instrukcii, ked pri kompilacii su uz tie instrukcie preusporiadane prave pre tento CPU...

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ů

[THX]

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

na beznu pracu (=filmy, browsenie, mail etc.) ano. Doma mi na to staci 1700+ athlon v pohode.

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".

pozri, aj novy power procesor od IBM siel cestou vyssej freq. a zjednodusenia cpu
rozdiel vo svetoch win + x86 a linux/ine platformy je v tom, ze v x86 win svete sa robia procesory pre uz existujuce programy (ktore sa nerekompiluju - a preto robi reordering sam CPU), kdezto v lin. si mozes skompilovat program priamo na mieru konkretneho cpu a teda mozes spravit reordering (mozes presunut logiku z cpu do kompilera)

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ů

zaujimave, ale...
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...

a proc teda apple od powerpc utekl k intelu, kdyz jsou to tak vykony procesory

to uz bolo 1000x rozoberane, ale slo tam napr. aj o dostupnost, cenu HW - a ano, aj max. vykon...

[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.

[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.

[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.