Új hozzászólás Aktív témák

• #31 MaUser addikt pakriksz #30

  Új Válasz 2013-11-18 16:56:32 #31

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  MaUser

  addikt

  válasz pakriksz #30 üzenetére

  A parallel.for-ral, cilk_for-ral, parfor-ral megmondod a fordítónak, hogy légyszíves csinálj nekem egyszerűen thread-eket amennyit bírsz és érdemes az erőforrások függvényében és végezd el ugyanazon műveletek az egyes thread-ekben. Ezt nem hiszem, hogy két perc alatt kódolod le, még ha snippetből dolgozol is vagy baromi gyorsan gépelsz, ráadásul itt egyből kapsz visszajelzést is gépelés közben, mert a környezetek ezt támogatják. HA olyan egyszerűek a műveleteid, hogy érdemes GPU-ra váltanod, akkor goto CUDA, az erre való.

  Amiről te beszélsz az a szálak szinkronizálása, de ebben semmi új nincs, a szinkronizálás meg egy szál esetén is meg volt (pl. IRQ v. port figyelés, stb.). Ezt az életben nem fogod tudni elkerülni, mert a fordító soha nem fogja kitálni, hogy egymástól függő dolgokat, hol és hogyan akarsz te, mint programozó összefűzni és ennek semmi köze a CUDA-hoz.

• #29 MaUser addikt pakriksz #26

  Új Válasz 2013-11-18 14:00:01 #29

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  MaUser

  addikt

  válasz pakriksz #26 üzenetére

  Most akkor dobjak fel egy fotót arról, hogy az adatbányászati alogritmusaim 4 szálon, gyakorlatilag 90% környékén használják a négymagos procit sima parforban PCT-vel?

  A .net-es for párhuzamosításra meg MS-es előadást is tudsz találni, ha nem akarsz kézzel méricskélni.

  Egyébként rálátok egy .net-es (jelenleg 3.0-ás verzióval van fordítva) játék játék fejlesztésére és sok profi programozó keményen megküzd a többszálúsítással, ami még így sem olyan amilyennek szeretnék bár ez részben a hulladék direct3d korlátainak köszönhető.

  És ők mivel szívnak konkrétan? Gondolom nem azzal, hogy egyszerre négy szálon egymástól független adatokat feldolgozzanak, hanem azzal, hogy szinkronizálják a szálakat.

  Gyanítom hogy ha ugyan ezt az xml-es cuccot kipróbálnám .net-ben, és 1 szálra írnám, a for ciklusban bambán egymás után dolgozná fel mindet, ahogy a java, és semmit sem ismerne fel.

  Próbáld ki és kiderül. Ha nem vagy elégedett a kapott eredménnyel v. nem akarsz beállításokkal molyolni, akkor ott a Parallel.For utasítás és öröm boldogság egyből. Igaz, ez ha jól rémlik .net 3.5-től van, ellőtte külön kellett feltenni és talán nem is volt hivatalosan release-elve.

• #28 LordX veterán pakriksz #26

  Új Válasz 2013-11-18 10:46:58 #28

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  LordX

  veterán

  válasz pakriksz #26 üzenetére

  Ne keverjétek össze a task alapú párhuzamosítást és az adatpárhuzamosítást. Amit a .NET / Java / akármelyik mainstream programnyelv fordítója tud, az task és short vector (SIMD) párhuzamosságot, a CUDA meg adatpárhuzamosítást használja ki. A kettőnek azon kívül, hogy "párhuzamosítás", túl sok köze nincs egymáshoz. A CUDA felépítése miatt majdhogynem triviális azokat az optimizációkat automatikusan elvégezni, amiből ez a szál kiindult, nyugodtan elhiheted, hogy képes a fordító rá. És az is igaz, hogy nem ősrégi fordító (.NET 3.0 már annak számít) alapján kéne végső igazságokat kijelenteni, bár annyira nem eszik forrón a kását, a mai fordítók nem jól dolgoznak, hanem csak elfogadhatóan..

• #27 Jack@l veterán pakriksz #26

  Új Válasz 2013-11-18 09:30:44 #27

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Jack@l

  veterán

  válasz pakriksz #26 üzenetére

  Lehet át kéne térni .net 4.5-re, me a 3-as má ölég régi jószág... (meglepődnél mik nem vannak benne többszálúsításhoz )

• #25 MaUser addikt pakriksz #24

  Új Válasz 2013-11-17 19:38:39 #25

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  MaUser

  addikt

  válasz pakriksz #24 üzenetére

  A xlm-es példádra pont jók a modern fordítók, amit most batch-ként futtatsz, azt felismerik, ha van megkötés azt meg megtalálod a dokumentációban. Javával nem tudom mi a helyzet, már .net 2.0 idején is le volt már maradva, azóta szerencsére nem dolgozom vele, de ismerősök szerint az olló csak nyílik és nyílik.

  A másik példánál, ha jól értem, arra kéne a több szál, hogy az interakció minél inkább real-time legyen. Ez tudományos/mérnöki életben nagyon ritka. Nyilván customer programnál ez kell, itt nincs mese, ezt kézzel kell. Azonban egy szálon is ugyanez volt a helyzet, itt nincs difi, csak most nem a programfutási szálat szakítgatod meg kézzel a bement kedvéért, hanem még kiegészül azzal, hogy a programfutási szálát a kívánt interakció mértékében több szálra szedheted szét.

• #23 MaUser addikt pakriksz #22

  Új Válasz 2013-11-16 00:04:27 #23

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  MaUser

  addikt

  válasz pakriksz #22 üzenetére

  Már miért lenne édeskevés Ezzel az esetek jó része megoldható. A gond ott van ha szálak között kell adatokat kezelned. Itt is két eset van, ha ritkán vannak ilyen esetek, akkor írtsz rá kézzel valami ütemezőt, ha meg gyakran kell szálak között adatokat átadni, akkor nyilván bukta. Ez esetben viszon goto másik algoritmust nézni, mert az esetek túlnyomó többségében lesz olyan, aminek a vége egymástól független vektor és/vagy mátrixművelet lesz. Nyilván lesz egy nagy overhead-ed, de párhuzamosítás miatt mégis jóval gyorsabb leszel. És főleg nem kézzel optimalizálgatsz és csinálsz a végén ugyan valamivel gyorsabb, de 10x nagyobb kódot 10x több hibával.

• #21 MaUser addikt pakriksz #16

  Új Válasz 2013-11-15 22:10:36 #21

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  MaUser

  addikt

  válasz pakriksz #16 üzenetére

  Az összes modernebb fordító tudja pl ma már azt, ha egy for ciklus nem függ a ciklusváltozótól/előző elemtől, akkor pl. több magra szét tudja dobni a ciklus lépéseit. Nyilván ez nagyon buta példa, de matlab már 1000 éve tudja, ha manuálisan parfor-t használsz akkor megfelelő számú worker-en fog futni a for ciklus. Nyilván innen egy lépés lenne, hogy a PCT méltóztasson ne csak futtatás közben felismerni, ha van ciklusfüggő változó, hanem már a kód írása közben. MS viszont már .net 3.0-át ezzel is hirdette, ott ráadásul sima for-t is szétdob a fordító több magra automatikusan, ha úgy látja, hogy megteheti. Jacket alatt meg ott van a gfor, ami megpróbál vektorizálni pl.

  Nyilván a nem erőforrás igényes részeknek meg tökmindegy hány magon futnak.

  Nyilván nem az lesz, hogy a fordító felismeri a gányolt fft-t és 4 magra csinál belőle egy olyan binárist mintha cilk fft-t használtál volna tökéletesen.

• #20 Fiery veterán pakriksz #19

  Új Válasz 2013-11-15 21:11:03 #20

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Fiery

  veterán

  válasz pakriksz #19 üzenetére

  A legtobb szoftvernel eleg csupan reszfeladatokat, meghozza a leginkabb teljesitmeny-erzekeny reszfeladatokat parhuzamositani. Ha azt meg tudja oldani akár a CUDA, akár a HSA, akár barmi mas hatekonyan es egyszeruen, az mar eleg jo lesz a legtobb fejlesztonek.

• #18 Fiery veterán pakriksz #16

  Új Válasz 2013-11-15 20:46:04 #18

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Fiery

  veterán

  válasz pakriksz #16 üzenetére

  A HSA pl. tud majd ilyet, Java kodot automatikusan vektorizalni es az iGPU-n futtatni.

Új hozzászólás Aktív témák