2. Fórumok
  3. Videokártyák
  4. Adatok az Intel Xeon Phi teljesítményéről
Keresés

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

  • #33 con_di_B tag petXYZW #32
    Új Válasz #33
    Ú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

    con_di_B

    tag

    válasz petXYZW #32 üzenetére

    A "Tree search" egy teljesen szintetikus teszt (értsd, nem az a lényeg, hogy mit old meg, hanem az, hogy mit terhel) ami kifejezetten arra készült, hogy extrém divergens kódvégrehajtást eredményezzen. Elméletben ez persze nem fair a masszívan SIMD hardverekkel szemben, de a gyakorlat azt mutatja, hogy ezek között is lényegi különbség van a divergencia kezelése terén, amit érdemes mérni.

    A "bemegyünk a gráfba és jól eltévedünk" jellegű problémáknál ezen kívül az is szempont, hogy ennél a fajta divergenciánál nem csupán a vezérlés nehéz, hanem a memória-elérés mintája is a lehető legrosszabb.

    Éppen ezért ebben a tesztben azok a hardverek tudnak jó eredményt elérni, amelyek 1) nem annyira érzékenyek a divergens vezérlésre 2) jól kezelik (gyorsítótárazzák) a legordasabb memória-eléréseket is.

    Ezeket a problémákat hagyományosan nem szeretik GPU-ra átültetni, de az OpenCL messze nem csak a GPU-król szól.

    Folyamatpárhuzamosságról ebben az esetben nincs szó.

  • #30 Abu85 HÁZIGAZDA petXYZW #21
    Új Válasz #30
    Ú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 petXYZW #21 üzenetére

    Nagyon jó flow control hardver kell hozzá. Ezzel jól kezelhető a branch-divergency.

    Közben kiderült a Xeon Phi-ről, hogy nem is olyan megosztott az az L2 cache. Konkrétan minden maghoz saját tartozik, és a másik maghoz tartozó L2 tárat se írni se olvasni nem tudják. Az Intel ezt nem pont így ígérte, de mindegy. Ez is ad némi magyarázatot az eredményekre.

  • #26 Meteorhead aktív tag petXYZW #22
    Új Válasz #26
    Ú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

    Meteorhead

    aktív tag

    válasz petXYZW #22 üzenetére

    A programozóknak az OpenCL-lel nem az a bajok, hogy programozni kell benne (bár igen, sajnos létezik az a 70%-os programozói réteg, aki egy mezei host oldali párhuzamos kóddal sem bánik el, sem task, sem data parallel esetben), hanem az a baja, hogy isszonyatosan verbose és macera az interface-e.

    Egy olyan egyszerű problémát megoldani, hogy egy GPU képes-e double-ben számolni, vagy csak floatot lehet használni kernelben olyan trágya módon lehet megoldani, hogy az ember csinál egy #define REAL float/double sort a kernel kódba, amit runtime kell a kódba beleírni, mert akkor derül ki, hogy az adott hardver amin fut képes-e rá. Igen, C++-an léteznek template-k. Ilyenekre találták ki őket. (Igen, AMD-nek van már static C++ OpenCL compilere, de az a kód nem lesz hordozható)

    OpenCL-ben nincs dinamikus memóriaallokáció (ami állatira megnehezíti a legegyszerűbb hatékony reduction kódok írását, mert egy csomó méretet host oldalról kell beleinjektálni a kódba, hogy compile-time konstans legyen.

    Tisztában vagyok vele, hogy a rengeteg feature amit korábban felsoroltam az egy magasabb szintű absztarkciót szolgál, de el nem tudom mondani, hogy mennyivel egyszerűbb lenne az életem, ha STL tárolókat használhatnék egészen az utolsó függvényig, ami feldogolgozza az adatokat, és nem kéne közbeékelnem egy cl::Buffert, és a köré épített egész masinériát. Fejlesztési idő ÓRIÁSI mértékben lerövidülne.

    Egyébként értem amit mondasz, hogy van egy fajta programozói lustaság, (bár nekem azért van munkám, mert kevesen értenek ehhez) de tényleg macera. Olyan programot írni, ami minden user gépén fut állati macera írni, és OpenCL C99 kernel nyelve ehhez csak hozzárak. Csak a template-ek már megváltásként hatnának.

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