A Microsoft a C++ AMP-ről az első Fusion Developer Summit rendezvényen beszélt, míg a felület specifikációi hat hónappal korábban mutatkoztak be. A rendszer a Visual Studio 2012-ben érhető el, melynek RC verziója már egy ideje letölthető, így a fejlesztők barátkozhatnak az új felülettel. A technikai oldaláról eleget lehet tudni, de a gyakorlat sokszor különbözik, így felkerestünk pár fejlesztőt, hogy véleményezzék a C++ AMP-t az eddig látottak alapján.
Alapvetően nagy az egyetértés arról, hogy a C++ AMP az ideális terep a kezdő programozók számára, ha csak most ismerkednek a GPU-k kódolásával, ráadásul a Visual Studio hasznos szolgálgatásai is működnek. Az OpenCL kódoknál számottevően rövidebb lehet a C++ AMP-s kód, ami főleg annak köszönhető, hogy a Microsoft bináris formátumot is definiál, így nem szükséges semmilyen fordításra vonatkozó kódrészlet. Ez azt jelenti, hogy a kliensek felé elég a bináris kódot biztosítani. Az OpenCL-nél ez nem ilyen egyszerű, ugyanis ez a felület nem definiál bináris formátumot, vagyis a programot még a futtatás előtt az adott hardverhez kell fordítani a telepített OpenCL driver fordítójával. Ez alapvetően nem lenne probléma, de minden gyártó külön fordítóval rendelkezik, így már a fordítás folyamán akadhatnak gondok, mert ha nem készül el a megfelelő kód, akkor nem lehet azt futtatni a hardveren. Ezért van az, hogy az új, OpenCL-t támogató programok egy része AMD által írt OpenCL drivert követel, mert csak így tudják garantálni a fejlesztők a megfelelő fordítást. A probléma természetesen áthidalható, de extra munkát igényel a fejlesztők és a hardverhez támogatást nyújtó gyártó részéről, így a C++ AMP ezen a ponton előnyös, hiszen a lefordított programkód biztos, hogy el fog indulni.
A hardver oldaláról DirectX 11-es API-t támogató grafikus vezérlő szükséges DirectCompute 5.0-t kezelő driverrel. Ebből kitalálható az is, hogy Windows 7, 8 és RT operációs rendszerre lesz támogatás, de mivel a C++ AMP specifikációja nyílt, így bármelyik operációs rendszerhez készíthető implementáció.
Szintén jól reagál a C++ AMP a Windows TDR funkciójára. OpenCL-nél ez gond, ugyanis előfordulhat, hogy egy kernel kiosztása esetenként sokáig tart, amire a TDR funkció úgy tekint, hogy az erőforrás nem válaszol az eseményre, és ezért a Windows újraindítja a hibát jelző felületet. Ilyenkor nagy esély van rá, hogy a program nem képes tovább futni. Ez a másik oka annak, hogy az egyes OpenCL-t támogató programok csak az AMD driverével futnak, mert ez a meghajtó jobban fel van készítve az előbb részletezett gondra. A C++ AMP azonban teljesen eliminálja a TDR funkció úgynevezett recovery módját. Maga a detektálás a kernel hosszú ideig tartó kiosztásával megtörténhet, de ezt az alkalmazás kezelheti kivételként, így az operációs rendszer tudatára adható, hogy az erőforrás idővel válaszolni fog, és ne állítsa le a hibát jelző felületet.
[+]
A C++ AMP mellett tehát sok indok szól, de komoly hátrány, hogy az aktuális profilozók jóval kevesebbet tudnak, mint az OpenCL-hez elérhető eszközök. Ez megnehezíti a program működésének profilozását, így nehezen lehet meglátni, hogy mely kódrészletek futnak túl sok ideig. Az optimalizálás szempontjából ez nagyon fontos lenne, hiszen manuálisan kutatni a problémás részek után nem a legkedveltebb időtöltés. A fejlesztők szerint a C++ AMP-n írt kódok 15-25%-kal futnak lassabban az OpenCL-en írt kódoknál, és ez főleg annak köszönhető, hogy nehéz manuálisan behatárolni az optimalizálásra szoruló kódrészleteket. Valószínű, hogy a jobb képességű profilozók érkezésével az OpenCL-ben írt kódok sebessége megközelíthető lesz C++ AMP-ben is.
A C++ AMP gondja még, hogy a kód lefordítása nagyon sok időt vesz igénybe. Ez talán még elfogadható kompromisszum, de egy kernel fordítása fél percbe is kerülhet, vagyis egy bonyolultabb programkódból nem lesz gyorsan bináris állomány.
Összességében a C++ AMP fogadtatása kedvezőnek mondható. Kétségtelen, hogy jelenleg a legnagyobb probléma a megfelelő profilozók hiánya, de biztos, hogy a C++ AMP-t támogató cégek dolgoznak ezen a problémán.
