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

• #84 Fiery veterán hugo chávez #73

  Új Válasz 2015-10-08 21:41:52 #84

  Ú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

  

  Fiery

  veterán

  válasz hugo chávez #73 üzenetére

  "Ha lenne egységes/közös architektúra, "hardveres" ISA, akkor éppenhogy nem is kéne a HSA/HSAIL-szerű közös virtuális (vagyis szoftveres) ISA-kkal szórakozni a legalább ezen a "magasabb" szinten történő egységesítés nevében és a HSA-koncepció is pont amiatt jött létre, mert nincs és nem is várható olyan egységes (és "jövőbiztos") architektúra, amit minden gyártó elfogadna, hajlandó lenne átállni rá, nem?"

  Persze hogy nem kene a HSA, ha nem lenne ennyifele architektura. A HSA egy ernyot kepez az architekturak fole, egy absztrakcios reteget, ilyen szempontbol tenyleg hasonlit a Javara vagy epp a JavaScriptre. De ahhoz, hogy ez mukodjon, hasonloan a JavaScripthez, mindenkinek tamogatnia kellene, es hasonloan a JavaScripthez, baromi jo es stabil compilerek kellenenek hozza. Egyik sem adott, es az alagut vegen nem latszik, hogy mikor jon el ez az ido. Ha pedig a "nagyok", azaz az iparag fejlodeset valoban formalo cegek megmakacsoljak magukat, akkor hasonloan a Flash es az OpenCL halalahoz, a HSA is ki lesz vegezve, me'g mielott a gyakorlatban be tudna mutatni, hogy mire is kepes.

  "Javíts(atok) ki, ha tévednék és azóta már változott a dolog, de úgy tudom, hogy konkrétan a HSA kifejezetten az APU-król szól"

  Elsosorban az APU-krol szol, de ugyanugy bevonjak a CPU-kat es a dGPU-kat is egy legacy retegen keresztul, mint ahogy az OpenCL is mukodik manapsag.

  "Arra ott van az OpenCL"

  Ertsuk mar meg vegre, hogy a HSA OpenCL nyelven is meghajthato A ketto nem 2 kulonallo ag. Az OpenCL viszont nem csak az OpenCL kernelek nyelvet, mukodeset meghatarozo nyelvet foglalja magaban, hanem a frameworkot, azaz az OpenCL kernelek leforditasat es vegrehajtasat menedzselo reteget is. Ez utobbi 2 eleg docogosen mukodo modulon probal a HSA javitani a sajat, fejlettebb megoldasaival. De maga a nyelv, amiben megirod a kernelt, amit aztan a HSA lefordit es vegrehajt a vason, lehet OpenCL is.

  "Tehát egy hipotetikus HSA bench is csak APU-kon menne, a dGPU-k irrelevánsak a HSA szempontjából."

  Nagyjabol igen, es ezert sem lenne relevans pl. az AIDA64 mostani OpenCL benchmarkjait atvinni HSA-ra. Egy APU+dGPU kombonal lenyegesen kedvezobb eredmenyt kapnal HSA nelkul, mint HSA-val, hiszen a dGPU-t a HSA-val nem vonnad be a benchmarkba, mig a "hagyomanyos" OpenCL benchmark azt is szepen megdolgoztatja.

  Ahol egyebkent a HSA egyertelmuen villantani tudna, es amire lehetne benchmarkot is irni kifejezetten, az valami olyan munkafolyamat lenne, aminel a CPU (azaz az x86 magok) es a GPU egy bonyolult adatstrukturan parhuzamosan (pontosabban felvaltva) dolgozna. Valamint, me'g egy nagysagrendet tudna gyorsitani a HSA, ha raadasul a GPU altal vegzett munkafolyamat relative gyorsan lefutna. Jelenleg, ha pl. OpenCL-lel akarsz olyan szamitast vegezni, ami nagyon hamar lefut a GPU-n, majd utana a CPU-val valamit matatsz az adatokon, es megint jon a GPU, es megint tul hamar vegez a GPU (es igy tovabb), akkor a rengeteg kernel inditas miatt, a gyenge labakon allo, nem optimalis queue modell miatt baromi lassan fog az egesz mukodni. Me'g akkor is lassu lesz, es alig gyorsul egy tisztan x86 kodhoz kepest, ha OpenCL 2.0-val, azaz megosztott memoriaval oldod meg. Az meg aztan plane horror, ha a memoriat is masolgatni kell, es a GPU tul gyorsan letudja a melot. A mostani OpenCL keretek kozt nagyon oda kell figyelni arra, hogy mikor es mennyi memoriat masolgatsz, es gondoskodni kell arrol, hogy a GPU-nak elegendo munkat tudj adni.

  [ Szerkesztve ]

• #90 #06658560 törölt tag hugo chávez #87

  Új Válasz 2015-10-09 11:11:23 #90

  Ú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

  

  #06658560

  törölt tag

  válasz hugo chávez #87 üzenetére

  A heterogén programozás problémája inkább a heterogén kódot igénylő feladatok létén múlik. Mi az a feladat, ami jobban fut hibrid környezetben, mint vagy csak CPU-n, vagy csak GPU-n futva? És itt a tényleges feladatot értem, nem a kifejezetten ilyenre kitenyésztett, de egyébként semmit nem csináló kódokat. Tehát pl. tömörítésnek jobb a vagy ez, vagy az állapotnál? CAd-nek, FEA-nak, kép-, videoszerkesztésnek? Valamilyen szimulációnak, titkosításnak? Ezen jobban múlik a siker.

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