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

• #7 szabi80sz tag dezz #6

  Új Válasz 2011-11-18 18:00:05 #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

  

  szabi80sz

  tag

  válasz dezz #6 üzenetére

  1. Az OpenCl inicializálása (csak az inicializálása!) olyan lassú, hogy ez alatt a Cudában megírt program, ami egy Ion-on fut (integrált videokártya, ha jól emlékszem: 16 számoló egységgel), 20* végez a két kancsós probléma kiszámításával (egy 5 és egy 3 literes kancsóba lehet vizet tölteni, 4 liternek kell lennie az 5 literesben, de nem lehet mérni a víz mennyiségét). Az ellenfél egy firepro v4800 volt, 400 stream processzorral.A cuda inicializálása: 0 ms.
  2. Futáskor fordul le a kernel, ami nagyon belassít. (Cuda esetében fordításkor történik egy előfordítás, ami miatt ugyan lassabb a fordítás, de a futás során nem lassít annyit).
  3. Szekvenciálisnak kell lennie a megírt program felépítésének. Ez alatt azt értem, hogy mindent kötött sorrendben lehet csak megírni. Pl. Cudánál videomemóriát inicializálás alatt, egy másik szálban is le lehet foglalni, függetlenül a kerneltől vagy az inicializálástól.
  4+. Kernel: vagy egy fájlból, vagy egy sztringből kerül betöltésre. A fájl használata nem a leggyorsabb, a sztring nagyon kényelmetlen. Arról már nem is írok, hogy a saját típus használata esetén, azt kétszer kell definiálni: egyszer a programomnak, egyszer a kernelnek. (Hopp! Mégis írtam róla. ) A mutató aritmetikát nem támogatja az OpenCl (azért ez nem akkora probléma, mert meg lehet oldani másképp). A double típus használata a programban veszélyes, mert csak a felső kategóriás videokártyák támogatják hardveresen (egy professzionális videokártya, nem biztos, hogy felső kategóriás: pl a v4800-as nem támogatja a double típust). Cuda esetében nem probléma, ha a hardver nem támogatja (pontosan nem tudom, hogy vagy simán átkonvertálja float típussá, vagy megpróbál kicsit trükközni, ami miatt nagyon belassul a program nem felső kategóriás videokártyákon, de legalább lefut és eredményt ad).
  5. OpenCl-t ma elsősorban csak az Amd videokártyák támogatása miatt használnak (később nyilván az Intelesek támogatása is szempont lehet). Amd: videomemória korlátolt feldolgozást tesz lehetővé a következő 1 évben mindenképpen, azzal, hogy elhatárolódik a PCI-E 3-tól. Nvidia: virtuális memória bevezetését tervezi (ehhez kell a PCI-E 3). Ha szükséges a sok memória, akkor Nvidia, ha Nvidia, akkor Cuda... (Ha kell még egyéb hiányosság: az Amd, stb által nem támogatott rekurziónál -amit az nvidia régóta támogat- érdemes szétnézni. )
  6. Milyen szép lenne az élet, ha lefordítom az OpenCl programot és az fut Nvidia és Amd kártyákon is. Na az élet nem ilyen szép... Ha Amd sdk-val fordítok, akkor nem fut az Ion-on (de az Ion-t látja), ha Nvidia sdk-val fordítok, akkor az még csak nem is látja az Firepro-t. De azért ha fordítom egyikkel is, másikkal is, külön-külön exe fájlt készítve, akkor az egyik futni fog Amd alatt, és a másik Nvidia alatt.
  7. De kell-e nekem az, hogy az Amd-s kártyán fusson, ha a programom sok memóriát használhat, meg jól jönne a rekurzió is, +a double típus használata. Tudom: most jön, hogy ilyen programok úgy sem lesznek egy darabig: igen nem lesznek, de csak ezért nem, mert az Amd elzárkózik. (Vagy csak nem mennek náluk olyan jól a fejlesztések?) Vagy mégis csak lesznek, de Nvidián fog mind futni Cudával?
  8. Remélem: elég informatív voltam. Ha valamiben tévednék, akkor megfelelő alátámasztással várom az indoklást. Örülnék neki, ha valaki tudna trükköket, amikkel ezeket a problémákat, hiányosságokat gyorsan és egyszerűen ki lehetne küszöbölni OpenCl alatt.

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