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

• #30 pakriksz őstag MaUser #29

  Új Válasz 2013-11-18 15:35:33 #30

  Ú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

  

  pakriksz

  őstag

  válasz MaUser #29 üzenetére

  parallel for az pont ugyan az az mintha csinálnál külön threadeket, csak rövidebben leírva.
  Egyébként java-nál ugyan ezt lehet elérni egy sima forral, és egy executorservice-el.
  De ez semmit nem old meg, amire ezt lehet használni, azt amúgy is 2 perc alatt lehet párhuzamosítani, szóval halottnak a csók effekt.

  Igen a szinkronizálással szívnak, de ez is a többszálúsítás legnagyobb mumusa.

• #26 pakriksz őstag MaUser #25

  Új Válasz 2013-11-17 22:12:44 #26

  Ú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

  

  pakriksz

  őstag

  válasz MaUser #25 üzenetére

  Hát már bocs de ezt nem hiszem el... Nem is nagyon létezhet olyan algoritmus ami felismer olyat amit egy embernek sem könnyű...
  Ha ez igaz lenne, minden program gyönyörűen skálázódnak akárhány magra, de messze nem így van.
  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ő.

  Java pedig kb csak abban a linkben van lemaradva kb (amire még mindig nem jöttem rá mi értelme (1 lépés előre 1 lépés hátra)), meg pár hasonló jelentéktelen dologban, engem csak az unsigned számok hiánya zavar.

  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.

• #24 pakriksz őstag MaUser #23

  Új Válasz 2013-11-16 23:05:18 #24

  Ú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

  

  pakriksz

  őstag

  válasz MaUser #23 üzenetére

  mert ezzel a többszálúsítás kb 30%-át lehet megoldani. a többit szálkezeléssel kell.

  Pl csináltam egy programot ami bazi nagy xml-eket módosít javaban. Bár az xml feldolgozó libek tényleg több szálúak, de 1 xml feldolgozása maximum 1,7 magot tudott leherhelni a 4 ből. És ilyenkor jön az hogy "batch"-ban indítom a feldolgozást, több szálon, így 1 helyett mondjuk 4 xml-el dolgozik párhuzamosan, így garantáltan kihasználódik mind a 2 mag.

  Vagy megírsz egy játékot threading nélkül szinte semmit sem fog érni hogy néhány alaplib többszálú. Semmi sem fogja azt szétszedni több szálra a lényeget, neked kell szépen külön szálba rakni a rendert, a fizikát, a betöltést, a hangot.

• #17 Fiery veterán MaUser #14

  Új Válasz 2013-11-15 20:44:33 #17

  Ú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 MaUser #14 üzenetére

  "Lásd jobb c/c#/c++ coding guide-ok mindig úgy kezdik, hogy ne akarj okosabb lenni a fordítónál"

  Az a baj, hogy a C forditokkal ellentetben az OpenCL es CUDA forditok eleg butak tudnak neha lenni, nem art nekik egy kis segitseg. A CUDA 6 unified memory "varazslata" meg max. akkor mukodhet a gyakorlatban kielegitoen, ha relative keves masolasi muveletre jut egy csomo GPU szamolgatas (computing). Ellenkezo esetben ugyanolyan sz** lesz, mint egy nem atlapolt kezzel valo memoria masolasi megoldas. Teny, hogy a lusta programozoknak jol johet ez a kis segitseg; de aki lusta GPGPU fejleszto, es nem kotik a kezet guzsba (azaz valaszthat AMD es nVIDIA hardver kozul), az inkabb a HSA kornyeken fog nezelodni, ott legalabb valoban nincs szukseg memoria masolgatasra.

• #16 pakriksz őstag MaUser #14

  Új Válasz 2013-11-15 20:29:37 #16

  Ú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

  

  pakriksz

  őstag

  válasz MaUser #14 üzenetére

  Micsoda? automatikusan párhuzamosított kód? Azt hogy?

• #6 Abu85 HÁZIGAZDA MaUser #3

  Új Válasz 2013-11-15 14:05:38 #6

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz MaUser #3 üzenetére

  A memóriák közötti szinkronizálást nem szünteti meg a CUDA 6, csak leveszi a terhet a válladról. Ami szarul fut az ezután is szarul fog futni, csak nem kell beleölnöd annyi munkaórát. De erre az NV-nek is megvan az integrációja, ami első körben a Maxwell és az ARMv8 párosítása. De ugye az IBM-mel dolgoznak a Poweren is, így a Maxwellt ahhoz is áttervezhetik.

  (#7) Kopi31415: A hardver szintjén nem közös a címtér. A CUDA 6 csak annyit csinál, hogy amit eddig a programozó optimalizált, azt a háttérben megcsinálja helyette. Ettől függetlenül a memóriamásolás megtörténik. A beleölt munkaórában vagy előrébb.

• #4 Bici félisten MaUser #3

  Új Válasz 2013-11-15 13:56:02 #4

  Ú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

  

  Bici

  félisten

  válasz MaUser #3 üzenetére

  De ettől még nem lesz fizikailag egyben a memória, vagyis a buszokat ezután is terhelni fogja, csak nem a fejlesztőnek kell vele foglalkoznia, hanem a runtime megoldja. Nem?

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