Nevite nekdo, jak to vyada s vyvojem OpenCL? Je uz k dispozici nejaka alespon trochu pouzitelna specka a implementace? Napadlo mne zkusit si prepsat sifrovani s TwoFishem (nebo jinym algoritmem, moc jsem se zatim nedival, jake TwoFish, Rijandeel a Serpent pouzivaji operace) na grafickou kartu, konecne by pak zacal behat dost rychle TrueCrypt pro cely disk ;)

NECROMAN: nicmene neves hlavu: http://brahma.ananthonline.net

nic v dohledne dobe o cem bych vedel (a to tu sedi vedle me clovek co tam ted dodelal interna)

nahodou nejaka knihovna pro programovani rovno z .net do CUDA se asi zatim nechysta, co?

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

Jen tak mimochodem, že jsem si toho tady náhodou všiml, kdysi dávno (2004?) jsem taky hledal něco, co by umělo nahradit CPU pomocí GPU...a objevil jsem projekt Brook for GPU, každopádně tenkrát se mi to myslím nějak nepovedlo rozjet a pak jsem na to zapoměl... takže koho by to zajímalo, může se tam kouknout. Mám dojem, že to jede na jakékoliv grafice co umí DX8, takže to není omezené jen na nvidii...

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 :]