- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Megérkezett a legújabb és eddigi legátfogóbb 3DMark teszt
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Milyen egeret válasszak?
- Gaming notebook topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- GoPro Topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen Android TV boxot vegyek?
Hirdetés
-
Visszatérne a PC-s kliensbizniszbe az NVIDIA
ph A Bloomberg videointerjújában utalt erre a Dell és az NVIDIA vezére.
-
Elon Musk: az xAI szuperszámítógépet akar az AI-alapú chatbotjához
it Elon Musk tervei szerint egy szuperszámítógéppel szolgálják majd ki az xAI Grok chatbotjának következő verzióját.
-
Így fest a Steel Effigy korai béta változata
gp A külső nézetes hack&slash akciójáték az előzetes információk szerint PC-re érkezik.
Új hozzászólás Aktív témák
-
#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?
-
Abu85
HÁZIGAZDA
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Z_A_P
addikt
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"
[ Szerkesztve ]
OK
-
Abu85
HÁZIGAZDA
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- bambano: Bambanő háza tája
- Óra topik
- Ukrajnai háború
- Megérkezett a legújabb és eddigi legátfogóbb 3DMark teszt
- Anglia - élmények, tapasztalatok
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Samsung Galaxy A54 - türelemjáték
- Google Pixel 6/7/8 topik
- Diablo IV
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen