DURDIN: Optimalizovat se smyslu lepšho využití paměti atd. to neumím, jsem matematik. Optimalizovat ve smyslu chytřejšího algoritmu, to už jsem udělal a nevím jak. Teď se snažím o novej přístup v tomhle systému..
Mám, už to i běželo..

MAIMONIDES: nevidím do toho, ale nebudeš mít lepší optimalizovat ten samotný algoritmus, než použít sice možná rychlejší, ale hardwarově závislé řešení? btw. když to je diplomka, nemáš možnost to ve škole pustit na nějakém matematickém clusteru?

Díky:)

MAIMONIDES: Ted nevim co myslis. Muzes mit vic gridu (de facto jinej program), vid bloku (stejnej program, jiny data).
A stridaj se thready v blocku a blocky v gridu a gridy taky nejak.
Nic z toho nepomuze s ifem, pomuze to pri prekrejvani vypadku pameti.

CPU ma pristup do L1 cache v jednotkach taktu, L2 radove desitky.

GPU pameti je takovej kotel, ze bych si takovou generalizaci asi nedovolil, ale pristup do offchip trva ty stovky taktu (casove cca stejne jako na CPU, i kdyz tam je to vic cyklu). Respektive, ten rozdil v pristupu do hlavni pameti je radove 2X. Jenze GPUcko nema (tady) skoro zadnou cache, ale zase to prekrejva jinejma warpama, takze to je fakt nesrovnatelny :-D

NECROMAN: Asi tak:DAVIDOWITCH.
Každopádně gpu má těchhle vláken stovky, takže ve vhodně přepsané vhodné úloze to bude i x1000.


DAVIDOWITCH: myslim, že těch výpočtovejch "skupin" je tam víc, takže při vhodnym rozdělení můžeš mít věci vesele paralelní, ale jinak máš pravdu.


Nejsem si jistej jak je to u cpu paměti, ale přístup do gpu paměti zabere 300-400 cyklů, přístup do registru nebo aritmetika trvá kolem 4 cyklů..

DAVIDOWITCH: uz jsem se bal zes to tady prehlidl a chtel jsem ti hodit link do posty :]

NECROMAN: To se vicemene vubec neda srovnat. Protoze kazdej procak ma (co se vlaken tyce) dost jinou architekturu.
Na GPU jsou vlakna de facto cheat jak udelat SIMD programovani zkousnutelnejsi.
Vsechny ty vlakna a warpy a buh vi co jsou maskovani pro to, ze to je 32way SIMD (no, on je to 8way SIMD co bezi na 4x).. Co vlakno to jedna "pozice" v tom SIMD registru, neaktivni vlakna jsou jen odmaskovany.
Takze kdyz se tehle 32 vlaken rozhodne jit ifem ruznejma smerama, tak se provede pro vsechny to samy, ale nektery vlakna sou maskovany v "taken" vetvi a jiny v "not taken" vetvi.

Cisty porovnani processing power pak strasne zavisi na uloze. Pokud pojedes nejaky floatovy operace na sekvencnim kusu pameti, tak GPU da CPU strasnym zpusobem na prdel. Pokud naopak pojedes nejaky hodne random access programy s minimem faktickejch vypoctu, tak da CPU na prdel GPU.
CPU zvladne realne (s cekanim na disk a tak) cca 4x tolik threadu co ma jader (nejak rozumne uprepinat, aby vzdycky bylo co delat). GPU jich zvlada tisice, ale i to prepinani ma uplne jiny (jemnozrny vs hrubozrny).

MAIMONIDES: jak je to treba s vykonem, kolik toho spocita "jedno vlakno" u GF 8800 GTX, vs. jedno vlakno na prumernem Core2Duo a take, kolik takovych vlaken zvladne GF soucasne?

tomu se tady člověk vyhne..

Btw. na matfyzu je moznost vyuzit i 11x8 procesorovy bladeserver, celkem 10+1 stroj, kazdy dva Xeony po 4 jadrech. Zkouseli jsme na tom loni programovat a je to zajimave, co to dokaze... ale zvladnout poradne MPI neni zadna sranda.

MIKEE: Jo tak. Hmm, to imho neplatí. Jen s tím musíš počítat a vyhnout se případně konfliktům s pamětí a případně synchronizovat ručně. V CUDA je těch paralelních procesů velice mnoho, ale jsou velice "tenké", takže každym člověk zpracovává jednu buňku v matici nebo tak..

no ja se tesim na to Larrabee od Intelu, protoze to konecne i lidi jako jsem ja budou moci delat skutecne vicevlaknove aplikace :-)))

MAIMONIDES: urco se pochlub, ja bych si to rad u sebe pustil :)

MAIMONIDES: branch = conditional jump :] ... tj. ze sice to bezi paralelne, ale pokud polovina vlaken bude mit v kodu na skoku true a polovina false, tak to pojede seriove dokud se nevyhodnoti obe vetve skoku .. ze to je schopny pocitat paralelene jen pokud se vyhodnocuje opravdu kompletne stejny kod (az na data)

MIKEE: Nerozumím pojmu v tomhle kontextu. Jinak je code branching o vývoji aplikací, ne?
Kód v CUDĚ pojede sériově, pokud dojde ke konfliktu v paměti(dvě vlákna obcují s jednou adresou) nebo pokud přeženeš paměťové nároky na registry..

MAIMONIDES: jo, zadna prdel to neni .... ja nakonec vzal Cell, protoze na G80tkach ti ten kod musi branchovat (to je slovo ;]) stejne, jinak to jede seriove, zejo .. a to se mi nejak nelibilo :]

Aha, toho jsem si nevšiml. Koukám, podle internetů je to taky dost složitý programování:)

MAIMONIDES: na Cell nemam, ve skole jsou dve PS3 na ktery se pripojuju z dalky ;] .. a ted to snad i rozchodim doma, protoze novej spoludbylici PS3 vlastni

SUCZKER: Jo, tak to říkám v hospodě:)

MIKEE: Koukám, to je něco podobnýho. Jestli máš na cell, tak si pořiď rovnou tu poslední Teslu:)

http://forums.nvidia.com/lofiversion/index.php?t58846.html ikdyž pořádný srovnání tam neni..

MAIMONIDES: to si uzivej, ja na tom mohl delat diplomku taky, ale nakonec ji delam na IBM Cell :] taky je to prilis pomaly, a taky to pomalu prepisuju :]

Doufam, ze ke CUDA se brzo taky dostanu .. jen co upgradnu na nejakou slusivou nVidia kartu (ponejlepe asi 260GTX)

MAIMONIDES: Resitel sudoku ;) Jsem zvedavej, jak se ti to podari zrychlit...

NECROMAN: Řada 7xxx to ještě neumí, viz odkaz kurzivou. Nicméně pokud tě láká to programovací prostředí, tak je tam k dispozici "emu_mode", kterej to zkompiluje pro cpu. Používá se například pro ladění.

LITTLELI: Diplomku, hledám zvláštní vlastnost dvojic latinských čtverců 8x8. Mám to jako obyč kód, ale to je příliš pomalý a tak to pomalu přepisuju... až bude hotovo, tak ti dám vědět:)