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

• #11 Bici félisten Abu85 #10

  Új Válasz 2017-05-24 15:01:45 #11

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

  Áhh, értem már. Kössz!

• #10 Abu85 HÁZIGAZDA Bici #9

  Új Válasz 2017-05-24 14:32:40 #10

  Ú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 Bici #9 üzenetére

  A munka hiánya. Az OpenCL-ből is ki lehet hozni ugyanazt, csak nincs akkora akarat, hogy kellő pénzt és energiát rakjon bele a közösség. A HIP kód azért tud gyors lenni, mert áthozza a CUDA kód optimalizálásait is.

• #9 Bici félisten Abu85 #8

  Új Válasz 2017-05-24 14:31:26 #9

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

  Ez mitől van? Maga az OpenCL felépítése a ludas, vagy az AMD openCL fordítója?

• #8 Abu85 HÁZIGAZDA Bici #7

  Új Válasz 2017-05-24 13:20:17 #8

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

  A kódtól függ. Ha mondjuk CUDA kódot kell portolni, akkor a HIP sokkal kézenfekvőbb. Például a CAFFE nevű deep learning keretrendszert Tip verzióját, ami ugye 55000+ soros programkód, lényegében négy nap alatt leportolták HIP-re (ebből automatikus, HIPify konverzió volt 54000-nél valamennyivel több sor). Manuálisan kb. pár száz soros módosítást igényelt, és a teljesítménye megegyezik a CUDA kóddal.
  Az OpenCL portnál már 32000-nél is több sort írtak át benne manuálisan, hónapok óta fejlesztik, és a teljesítménye el sem éri a CUDA/HIP verziót.

• #7 Bici félisten Abu85 #2

  Új Válasz 2017-05-24 13:15:14 #7

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

  AMD hardveren gyorsabb a HIP, mint az OpenCL?

• #6 Z_A_P addikt Abu85 #5

  Új Válasz 2017-05-24 13:06:22 #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

  

  Z_A_P

  addikt

  válasz Abu85 #5 üzenetére

  A kisebb a jobb.

  Hmmm, ott irja alatta Cuda time/cuda-on-cl time.
  Azaz ha Cuda lefut 2 sec alatt, cuda-on-cl 1 sec alatt (azaz 2* gyorsabb a cuda-on-cl), akkor kapsz 2.0
  Azaz ha Cuda lefut 1 sec alatt, cuda-on-cl 2 sec alatt (azaz 2* lassabb cuda-on-cl), akkor kapsz 0.5-ot.

  Azaz a hosszabb vonal (>1.0) akkor gyorsabb a cuda-on-cl.

  Szerk: de most latom irja is utana: "longer line: cuda-on-cal faster"

• #5 Abu85 HÁZIGAZDA Z_A_P #4

  Új Válasz 2017-05-24 13:01:17 #5

  Ú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 Z_A_P #4 üzenetére

  A kisebb a jobb. Elvileg ugye time. Akkora eltérés egyébként nincs, tehát bőven lehet választani a Coriandert, kivéve a full reductiont, mert ott a CUDA jóval gyorsabb. De ezen állítólag lehet javítani.
  A legfontosabb itt a választás lehetősége. Egy reálisan megfontolható olyan lehetőség, ami eddig nem volt.

  (#6) Z_A_P: Ja elég nehezen értelmezhető. Most már kezd átlátható lenni. Köszi.

• #4 Z_A_P addikt Abu85 #3

  Új Válasz 2017-05-24 12:57:49 #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

  

  Z_A_P

  addikt

  válasz Abu85 #3 üzenetére

  Teljesítmény kell vagy portolhatóság. A kettő együtt ma nincs

  
  Hat itt nekem ugy tunik hogy a cuda-on-cl kb gyorsabb mint a cuda. Ugye 1.0 egyenlo sebesseg, >1.0 gyorsabb, <1.0 lassabb.
  A legtobb >=1.0.

  

  Vagy rosszul ertelmezem?

• #3 Abu85 HÁZIGAZDA Abu85 #2

  Új Válasz 2017-05-24 12:32: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

  

  Abu85

  HÁZIGAZDA

  válasz Abu85 #2 üzenetére

  Ehhez még annyit lehet hozzátenni, hogy itt az egyes projekteknél a két véglet a lényeg. Teljesítmény kell vagy portolhatóság. A kettő együtt ma nincs. Nagyjából az a helyzet, hogy ha teljesítmény kell, akkor CUDA vagy HIP kódot érdemes írni, de ezzel bukik a portolhatóság. A CUDA NV only, míg a HIP NV (NVCC) és AMD (HCC) only. Ha a portolhatóságon van a szempont, akkor a Coriandert érdemes használni, mert az OpenCL 1.2 iparági szinten széleskörűen támogatott, és sok a CUDA kód. Ha pedig egy ideális átmenetet keresnek a portolhatóság és a sebesség között, akkor ott a ComputeCpp és a triSYCL, de itt mindenképpen kell SPIR támogatás a gyártók részéről, tehát ez sem egy széleskörűen támogatott megoldás, noha a CUDA/HIP opcióknál nagyobb piacot lehet vele lefedni. Ide viszont manuálisan kell az eddigi kódokat leportolni, de nem olyan nehéz ez, mint manuálisan OpenCL-re portolni.

• #2 Abu85 HÁZIGAZDA #06658560 #1

  Új Válasz 2017-05-24 12:25:21 #2

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

  A HIP azért lényeges csak, mert arra CUDA-ról könnyű áttérni a konvertáló miatt. És a HIP kóddal ugyanolyan hatékonyan lehet kiszolgálni az NV és az AMD hardvereit. De a CUDA és a HIP már nem jól portolható OpenCL-re, tehát itt a HIP is ugyanazokkal a problémákat hozza, amiket a CUDA. Eleve az volt a célja, hogy a CUDA másolata legyen, vagyis dettó ugyanúgy működjön, csak az API hívások nevei mások. Az OpenCL-hez a HIP-nek nincs is semmi köze.

  A legfontosabb, hogy a kódszintjén senki nem akar két kódbázist. Egyet akar csak. Ha OpenCL-t, akkor a CUDA és a HIP nem jelent problémát, mert eleve OpenCL-ben van a kód. Ha CUDA-t akar, akkor a Corianderrel a CUDA kódból kiszolgálható az OpenCL. Ha HIP-et használnak akkor pedig a CUDA-HIP hasonlóság miatt CUDA-ra konvertálni gyerekjáték, és onnan megint mehet a Corianderes buli.

• #1 #06658560 törölt tag

  Új Válasz 2017-05-24 12:05:59 #1

  Ú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

  

  #06658560

  törölt tag

  "Ez azért problémás, mert CUDA-ról OpenCL-re és fordítva portolni igen drága az ipar számára, pedig maga a probléma annyira jelentős, hogy bőven lenne igény egy ilyen megoldásra."

  Ez így tömény bullshit, értelmezhetetlen baromság.

  Ha CUDA és OpenCL. is kell valakinek, az miért is fejlesszen OpenCL-ben HIP-pel, ha arra pont tud fordítani, visszafele a hír alapján pedig nem? A cikkből megint hol maradt a logika?

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