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

• #34 petXYZW tag con_di_B #33

  Új Válasz 2013-06-06 16:26:03 #34

  Ú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

  

  petXYZW

  tag

  válasz con_di_B #33 üzenetére

  Pontosan ezt a választ vártam.

  Ez esetben a tesztnek, a "kód-divergencia", "random memory-access pattern" vagy hasonló nevet kellet volna adni, nem pedig, hogy "tree search".

  Ugyanis így már teljesen világos a GPU lemaradása.

  A "tree search" tehát azért nem szerencsés elnevezés, mert a gráfkeresőket lehet a GPU számára emészthetővé tenni olyan módon, hogy a divergenciából eredő lassulás ne jelentkezzen és a memória elérés minták ne legyenek olyan "ordasak". Ráadásul olyan előnyi is lesznek a megközelítésnek ami kifejezetten kedvez a GPU-nak.

• #32 petXYZW tag Abu85 #30

  Új Válasz 2013-06-06 14:33:04 #32

  Ú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

  

  petXYZW

  tag

  válasz Abu85 #30 üzenetére

  "flow control hardver kell hozzá."

  Én nem hiszem, hogy ez az oka! Úgy gondolom, hogy egyszerűen feladat-párhuzamos a kód és ez fekszik a Xeon Phi-nek, míg a másik kettőnek kevésbé. Nekem ez a véleményem, de pont ezért írtam, hogy ez esetben jó lenne látni, milyen a konkrét kereső algoritmus és milyen problématérben keres. Ha egyáltalán ezt takarja a "tree search" a CLBenchmark fejlesztőinél...

• #29 petXYZW tag lenox #27

  Új Válasz 2013-06-06 09:49:09 #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

  

  petXYZW

  tag

  válasz lenox #27 üzenetére

  Szívesen megnézném a tesztek forrását, bár már egy két konkrétabb megnevezés is segítene, ezért hoztam fel a "tree search"-t...

• #28 petXYZW tag Meteorhead #26

  Új Válasz 2013-06-06 09:45:04 #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

  

  petXYZW

  tag

  válasz Meteorhead #26 üzenetére

  Most erre mit mondjak...minden szavaddal egyet tudok érteni és megértem.

  Az tény, ha bármit szeretnél létrehozni ami GPU-n fut, és nem két vektort ad össze, ahhoz tényleg "akarni kell" és egy adag szop@s garantált, amitől elmehet az ember kedve.

• #22 petXYZW tag Meteorhead #16

  Új Válasz 2013-06-06 04:48:15 #22

  Ú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

  

  petXYZW

  tag

  válasz Meteorhead #16 üzenetére

  "Azt, hogy virtuális függvényeket , függvénypointereket, polymorphizmust orrvérzésig használhat az ember számokban nem kifejezhető, és a GPUk azt nagyon soká fogják csak tudni. A HW hiába tudná már, nincs API amin keresztül rendesen ki is lehetne használni (portable módon meg aztán végképp)."

  Szerintem ezek a dolgok nem arra valók, hogy valamilyen dedikált "computational task"-ban szerepeljenek, hanem alapvetően absztrakciót, programozást elősegítő eszközök, módszerek, valóban összetett problémák megoldásához.

  A "programozóknak" az nem tetszik, hogy az OpenCL-ben programozni kell...

• #21 petXYZW tag

  Új Válasz 2013-06-06 04:33:54 #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

  

  petXYZW

  tag

  A CLBenchmark "tree search" algoritmusára kíváncsi lennék!? Vajon miért marad el a két "GPU based" megoldás a Xeon Phi-től. Illetve sejtem miért...

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