Cell

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