Cell

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

[Fox!MURDER]

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

treba v tom, ze nektery vetveni se daj predvidat az kdyz to bezi a ty vis, ktery data a odkud tahas, popripade podle toho jak dopadlo predchozi vetveni ...