A HSA alapítvány egy újabb erős támogatóra tett szert, ugyanis az Oracle a jelenleg is zajló APU13 rendezvényen bejelentette, hogy egyetértenek a HSA jövőképével és támogatni szeretnék az úgynevezett hozzájáruló jogkör mellett. A vállalat célja a Java programnyelv fejlesztése kapcsán már egy ideje ismert, hiszen nagyjából egy évvel korábban fogtak össze az AMD-vel a Sumatra kódnevű projekt megszületéséért, mely a Java programoknak lehetővé teszi az integrált, vagy akár a dedikált grafikus vezérlők általános számítási kapacitásának kihasználását.
Nandini Ramani, a Java platform alelnöke az APU13-on tartott előadása során részletezte, hogy a Java az elmúlt évek során sok fejlesztést tett a párhuzamosítás irányába. Gyakorlatilag 2002 óta folyamatosan javul a programnyelv ebből a szempontból, de problémát jelentett, hogy nem fejlődött elég gyorsan, így az aktuálisnak tekinthető, de már több mint két éve megjelent Java 7-ben történt komoly előrelépés ebből a szempontból a fork/join keretrendszer bevetésével. Utóbbi a Java 5-ben megjelent java.util.concurrency Java 6-ban végrehajtott kiegészítéseivel együtt elég jó megoldásnak tekinthető, de a következő esztendő tavaszán érkező Java 8 a Lambda API-val még tovább lép, ami lambda-kifejezések támogatásával a végrehajtás párhuzamosításában vállal főszerepet. Az Oracle azonban egyre nagyobb figyelmet fordított a grafikus processzorok gyorsan növekvő erejére, és az ezekben rejlő általános számítási teljesítmény kihasználására komoly kutatások kezdődtek meg a cégen belül. Ez részben felelhet a régóta várt modularizálást célzó Project Jigsaw folyamatos késéséért, ugyanis a vállalat jó eséllyel fontosabbnak tartja heterogén jövőre való felkészülést.
[+]
Az Oracle elmondása szerint a Sumatra kódnevű projekt (azaz a készülő Java 9) kiindulópontja az AMD Aparapi projektje volt, melyről az alábbi hírben bővebben írtunk. Ez a rendszer lényegében egy adatpárhuzamos feldolgozásra tervezett API a Java 7-hez, a működés szempontjából pedig az OpenCL felületre épített a grafikus vezérlők kihasználásához vethető be. Az Oracle az alapötletet jónak tartotta, ugyanakkora az Aparapi a JVM-en (Java virtuális gép) kívül, magában a programban működik, ami elfogadható, de nem elegáns megoldás. A Java fejlesztéséért felelős cég ötlete annyiból állt, hogy célszerű lenne az Aparapi alapkoncepcióját a JVM-en belül megvalósítani, ami lényegében egyenlő a grafikus vezérlők natív támogatásával.
A Sumatra kódnevű projekt drámaian leegyszerűsíti a heterogén módon programozható processzorok kódolását. A Java 8 Lambda és Stream API-ja megmarad, de a JVM-en belül lesz egy JIT (Just-In-Time) fordító, ami HSAIL kódot generál, majd azt a HSA futtatási környezet és a HSAIL Finalizer megfelelő formában eljuttatja a hardverhez. A projekt célja alapvetően az volt, hogy a Java ne veszítse el azt, ami népszerűvé tette, vagyis az egyszerűségét, így a JVM dönt arról, hogy a munkafolyamatot a központi vagy a grafikus processzor kapja meg, méghozzá az adott feladat karakterisztikája szerint. Egyszerűbben fogalmazva a programozónak nem kötelező figyelnie arra, hogy melyik folyamatot futtassa a központi és melyiket a grafikus processzor.
Nandini Ramani előadásán ezt tesztelték is, így egy Kaveri APU-t beizzítva a Sumatra és a HSA futtatási környezet előzetesével egy program 5150 női és férfi nevet keresett Charles Dickens különböző könyveiben, majd erről valós időben egy kimutatást is készített. A munkával a négymagos processzorrész kicsivel kevesebb, mint 45 másodperc alatt végzett, de a GCN architektúrára épülő integrált grafikus vezérlőt is beizzítva (a hUMA és hQ architektúrával egyetemben) ugyanez a feladat alig tartott tovább 9 másodpercnél, a program pedig konkrétan ugyanazzal a kóddal futott. Ebből a gyorsulásból érthető, hogy az Oracle figyelme miért irányult a grafikus vezérlők általános számítási teljesítményének kihasználása felé.
[+]
A Sumatra kódnevű projekt azonban még fejlesztés alatt áll, így a Java 8 kap még egy extra kiegészítést az Aparapi szempontjából. Az új Java környezetben ugyanis a grafikus vezérlők erejének hasznosítását az OpenCL-től átveszi a HSA, így a programok jóval hatékonyabban futhatnak az ehhez fejlesztett APU-kon.
A készülő Sumatra környezet egyébként HSA-val kompatibilis grafikus vezérlőt igényel, a legjobb hatékonyság érdekében hUMA és hQ támogatással. Persze utóbbi kettő az AMD technológiája, de a többi HSA alapítványban résztvevő gyártónak is lesz saját implementációja ugyanezekre a funkciókra, és a szabványos specifikációknak hála ezek kompatibilisek is lesznek egymással csupán nem ez lesz a nevük.
