Az Intel a Supercomputing 19 alkalmával leleplezte a jövőképét a HPC-piac tekintetében. Ebben már nem csak processzorok, hanem specifikus gyorsítók is szerepelnek, sőt alapvetően ezeknek adna nagy szerepet a cég, miután a CPU-k segítségével egyre nehezebben tudnak folyamatos teljesítménynövekedést elérni.

A Santa Clara-i óriáscég a CPU-k mellett egyre többet beszél az FPGA-król, a GPU-król, illetve a specifikus gyorsítókról, gondolva itt például az AI-ra tervezett dizájnokra. A koncepció ebben az, hogy az egyes feladatok azokon a hardvereken fussanak, amelyeken a legjobb a sebesség, illetve a hatékonyság. Nem először halljuk már ezt a piacon, párszor megfogalmazódott ugyanez a gondolat, és van benne ráció, hiszen bizony vannak olyan komplex munkafolyamatok, amelyek a CPU-n működnek optimálisan, de bizonyos részfeladatokat érdemes gyorsítókra bízni, például GPU-kra. Az Intel ott lépett egy picit tovább a korábbi heterogén kódfuttatás hardveres felosztása tekintetében, hogy a hagyományosan emlegetett CPU-k és GPU-k mellé bevették még az FPGA-kat, illetve az egyedi gyorsítókat, hiszen vannak olyan kódok, amelyek ezeken futnak a legjobban. A legegyszerűbb példa itt a gépi tanulás, hiszen ott a feldolgozás nagyjából 95%-a mátrixszorzás, és bár ezt a CPU és a GPU is megoldja, a specifikusan erre tervezett gyorsítók sokkal hatékonyabbak.

Az Intel koncepciójában itt jön képbe a OneAPI, ami tulajdonképpen egy olyan platform, amivel a kódot egyszer kell megírni, és az végül bármilyen hardveren futtatható, legyen szó CPU-ről, GPU-ról, FPGA-ról, vagy specifikus dizájnt használó gyorsítóról, de leginkább ezek kombinálása lehet kifejezetten érdekes, amivel a rendszerben található, különbözően megtervezett hardverelemek egységesen használhatók ki. Az olvasóink számára ez sem lehet igazán ismeretlen, hiszen a HSA alapítványon belül több cég pont ugyanezt a koncepciót dolgozta ki, ott is a különböző hardverek egységes kóddal való kezelése volt a lényeg. Van azonban egy nagyon nagy különbség a OneAPI és a HSA koncepciója között, még akkor is, ha a cél pontosan ugyanaz. A HSA ezt úgy érte el, hogy a gyártók egyes implementáció megfeleltek egy szabványosított, HSAIL nevű, alacsony szintű köztes nyelvnek, így az ezekre lefordított kódot, mindegyik HSA direktívákat támogató implementáció tudta futtatni. Ennek egy hátránya van, az operációs rendszereket esetenként jelentősen módosítani kellett, hogy működjön.

[+]

A OneAPI nem vállal be olyan reformokat, amellyel megpróbálja megoldani az IT-piac nagy problémáit, sokkal inkább arra törekszik, hogy ezekkel a gondokkal könnyebb legyen együtt élni. Emiatt az Intel nem csinált mást, mint összerakott számos függvénykönyvtárat, amelyekkel a hardverfüggetlen API hívásokat le tudják fordítani a támogatott hardverek specifikus, alacsony szintű kódjára. Ha a teljesítmény kritikus tényező, akkor még egy Data Parallel C++ nevű nyelvvariáns is van, amivel alacsony szintű optimalizálások is lehetségesek. Ez az opció a SYCL kiegészítésére épül. Utóbbi a Khronos Group fejlesztése, és egy platformtól független absztrakciós rétegről van szó, amely az OpenCL hatékonyságát a C++ flexibilitásával ötvözi, így a SYCL egyetlen C++ forrásból történő programfejlesztést valósít meg az OpenCL-re építve.

A OneAPI aktuális verziója persze még nem tart ott, amire valójában ezt tervezik, vagyis most még relatíve sok, hardverspecifikus optimalizálásra van szükség, de a végleges verzióra már az a cél, hogy a programfejlesztő azon kívül ne definiáljon semmit, hogy a kódot milyen típusú hardveren szeretné futtatni. Minden, ami ennél továbbmegy csak hátrányos tényező a fejlesztőknek, és el kell rejteni előlük.

Az Intel a OneAPI-t természetesen a saját hardveri miatt fejleszti, és utóbbiak is fejlődnek majd. A vállalat a szerverpiacot tekintve a Sapphire Rapids kódnevű CPU-ra koncentrál már, amelyről viszonylag sokat lehet már tudni. Bejelentették azonban a másik kritikus komponenst, amely egyelőre Ponte Vecchio kódnéven fut. Ez egy specifikusan a HPC-piacra szánt GPU, ráadásul az Intel első ilyen jellegű fejlesztése. A vállalat olyan nagyon sok részletet nem árult el, de a működés tekintetében elmondták, hogy a dizájnt úgy tervezték, hogy támogassa a variálható vektorhosszt, valamint a SIMT és SIMD formájú párhuzamosítást.

A SIMT és a SIMD koncepció egyszerre történű támogatás furcsa lehet, de valójában nem újdonság, az Intel aktuális GPU-architektúrái is így működnek, alapvetően a shader lépcsőnek megfelelően döntenek arról, hogy melyik módban futtatják a programot. Ami ok, amiért ezt a megoldást nem látjuk sűrűbben az az, hogy a SIMT és a SIMD feldolgozás eltérő hardveres felépítést igényel. Előbbinél fontos, hogy legyen elég konkurens szál a memóriaelérés időigényének átlapolására, míg utóbbinál lényegesebb, hogy jól legyen felépítve a hardver a függőségből eredő gond hatékony kezelésére. Na most a probléma az, hogy mindkettő tényező megoldása tranzisztorigényes, ezért van az, hogy vagy az egyik, vagy a másik irányt választja egy cég. A hátrányok pontosan látszanak az Intel aktuális GPU-in is, amelyek nagyon kevés konkurens szála kezelnek, inkább mindegyikhez külön regisztert rendelnek, hogy az úgynevezett regiszternyomás ne legyen nagyon káros a sebességre, ezért viszont olyan sok tranzisztorral fizetnek, hogy arányaiban csak kevés feldolgozót tudnak a hardverbe építeni.

A nagy kérdés, hogy a SIMT és a SIMD koncepció egyszerre történű kezelése csak egy örökölt képesség az aktuális dizájnokból, vagy az Intel megtalálta azt a megoldást, hogy mindkét működési módban hatékony legyen a hardver, miközben arányaiban nem is pazarolják a tranzisztorokat sem. Ez valószínűleg csak később derül ki, amikor majd több adatot hoznak nyilvánosságra a Ponte Vecchio GPU-ról.

[+]

Annyi viszont már biztos, hogy a rendszer nagyon skálázható, ezernél is több feldolgozóegység építhető bele, bár azt az Intel még nem taglalta, hogy ezekben a részegységekben mi található, így különösebb következtetést se lehet ebből levonni. Az új adatpárhuzamos Matrix Engine feldolgozóról azonban beszámoltak, amely támogatja az INT8, bfloat16 és az FP16 adattípusokat, továbbá nagyon sokat javul majd a dupla pontosság melletti teljesítmény.

A skálázhatóság szempontjából az Intel CXL (Compute Express Link) interfésszel kötné össze a GPU-kat, illetve ezekkel a host processzorokat, míg az egyes GPU-khoz egy úgynevezett Rambo cache-en keresztül kapcsolódnának a HBM memóriák. Utóbbiak az EMIB, míg előbbiek a Foveros tokozási technológiával lennének a rendszer elemei. A Rambo cache tényleg nagyon érdekes, mivel ez rendkívül hasznos eleme lehet a több GPU-s rendszereknek, ugyanis megpróbálja a skálázási limiteket kiütni egy igen méretes gyorsítótár közbeiktatásával, vagyis a több GPU által elérhető gyorsulás a munkafolyamattól függetlenül közel lineáris maradhat.

[+]

Az X^e sorozatú, Ponte Vecchio kódnevű GPU 7 nm-es node-on érkezik, várhatóan 2021-ben, és gyakorlatilag ez lesz a 10 nm-es Sapphire Rapids társa az Aurora nevű rendszerben, amely a második leggyorsabb szuperszámítógépnek készül az 1 EFLOPS-os becsült teljesítményével.