SATAI: pokud se cuda rozšíří dostatečně, je šance, že to ostatní převezmou za standard, ne?

DAVIDOWITCH: nemam chut takove veci prepisovat co pul roku (v poci mam NVidii, ale kdo vi, co si poridim za rok? a kdybych se o ten kod chtel podelit, tak...)

JOHNYDOG: u TrueCryptu je zpomaleni pozorovatelne, obzvlaste kdyz pouzivas kaskadu

SATAI: ja pouzivam fulldisk encryption s AES (pres dm-crypt/luks) a maximalni zpomaleni v testech je nekde 1%-8%, vyuziti CPU 0.0nic takze bych tipoval ze limitujici faktor je spis IO nez CPU. Jinak treba distributed.net ma experimentalniho CUDA clienta pro crackovani RC5-72 (http://dungeon.darktech.org/hg/hgwebdir.cgi/dnetc_cuda/file/9ab1cf0f17f7/rc5-72/cuda/r72cuda1.cu), i kdyz je to samozrejme neco jineho nez plne sifrovani/desifrovani tak to stoji za nahlednuti :)

njn, ale i tak, stejne to primarne pobezi na nVidia kartach. Protoze ATI ma nejakou podezrelou VLIW architekturu, alespon naposledy co sem koukal tak melo. A Larrabee bude mit prvni silicon nekdy ve ctvrtym kvartalu pristiho roku (a obecnej odhad je, ze az Larrabee 2 bude realne pouzitelny a srovnatelny vykonem s nVidia chipama)

DAVIDOWICH: NVIDIA ;)
Prijde mi to jako svizna cesta smerem vendor lock-in.

SATAI: V cem je problem napsat to primo v CUDe?

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?