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

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

• #14 MaUser addikt Abu85 #6

  Új Válasz 2013-11-15 16:48:38 #14

  Ú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 Abu85 #6 üzenetére

  Na ja, de ha ránézel egy .net vagy java kézzel párhuzamosított vs. automatikusan párhuzamosított kódra, rájössz miért fontos, mindez automatikusan történjen. 100-ból 99 programozónak lövése sincs az adott technológiához az api-k hívásán kívül.

  Lásd jobb c/c#/c++ coding guide-ok mindig úgy kezdik, hogy ne akarj okosabb lenni a fordítónál, ha úgy hiszed többet tudsz, mint azok a srácok, akik azt írták, akkor szólj nekik és 10x-es pénzért fogsz náluk dolgozni.

• #3 MaUser addikt polika #1

  Új Válasz 2013-11-15 13:47:45 #3

  Ú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 polika #1 üzenetére

  CUDA-ra vannak létező komoly rendszerek. Egyetemeken, fejlesztőcégeknél (mármint akik ténylegesen dolgoznak velük) 99%-ban CUDA van. Két nagy hátránya volt eddig, az egyik, hogy nV-only, ami annyira nem gond, mert AMD is hasonló áron van lényegesen. Ha jönnek a filléres kínai 3rd party-k akkor AMD-nek sem lesz esélye amúgy sem.
  A másik pedig, hogy CPU-GPU közös műveletek nagyon lassúak voltak (futásidőben és fejlesztési időben is) a memóriák közötti állandó szinkornizálgatás miatt. Ez utóbbi most megszűnt. HSA "méregfogát" ezzel kihúzták gyakorlatilag, eddig ha valaki gondolkozott a migráláson, ezzel valszeg letesz róla.

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