0xR

0xR

Level 1

7. 9. 2010 10:44

Komentáře tohoto uživatele máš zablokované.

@JoHnY2 @Z. Obermaier: Ano, souhlasim, ze pro specialne napsany vysoce paralelni kod (nejspis s vlastni sadou instrukci) to bude mozne - neco ve stylu x87, kdyz byl jeste samostatny koprocesor. Ale urcite ne pro normalni x86 (SSE) kod, ten proste paralelizovat nejde a kdo to dokaze, ma Nobelovku jistou :).

Jinak, firemni prezentace je nutne brat s trochou te "grain of salt". Oni tam prezentuji vselico a realita je pak trosku jina. Pripadne, clovek si v nadseni rad domysli i to, co tam neni :). Ono je to videt i ve tvem clanku, ktery obsahuje dost technickych chyb a nepresnosti - treba o te delce pipeline. Ty cisla tusim 17 a 23 neznamenaji pocet stages, ale latenci jedne stage. A taky samozrejme - vic stages = vyssi frekvence a mensi vykon a ne naopak, jak je (nebo aspon vcera bylo) uvedeno. Ale nechci rypat, laickym ctenarum je to stejne fuk a ja uz musim jit zase makat :).

0xR

Level 1

6. 9. 2010 20:13

Komentáře tohoto uživatele máš zablokované.

@JoHnY2 @Chroustostroj: Lidi, neblaznete, vyuzivat GPU jadra pro x86 FPU instrukce je naprosty nesmysl.GPU ma pipeline dlouhou radove stovky stages, takze kazda takto zpracovavana instrukce by mela latenci stovky taktu. Coz je zhruba 50x vic, nez ma FPU v procesoru ;). GPU je optimalizovana pro obrovske mnozstvi nezavislych instrukci a threadu a ne pro jednotlive, navzajem zavisle FPU / SSE instrukce, ktere navic pro adresovani pameti pouzivaji standardni x86 registry a AGU. To je jako byste dali do A380 motor z F16 a mysleli si, ze bude letat nadzvukovou rychlosti :).

Kdyz to reknu jeste trochu jinak - FPU v CPU je dokonce rychlejsi, nez v GPU, ale GPU ma techto jednotek stovky. Ale pro CPU neni pocet jednotek dulezity, protoze vetsinou stejne nejde vykonavat soucasne vic nez 2 az 3 instrukce naraz, protoze v programu jsou skoky a instrukce jsou na sobe vzajemne zavisle.

0xR

Level 1

6. 9. 2010 22:15

Komentáře tohoto uživatele máš zablokované.

@JoHnY2 @Z. Obermaier: Ne nepujde. Ja se optimalizovanim a programovanim GPU a CPU (SSE) zivim, takze vim, co pisu :). I kdyby tam nakrasne bylo milion stream procesoru, tak by je nebylo cim krmit, protoze nejde provadet vic instrukci paralelne v jednom threadu, nez rekneme 3 nebo 4. Je to stejny pripad jako INT jednotky. Vic nez 2 se vyuziva tezko, proto treti INT jednotku AMD vypustilo. Mluvime samozrejme o normalnim obecnem x86 kodu s SSE. Jak uz jsem psal, ty instrukce jsou na sobe navzajem zavisle, tak jak byste je chtel paralelizovat ? A co vetveni, adresovani atp. Kazda druha SSE instrukce pracuje primo s pameti a k tomu potrebuje GP registry, kterymi GPU nedisponuje. Navic, SP rozhodne neumi stejne micro-ops, jako CPU. SSE instrukci jsou stovky a vetsinou jsou to single micro-ops. GPU podporuje kolem 20-ti instrukci +-. Nejhorsi by ale bylo vetveni, ktere se navic dela v INT casti. FPU/SSE nejde od INT oddelit, natoz provadet v GPU casti. Vase reseni mi pripomina ten trojclenkovy vtip, kdy 1 Cinan vykope jamu za 5 hodin, za jak dlouho tu jamu vykope milion Cinanu ? GPU potrebuje tisice threadu. FPU v Bulldozeru bude pracovat se 2 a navic s promichanymi INT, FPU a SSE instrukcemi, vcetne tech, co patri do vice skupin soucasne... GPU v CPU musi byt specialne programovano. Nikdy nebude provadet zadny druh x86 kodu, ani micro-ops z neho pochazejici. Kdo pise, nebo videl, jak vypada typicky x86 SSE(2,3,4) kod, tak nema pochyb. Ano, AMD APU predvedlo, ale bude to jen hodne integrovane GPU/VPU, se spolecnou cache a mozna i load/store engine. Nic vic.

0xR

Level 1

28. 3. 2011 14:34

Komentáře tohoto uživatele máš zablokované.

@0xR @dedecekhribecek: Ono je to ještě horší. Většina 64b programů prostě zaměnila 32b datové typy za 64b. Takže proměnné zbytečně zabírají dvojnásobek místa a tím i RAM, bandwidth, cache atp. A to (společně s nevyladěnými kompilátory) způsobí to zpomalení. Přičemž dobře napsaný program může díky více registrům, větší paralelizaci (a často i SSE2 místo x87) být klidně i 2x rychlejší...

0xR

Level 1

1. 10. 2009 13:10

Komentáře tohoto uživatele máš zablokované.

@Z. Obermaier To vysvetleni je proste uplne spatne a matete tim lidi. Je zajimave, ze v jinych clancich na jinych serverech je to spravne... Klidne me smazte, mne je to sumafuk, ja jsem vam spis chtel pomoct poopravit nepresnosti... Ja se programovani GPU zabyvam na profesionalni urovni a docela me pak mrzi, ze nekdo prekrucuje fakta a krmi lidi nemsysly :(.

0xR

Level 1

1. 10. 2009 13:18

Komentáře tohoto uživatele máš zablokované.

@Z. Obermaier Treba konkretne u tech atomickych operaci uvadite zrychleni 7-20 %, ale primo na tom originalnim slidu je "20x faster" a "14x faster". Neni v tom trosku rozpor ? ...

0xR

Level 1

1. 10. 2009 11:19

Komentáře tohoto uživatele máš zablokované.

Hmm, snaha o clanek dobra, ale pane autore, trochu by si to chtelo prohloubit znalosti, pripadne vygooglovat veci, se kterymi si nejste jisty. Je tam spousta hrubych nepresnosti a nesmyslu (atomicke operace nejsou zadne zakladni operace, ale operace spojujici cteni a zapis + ten narust vykonu, IEEE-754 neni nic o GPGPU, ale jen o FP, problematika FMA a MAD atd...). Nerad rypu a kazim usili, ale tohle uz bylo trosku moc :D.

0xR

Level 1

28. 3. 2011 13:13

Komentáře tohoto uživatele máš zablokované.

@kofo Píšete bludy. Na současných x86 CPU už naopak v podstatě není nic 32-bitového. Aritmetika je kompletně 64-bit. 64b instrukce trvají stejně dlouho jako 32b, jen pár méně používaných jich má na některých CPU o 1 takt delší latenci, ale to je nepodstatné.

To, že jsou některé 64b programy pomalejší, než 32b je dáno pouze horší optimalizací a lenivými vývojáři. Moje ručně laděné 64b x86 aplikace jsou naopak podstatně rychlejší, než jejich 32b verze :wink:

0xR

Level 1

28. 3. 2011 23:22

Komentáře tohoto uživatele máš zablokované.

@iagree No, a jsme prave u toho :). Nejste nahodou autorem nektereho z tech pomalych 64b paskvilu ? :)

Udelat kvalitni konverzi z 32b do 64b je podstatne slozitejsi...

0xR

Level 1

16. 2. 2011 10:48

Komentáře tohoto uživatele máš zablokované.

@kofo Ohledne toho bludu o 64b nemate pravdu. To se tykalo prvnich P4 s 64b rozsirenim. Vsechny AMD64 a Intely od Core2 jsou plne 64-bitove (krome nasobeni u starsich modelu, ale i7 ma uz i to 64b). Podobne s tou "multijadrovou optimalizaci". Sice nevim, co presne tim mate na mysli, ale pokud sdileni dat a atomicke operace, tak soucasne x86 CPU nijak zvlast za temi od IBM nezaostavaji. Do superpocitacu se nevyrabeji jen x86 CPU zejmena proto, ze napr. prave IBM si dela procaky sama a nechce pouzivat ty od konkunrence ;). Ale samozrejme mate pravdu, ze ty procaky od IBM jsou navrzeny primarne do serveru - zejmena velikosti cache, hyperthreadingem, sbernicemi a cenou :).