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

• #66 Abu85 HÁZIGAZDA petkow #55

  Új Válasz 2012-06-29 12:45:30 #66

  Ú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 petkow #55 üzenetére

  Nincs más választás. Vagy tartod az irányt, vagy sosem lesz gyorsabb a programod az új hardverek érkezésével sem. Ugyanaz a helyzet, mint az egymagos->többmagos váltásnál. Ott is szívták a fogukat a fejlesztők, de rákényszerültek, mert a chipek skálázódása nagy úr. A programozó szempontjából a programozási modellek átalakulása kellemetlen dolog, de áthidalható probléma, a lapkák tervezésénél viszont a fizika törvényei kőbe vésett jelenségek, és megkerülhetetlenek. Legalábbis eddig még nem volt rá példa, hogy a fizikát sikerült legyőzni. Lehet elmélkedni transzdimenzionális fejlesztésekben, hogy mondjuk egy adott térre más fizikai törvények legyenek jellemzők, de ezek elméletben is csak kitalációk, semmilyen gyakorlati bizonyíték nem létezik rájuk. Hamarabb váltjuk le a CMOS-t, minthogy legyőzzük a fizika korlátjait. Természetes, hogy a programozó szempontjából az 50 GHz-es egymagos processzor jelenti az űberhardvert, de ez a jelenlegi technológiai szintünkön kivitelezhetetlen, a teljesítmény skálázását viszont mindenki elvárja. Következtetés az, hogy keresni kell azt az utat, amivel skálázni lehet a lapkákat.
  Mindenki próbál párhuzamosítani. Az Adobe már APU-ban gondolkodik például, mert nem engedhetik meg maguknak, hogy a szoftverük teljesítménye megrekedjen egy szinten. A vezető szoftvermérnökük már elmondta ebben a hónapban az AFDS előadáson, hogy a jövőben a HSA-ra építenek, és szívesen venné, mindegyik cég beállna a támogatók sorába, mert megkönnyíteni a programozók dolgát.
  A játékok helyzete a legkönnyebb. Ugye egy programnál az APU kihasználása attól függ, hogy mennyi párhuzamosítható részlet van a feldolgozás során. Na most a játékok ebben igazán bővelkednek. A fizika, az útkeresés, a különböző culling eljárások, a sorting, a tartalom kikódolás ... mind-mind nagyon jól átrakhatók GPU-ra. Amiért ma ez nem történt még meg az az, hogy a GPU egy lassú külső buszon kapcsolódik a processzorhoz, és mindkét erőforrás különálló memóriát használ, emellett a DirectX is egy elég nagy késleltetéssel rendelkező API. A GPU pusztán a számítások oldalán így is gyorsabb, de annyi büntetést kap az adatok másolgatásával és az API késleltetésével, hogy összességében gyorsabb a processzor által való feldolgozás. Az APU-val lehetőség lesz teljesen koherens memóriát megosztani a CPU és az IGP között, azaz nem kell másolgatni az adatokat. Az API limitációira pedig megoldás például a HSA, vagy más hasonló irányú felület.
  A programozás szempontjából pedig HSA BOLT-ot használva rövidebb programkód írható, mint soros programozás mellett egy magot használva. A különbség, hogy HSA-val párhuzamos lesz a feldolgozás, és majdnem olyan lesz a sebesség, mintha OpenCL-be írtál volna egy 6x hosszabb kódot. Ezért buzdít az Adobe a belépésre, mert a programozóknak a befektetett munka nagymértékben redukálódik, és még a hardverek közötti különbség is elfedésre kerül, hiszen a HSAIL egy virtuális ISA, vagyis az alatta lévő fizikai hardver támogatása a finalizertől függ. Ha van x számú fizikai hardverre HSA támogatás, akkor ugyanaz a kód bármelyik hardveren fut függetlenül a gyártótól. Persze specifikus optimalizálásra szükség lesz, de aki eddig látta a HSA-t működni, az azt mondja, hogy a befektetett munka így is nagyon kevés, ahhoz képest, amit az OpenCL specifikus optimalizálásába kell beleölni.

  (#63) Kopi31415: Lesz is olyan kód, de rengeteg olyan kód van, ami nagyon jól párhuzamosítható.
  Bármit hozol a PCI Express helyett, akkor sem lesz gyorsabb a lapkába integrált kommunikációnál, és sosem fog két külön lapka teljesen koherens memóriát megosztani. A gyártók is látják ezt, és elképesztő ütemben integrálnak, mert nem tudnak más megoldást a problémákra. Ha lenne szerintem nem ezt az utat választanák.

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