Jakykoliv snizovani vykonu x87 jednotek je totalni kravina, a bude to kravina dokud neprijdou programovaci jazyky kde ty SSE/AVX atd jsou pouzivat v beznym kodu.
Kdyz clovek chce rucne vyuzit SSE misto klasickejch x87 instrukci tak nemuze v programu napsat
"x = 5.5*a"
ale skonci u neceho typu
"v1[0] = 5.5;
v2[0] = a;
ssemulfpacked(v1,v2,v3); //bacha je to makro a ne funkce...
x = v3[0];"
pripadne primo u inline assembleru. (a jeste nesmi delat v jave, C# ....) Jasne kdyz potrebujete vynasobit 2 pole tak je to super, ale za posledni rok sem snad takovou ulohu neresil.
del42sa píše:DOC_ZENITH: Už vidim to grafické jádro jak nám počítá x87 thread..... to je naprostá utopie.
a proč ne ? vždyť tou jsou jen výpočty s plovoucí desetinnou čárkou. Co myslíš že počítají třeba takové Tesly ?
Protoze naprosta totalni nepouzitelna pomalost? Sice ti tam litaj teraflopsy jenze na tisicich jednotek. Radeon 7970 ma 3,79Tflops na 2048SP si to vydel: 1.8GFlops na SP, + zvyseny latence vypoctu, + to musis pustit mimo CPU na nejakejch jinejch knihovnach (dalsi latence) a pak muzes bejt rad ze se dostanes na 5% rychlosti na GPU. Jak to neni algoritmus paralelizovatelnej z vice jak 90% tak nema cenu o GPU vubec uvazovat.
Se mrkni na Amdahlův zákon. Kód paralizovatelnej z 50% znatelne nezrychlis od 16 vypocetnich jendnotek. kdyz by byl paralelizovatelnej z 95% tak uz nemas zadnej prinos zvysovanim poctu jednotek nad 2000. A to paralelizovatelny je tak asi zpracovani signalů a fyzika. Nemluve o tom ze je to za idealnich podminek a zanedbavaj se casy ztraceny na synchronizacich, parkovani vlaken a podobnejch blbostech, ktery v tom nejsou zapocteny.
Kdyz oznacis kus kodu, kterym muze probihat vic vlaken jako usek kde v jednu chvili muze bejt jenom jedno. Tak zamek ma aktualne latence kolem 50ns (pri pouziti mutexu a semaforu z win api uz je to o dva rady pomalejsi) takze prubeh metody jednim vlaknem je o 100ns pomalejsi (uzamknuti a odemceni). Kdyz je to zamceny dalsi vlakna cekaj a nic nedelaj (vyyykon klesa).
Vraz to do kritickyho mista v programu a pak ma te na novim 4 jadru se stestim vykon 150% toho co na 1 jadru. A 10* pomalejsi vyvojovy cykly a ladeni. Jak se nekde musi neco synchronizovat jde vykon do kytek. A lock free multithreading pouzitelne zvlada 10 lidi na svete
Vetsina "Vedecky prace" je prekvapive to sami, paralelni vypocty zadny, jenom to rozdelis do single thread uloh, kazda dostane balicek dat a bezi si minimalne par minut. (aby prestali mit vyznamnej vliv casy na inicializace a distribuci dat). Pak spustis 4 tyhle balicky na 1 pocitaci, na 100 pocitacich v clusteru. Za den prijdes, shromazdis vysledky v jednovlaknovy aplikaci na svim PC, to taky den pocita a je to.
edit:
nou píše:pouzivaju sa pomalosti typu Java/C# alebo dnes este horsia zhuverilost JavaScript/HTML5 kedy sa musi vykonat tisice...
C# neni vyznamne pomalejsi jak C++ (microsofti kompilator, x86/x87 kod), ted naposled jsem dostal na vypoctu CRC32 (4KB tabulky) dokonce asi o 3% nad vykon C++ kodu. Jedinej problem je, ze clovek musi klesnout do unsafe kodu a pouzivat ukazatele. Vsechnu rychlost v dobre napsanym kodu zere detekce hranic poli, pak volani nativnich knihoven (kde ten call je pomalejsi o locknuti dat v pameti a pripadnej preklad datovejch typu na neco pouzitelnyho a nasledny unlocknuti), a pak vecny kopirovani bufferu misto toho, ze ukazatel pretypuju na neco jinyho
