A jelenleg is zajló Red Hat Summit alkalmával az AMD és a Fedora közösen demonstrálta az év közepén érkező Berlin APU képességeit. A második generációs X sorozatú Opteron az első olyan szerverekbe szánt megoldás lesz, ami támogatja a HSA platformot, amit a Fedora érkező Linux disztribúciója ki is használ. Ennek jelenleg már fut az előzetes verziója, amelyen természetesen lehet OpenCL és OpenGL alkalmazásokat is futtatni, és erre időt is szakított a két cég, de az igazán érdekes területe a koncepciónak a Java és a HSA baráti viszonya. Az Oracle már az elmúlt év novemberében bejelentette, hogy belép a HSA alapítványba, és az érkező Java 9-et úgy tervezik, hogy natívan képes legyen HSAIL kódot fordítani. Ennek értelmében a fejlesztőnek nincs igazából dolga az integrált grafikus vezérlő kihasználását illetően, a megszokott programozási modellen belül a Java 9 JDK Stream és Lambda API-ját használva kell dolgozni, és ugyanaz a kód fut CPU-n, illetve a HSA-n keresztül az erre felkészített APU-kon is az IGP erejét kihasználva.
A Fedora a koncepcióban nagyon nagy potenciált lát, mivel eltűnik a határvonal a CPU és a GPU között. A fejlesztő már nem látja különálló egységekként ezeket, és nem is kísérli meg a speciális algoritmus használatát az IGP-re, csupán a Javában megszokott programozási környezetben megkapja az IGP-s gyorsítás előnyét, amennyiben a HSA elérhető. Ha utóbbi feltétel nem teljesül, akkor ugyanaz a kód a CPU-n fut le mindenféle sebességvesztés nélkül.
A Fedora és az AMD demonstrációja még a márciusban megjelent Java 8 nyelvet bevetve futott az új HSA-s Aparapi API-val. Utóbbi kiegészíti a Java 8-ban bemutatkozó Lambda API-t, ami a lambda-kifejezések támogatásával a végrehajtás párhuzamosításában vállal főszerepet. A HSA-s Aparapi lényegében annyit tesz, hogy a kijelölt, párhuzamosítható algoritmusok bájtkódját HSAIL kódra konvertálja, ahonnan már egyenes út vezet az IGP-hez. Bár a korábbi Aparapi verzióhoz képest a működésben lényegében csak az a különbség, hogy a rendszer a bájtkódot nem OpenCL-re, hanem HSAIL-re konvertálja, ami nem tűnik sok változásnak, valójában viszont komoly jelentősége van. Utóbbi ugyanis megengedi, hogy a programozó ismerős környezetben kódoljon. Erre jó példa az alábbi két egyszerű kód, amelyek ugyanazt a munkát végzik, de eltérő Aparapi verzióval.
OpenCL-es Aparapi és HSA-s Aparapi
Az új HSA-s Aparapi tehát elsősorban kényelmi szempontokat kínál, azon kívül persze, hogy extra sebességet tesz lehetővé. Mindemellett az AMD ügyelt arra, hogy a rendszer nagyon idomuljon a jövőre érkező Java 9-hez, ami már natív HSAIL kódfordítást tesz lehetővé. Ennek értelmében a Java 8-ban Aparapi kiterjesztéssel megírt Lambda API-t használó kódok módosítás nélkül futnak majd Java 9 alatt.
[+]
A működés egyébként a Java 9 és a HSA-s Aparapival kiegészített Java 8 alatt is ugyanolyan. A rendszer először ellenőrzi, hogy az adott lambda-kifejezésnek ez lesz-e az első futtatása. Ha nem, akkor ellenőrzi, hogy van-e már rá generált HSAIL kód. Ha van, akkor futtatja a HSA platformon, de ha nincs, akkor a CPU-n fut. Amennyiben az adott lambda-kifejezés először fut, akkor a rendszer ellenőrzi, hogy elérhető-e a HSA. Ha nem, akkor a kód a CPU-n fut, ha igen, akkor ellenőrzi, hogy a bájtkódból generálható-e HSAIL kód. Amennyiben igen, akkor a HSA platformon fut, míg ha nem, visszakerül a futtatás lehetősége a CPU-hoz.
[+]
A HSA-val elérhető gyorsulás mértéke az algoritmustól függ. A Fedora és az AMD szerint a Berlin APU-val a jellemzően használt algoritmusokban 3-7-szeres extra sebességre lehet szert tenni a HSA-val, míg az extrém módon párhuzamosítható algoritmusok esetében a gyorsulás akár meghaladhatja 10-szeres szintet is. Eközben a fogyasztás jellemzően csak 10-40%-kal emelkedik. A Red Hat Summit rendezvényen ezt ki is lehetett próbálni pár előre megírt Java 8 program futtatásával.
A Java 9 működése még a fentieknél is hatékonyabb lesz, és érdemes hangsúlyozni, hogy a ma megírt kódok módosítására nem lesz szükség. Szintén fontos részlet, hogy a HSA-s Aparapi kiterjesztéssel megírt Lambda API-t használó kódok sosem futnak lassabban CPU-n, mintha a fejlesztő nem használná az új Aparapi API-t. Tekintve az Oracle által felvázolt fejlesztési irányt, az érintettek mindenképp ennek használatát javasolja, így a most megírt kódokat nem szükséges a következő évben módosítani a Java 9 újításainak kihasználáshoz.
