Keresés

Hirdetés

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

  • vicze

    félisten

    válasz lenox #34 üzenetére

    Legfőképp telejsítmény+support nem csak nV részéről, hanem hogy valaki meg is építi azt az adott méretben. Tehát nem egy 1db "mezei" W9000 hanem 20db egybekötve egy kész rackben. Ilyen volt a FireStream és most ilyen a Fire S, de közte 4 évig semmi. Közben a nV meg elég csúnyán betolta a Teslát ebbe a szektorba. A váltás meg sok zöldhasúba kerül. Ráadásul a Fire S mocsok drága a Teslához képest teljesítmény arányosan.

    Amire ti használjátok, ha jól sejtem az az nV-nél a Quadro és nem a Tesla.

  • Meteorhead

    aktív tag

    válasz lenox #34 üzenetére

    Mi is körülbelül azt csináljuk, amit ti. Úgy fejlesztünk, hogy mindenhol elfusson. Vannak azért generikus adatpárhuzamos optimalizációk, amik a diverz architektúrák ellenére gyorsítanak mindenütt:

    + __local terhelése GPU-n LDS-t használ, CPU-MIC-en pedig cache optimizationnek felel meg.

    + coalesced NV-nek nagyon kell, többiek vagy profitálnak vagy mindegy nekik (AMD-n channel conflict többet számít)

    + az ember annyi built-in intrinsic függvényt használ, amennyit csak lehet

    + ha van hordozható extension valamihez (cl_khr_extended_atomic_int32) akkor használja az ember, mert nagyságrendeket tud gyorsítani __global atomicon AMD-n például.

    Sima OpenCL valóban egy fos, ebben igazad van. Mi ezért utazunk SYCL-ben, de miután SYCL is, és linuxon C++AMP is OpenCL-re dependál, ezért amíg nV-nek nincs SPIR fordítója, addig kiesett a játékból. Egyébként osztom a véleményed, ami OpenCL-re van megírva, azt hordozhatónak tekintem. Amíg nincs zöld implementáció, addig egyszerűen unsupported-nek van titulálva. Csak bosszant, hogy saját magukat szabotálják el, mert ezzel az én piacom is csökken. Nem tudok zöld gépeken futtatni.

    Nálunk többnyire mindenki a saját notebookján fejleszt, tesztelni a klaszterünkben lévő mindenféle vason szoktunk, és ha stabil a számolás, több gyártó implementációjával is ugyanaz az eredmény, akkor 100 iteráció helyett 10.000.000 iterációval rátoljuk a nagy klaszterre, ami Radeonokkal van kitömve.

    Most egyébként egy olyan libet fejlesztünk, ahol lesz minden feature-nek egy generikus implementációja, ami ezeket az ökölszabályokat veszi figyelembe, és ha marad kapacitás, akkor a program egyes részeihez meg lehet írni az architektúrákra optimalizált változatot is. Az egyikkel az elméleti kapacitás ~60%-át lehet elérni, a másikkal ~75%-ot. De ezért a 25%-os sebesség növekedésért első körben nem éri meg izzadni.

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