A köztes nyelvek jelentik a kulcsot
A köztes nyelvek szerencsére az idei évben sokat fejlődtek. Olyan ténylegesen értékelhető alternatívák tűntek fel a színen, amelyek programfordítás problémáját a végfelhasználói nézőpontból minimum megoldják. Azt meg kell jegyezni, hogy maga a fordítás nem egy egyszerű tényező. Nem lesz azonnal egy magas szintű kódból bináris kód. Az egész folyamat több lépcsőben zajlik, vagyis a magas szintű kódból csak több fázissal lehet eljutni a natív bináris kódig.
Az ipart is számos köztes nyelv tarkítja. Gyakorlatilag minden gyártó rendelkezik egy olyan IL (intermediate language) réteggel, amely áthidalja a fizikai utasításarchitektúrák közötti különbséget, hiszen ezek folyamatosan fejlődnek. Ezt a réteget a legtöbbször virtuális utasításarchitektúrának szokás hívni, és valójában amikor natív programfuttatásról beszélünk a GPGPU-k kapcsán, akkor azt a virtuális utasításarchitektúra értjük. Mindemellett bizonyos szinten az x86 is egy IL, csak éppen hardveres szinten implementálva, de ez csak egy érdekesség.
A köztes nyelvek tehát ma is abszolút elterjedtek, csak éppen nem olyan formában, ahogy ideális lenne, ugyanis a gyártók által kidolgozott virtuális utasításarchitektúrák egymással nem kompatibilisek. Emellett a programfordítás problémájának megoldására nem feltétlenül kell az absztrakció alacsonyabb szintjeit szabványosítani, így a magasabb szinteken is lehet kezdeni valamit.
Az idei év felvillantotta a megoldásokat két szinten is. A magas szintű absztrakció szempontjából elkészült a SPIR-V 1.0, amely a Vulkan API és az OpenCL 2.1 része. Bár a SPIR-V nem sokkal helyezkedik el alacsonyabb absztrakciós szinten, mint például az OpenCL C, arra pont elég, hogy a gyártók szempontjából az adott specifikáció értelmezésbeli problémáit áthidalja. Ilyen formában a SPIR-V egy biztonságos alapot kínál a programok szállítására, amelyek így garantáltan futni fognak a SPIR-V-t támogató implementációkon. Ráadásul a SPIR-V megnyit számos lehetőséget az ipar számára, mivel nem csak OpenCL C és GLSL kódokat fogadhat el, hanem opciós lehetőségként más nyelvekből is fordítható SPIR-V bájtkód. Ez a formátum már relatíve könnyen lefordítható a gyártók virtuális utasításarchitektúrájára, ahonnan egyenes út vezet a hardverhez is. Az is jó hír, hogy a SPIR-V-re mindenki épít majd implementációt, mivel alapvető feltétele a Vulkan API támogatásának.
A programfordítás problémájának másik megoldása a virtuális utasításarchitektúra szabványosítása, amely szintén megtörtént az idén a HSA 1.0 specifikációjának publikálásával. A HSAIL egy alacsony szintű köztes nyelvnek tekinthető, amely csak egy picit helyezkedik el magasabb absztrakciós szinten, mint a gyártók a saját virtuális utasításarchitektúrái. Ilyen formában is biztosítható a kompatibilitás, hiszen fordítható egy olyan bináris állomány, amely kvázi natívan fut a HSA-t támogató hardvereken. És itt a natív programfuttatást megint úgy kell értelmezni, hogy nem a fizikai utasításarchitektúrán fut a program, hanem előtte egy szoftveresen felhúzott rétegen.
Ez jobb optimalizálási lehetőségeket biztosít a programozók számára, viszont a gyártóknak is teljesen le kell követni az irányt, így a meglévő virtuális utasításarchitektúrák mellé fel kell venni a szabványos HSAIL-t is. Ezt az alábbi cégek biztosan megteszik majd: AMD, ARM, Broadcom, CEVA, DMP, GPT, Imagination, LG Electronics, Marvell, Mediatek, Qualcomm, Samsung, Sony, SWARM64, S3, Texas Instruments, Toshiba és VIA.
A HSAIL, vagyis a virtuális utasításarchitektúra szabványosítása a végfelhasználó oldaláról nem annyira izgalmas. A programfuttatás problémájára levetítve végeredményben ugyanazt biztosítja, mint a SPIR-V, vagyis garanciát ad a program működésére. Ugyanakkor a fejlesztők nézőpontjából valamivel kellemesebb a HSA, mert a kódgenerálást is szabványosítja, hiszen a HSAIL réteg feletti absztrakció minden gyártónak közös lesz. A SPIR-V esetében egy jókora, mondhatni kritikus területen elhelyezkedő absztrakciós réteg nem tekinthető közösnek, hiszen maga a köztes nyelv eleve magas szintű, ugyanakkor az nem valószínű, hogy ez a végfelhasználóknak bármilyen programfuttatásbeli hátrányt fog okozni, de a fejlesztőknek kellemetlen helyzeteket teremthet. Emiatt egyébként a Khronos Group és a HSA alapítvány lehetővé teszi, hogy a SPIR-V bájtkódból fordítható legyen HSAIL kód is.
A SPIR-V és a HSAIL két nagyon jó alapnak néz ki a következő évre, amelyekre 2016-ban meg is érkeznek a gyártói implementációk. Ezek egyébként nem konkurenciái egymásnak, tehát abszolút megférnek a piacon. Sőt, Vincent Hindriksen, a StreamComputing vezető programozója szerint még több köztes nyelv várható a jövőben. Ennek a legfőbb oka a problémamegoldás lesz, ugyanis még számos megoldatlan szoftveres gond van, és a köztes nyelvek tulajdonképpen segítenek megosztani a megoldáshoz szükséges kutatást az iparágon belül. A legtöbb még fejlesztés alatt álló köztes nyelv azonban gyártóspecifikus lesz, így szabványos szinten a SPIR-V és a HSAIL marad, mint eltérő alapokra épülő, de életképes megoldások a programfuttatás problémájára. Ezekre vagy éppen ezekről azonban sokféleképpen lehet majd fordítani, illetve konvertálni, vagyis a köztes nyelvek jól kiegészíthetik majd egymást.
Abu85
