Melyik irányt válasszuk?
A 2015-ös esztendő egyik nagy áttörése a köztes nyelvek területén következett be. Manapság elég komoly problémákkal szembesül a piac, amikor nagyobb teljesítményt akarnak kicsikarni az elérhető hardverekből. Két lehetőség a teljesítmény növelésére a párhuzamosítás és a vektormotorok szélesítése. Mindkettő reális tényező, de nehezebben kihasználhatóak, mint a megszokott dolgok, ezt azonban nem csak a hardverek működése, hanem a szoftveres komponensek is nehezítik.
Meglepő, de a problémát hardveres oldalról a legkönnyebb megközelíteni. A párhuzamosítás egyik kulcsa a több mag beépítése (most abba ne menjünk bele, hogy mi a mag definíciója, mert az csak bonyolítaná a helyzet megértését), de a SIMD tömbök szempontjából már két reális út is van. Egyrészt megoldható az, hogy legyen egy fixen specifikált utasításkészlet rájuk, amely sosem változik meg, és ezt lehet majd folyamatosan kiegészíteni. Ennek előnye, hogy a programokat érdemes lesz natívan lefordítani erre az utasításkészletre, és így a program mindaddig fut, amíg az adott utasításkészletet támogatja a hardver. Másrészt sokkal kézenfekvőbb az utasításkészletet nem kőbe vésni, így biztosítható a hardver hatékony fejlődés. Ez azzal az előnnyel is jár, hogy a skálázódást nem fogja akadályozni az adott utasításarchitektúra idővel elavuló memóriamodellje, ami a programozó számára is könnyebbé teheti a munkát, mivel nem kell a hardver gyengeségeire szoftveres megoldást találnia.
Az előnyöket figyelembe véve a piacon mindkét irányra vannak példák. Fixen specifikált utasításkészletnek tekinthető többek között az AVX, amelynek idén megérkezett harmadik generációs verziója AVX-512F néven. Ennek azonban ma már láthatóan sok hátránya van. Itt jegyezzük meg, hogy innentől kezdve specifikus dolgokról lesz szó, így nem szabad majd általánosítani. Az látható, hogy az AVX és az AVX2 támogatott a mai PC-s Intel és AMD processzorok jó részében, de felhasználói alkalmazások nem igazán érkeznek rá, miközben a számítások mennyisége növekszik, és viszonylag jól hasznosíthatók lennének ezek a SIMD tömbök. Maxime Chevalier-Boisvert, a Montreáli Egyetem fordítóprogramokban jártas szakértője szerint a SIMD utasításkészletek nagyon rosszul vannak implementálva az x86-os utasításarchitektúrába, ugyanis megkövetelik a programozótól, hogy foglalkozzanak a többszálúsítás és az előbetöltés problémájával, illetve megküzdjenek a rendkívül kevés SIMD regiszterrel. Mindemellett az új kiterjesztések új regiszterméreteket is hozzáadhatnak az utasításkészlethez, amelyek kihasználásához át kell írni az eredeti kódot. Összességében ez az irány a legnehezebb és a legköltségesebb a programozók számára, és főleg ez az oka, amiért az AVX-512F már nem is aktív a Skylake-ben, annak ellenére, hogy a megjelent hardverek elvben támogatják.
Hasonlóan vélekedik erről az ARM is. Ugyan SIMD utasításkészletre szükség van a processzormagokon belül, de bizonyos korábban meghozott döntések miatt annyira korlátozottá váltak a lehetőségek, hogy nem éri meg egy bizonyos szintnél szélesebb SIMD tömböket használni, mert a programozó nézőpontjából a kihasználásuk vállalhatatlanul nehézzé válik.
Merre kellene menni? [+]
Alternatív oldalról megközelítve a dolgokat szintén vannak problémák. Az tisztán látható, hogy manapság a rendszerchipek korát éljük, és ezekben a lapkákban a processzormagok mellett egy vagy több koprocesszor található (GPU, illetve DSP). Leegyszerűsítve a lehetőségeket, integrált grafikus vezérlő a legtöbb lapkában biztosan van, mert valaminek meg kell jelenítenie a képet. Itt jön elő a másik irány, mint a nem kőbe vésett utasításkészlet, és ezzel a skálázhatóság dizájnba tervezése. A hátrányokat ennél az okozza, hogy ami biztosítja a működést és a hatékonyságot, az nem teszi lehetővé a szó szerint értendő natív programfordítást. Persze szállítható bináris kód ezekre a hardverekre is, de amint jön egy új hardver, a kompatibilitás azonnal elvész.
A programozó nézőpontjából mindenképpen előny, hogy a GPGPU-kban van bőségesen regiszter, a szálakat a hardver kezeli, illetve az előbetöltés problémája sem létezik, mivel ha egy szál számára még nem elérhető az adat, akkor van még sok másik szál, ami futhat. Tehát minden olyan dolog, amely a például az AVX esetében probléma, az itt nem gond. Viszont ha nincs natív programfordítás, legalábbis nem ajánlott alkalmazni, akkor a fordítást az adott gépen kell megoldani. Ez az a pont, ahol az aktuális nyelvek és platformok nem remekelnek, mivel például a programfuttatás ki van téve a fordítók fejlődésének, amelybe hibák is kerülhetnek. Egy magas szintű, például OpenCL C kódot azért nem ideális szállítani, mert előfordulhat, hogy egy új meghajtóprogram nem fordítja le jól, így a program futtathatatlanná válik. Nem beszélve arról, hogy például az OpenCL C specifikációt figyelembe véve voltak a gyártók között értelmezési eltérések; teljesen mindegy, hogy a specifikáció mennyire volt egyértelmű, az értelmezési eltérés már ahhoz vezet, hogy az elvileg szabványos kódot nem fordítja le mindegyik gyártó fordítója.
A cikk még nem ért véget, kérlek, lapozz!
