GPGPU programozás oktatása

Átírás

1 GPGPU programozás oktatása Szénási Sándor Összefoglalás A grafikus kártyák hagyományosan a képernyő tartalmának megjelenítéséért feleltek, ez azonban az évek folyamán lassan megváltozott. Ennek első látványos lépése a 90-es években megjelenő 3D gyorsítókártyák megjelenése (majd integrálása) volt. A későbbiekben a különféle új funkciók beépítését követően ezek a kártyák egyre sokrétűbben használható eszközök lettek, míg néhány évvel ezelőtt (jelentős részben az Nvidia CUDA környezetének kiadásának köszönhetően) elérkezett az idő, hogy általános célú végrehajtóegységeknek tekinthessük őket. Míg a hagyományos CPU-knál is a többmagos architektúrák fejlesztése lett a fő irány, addig a grafikus kártyák esetében is egyre nagyobb mennyiségű végrehajtóegységgel találkozhatunk, bár itt egészen más mértékekről beszélhetünk, napjaink csúcskártyáiban a végrehajtóegységek száma már meghaladja az ezret. A grafikus kártyák programozás azonban jelentősen eltér a hagyományos többmagos CPU-knál megszokottól, mivel itt alapvetően adatpárhuzamos kódok futtatására van csak lehetőség. Előadásomban ezt a környezetet szeretném bemutatni, illetve az oktatásához megvalósított tananyagot. Kulcsszavak: CUDA, GPGPU, grafikus kártya, adatpárhuzamos algoritmusok, párhuzamos programozás, programozás oktatás, I23 Abstract Teaching GPGPU programming Traditionally video display adapters were responsible for the representation of content in the screen, however this slowly altered during the last twenty years. The first spectacular step of this was the appearance (and later the integration) of the 3D accelerator cards in the 90s. Later in the aftermath of integration of several new functions, these cards become more and more comprehensive devices, and in the last few years (mainly due to the release of the Nvidia CUDA environment) the hour came to rate these set of tools as general-purpose processing units. While the main direction of the traditional CPU development is increasing the number of cores, in case of the video display adapters we 1

2 can see more and more processing units too. However in this case we can talk about quite different dimensions, the number of processing units is more than one thousand in the top-level graphics cards. Programming video display adapters is however remarkably different to the programming of multi-core CPUs, because the only opportunity to utilize the processing power of the GPU is the development of data-parallel algorithms. In my presentation I would like to present this environment and the already existing course notes. Keywords: CUDA, GPGPU, graphics card, data-parallel algorithms, parallel programming, teaching programming, I23 Bevezetés Egyre gyakrabban, egyre több fejlesztés során merül fel a GPGPU betűszó. A grafikus kártyák programozása napjainkban már egyértelműen megérett a gyakorlati alkalmazásra, a legnagyobb ipari szereplők (bankok, elemző cégek) hirdetik, hogy számításaik jelentős részét ezekkel a nagy csúcsteljesítménnyel rendelkező eszközökkel végzik el. Szinte egy teljesen új terület kifejlődésének lehettünk tanúi az utóbbi néhány évben. Alig 20 éve a grafikus kártyák egyetlen szerepe a számítógép memóriájában található kép analóg jellé való alakítása volt, amit a hozzá csatlakoztatott monitor meg tudott jeleníteni. A fejlődés sokáig pusztán a felbontás, színmélység, sebesség változását jelentette, a mérföldkő az első 3D gyorsítók megjelenése, majd ezek grafikus kártyára való integrálása lett. Mivel a monitorok fejlődése nem volt elég gyors, így a képminőség szempontjából a grafikus kártyákat sem volt érdemes továbbfejleszteni, a különféle 3D gyorsítási funkciók azonban új lendületet adtak ennek az iparágnak. Mind az ipari felhasználók (tervezés, animációk készítése), de méginkább a játékipar (különféle, 3D megjelenítést alkalmazó játékok megjelenése és elterjedése) hozzájárult ahhoz, hogy egyre nagyobb teljesítményre volt szükség, és a felbontással ellentétben a 3D teljesítmény növelésének lehetősége szinte határtalannak tűnt. A kártyák kezdetben elkülönült, dedikált eszközöket tartalmaztak a különféle feladatok végrehajtására (pixel shader, vertex shader, geometry shader), ezek megfelelő aránya azonban meglehetősen sok kérdést vetett fel, hiszen egészen más arányban van rájuk szükség pl. egy tájkép 2

3 kirajzolásakor (összetett geometria, viszont egyszerű textúra) mint pl. egy tervező program esetében (egyszerűbb geometria, viszont nagyon kifinomult árnyékolás). A megoldást az jelentette, hogy az egyes egymást követő generációkban egyre inkább hasonlítani kezdtek a különféle shaderek, míg néhány éve megjelent a unified shader model, amely egy olyan architektúrát jelez, ahol a grafikus kártya nagyszámú, általános célú végrehajtóegységet tartalmaz, amelyek el tudják végezni az összes, 3D modellezés során elvégzendő feladatot. Mivel ezek a végrehajtóegységek valóban szabadon programozhatók lettek, azonnal felmerült a lehetőség, hogy használjuk ezeket a grafikus megjelenítésen túlmenően egyéb számításigényes feladatokhoz (mivel ekkorra a grafikus kártyák csúcsteljesítménye már messze meghaladta a hagyományos CPU-két). Erre a gyártók azonnal válaszoltak is, és kiadtak különféle fejlesztői környezeteket, amelyek ezt lehetővé tették. GPGPU oktatás napjainkban A felsőoktatás nagyon gyorsan tudta követni ezeket a változásokat. Az első, hivatalosan is támogatott, és a fejlesztők számára jól használható fejlesztői környezet, a CUDA júniusában jelent meg, és szinte azonnal megjelentek a különféle ehhez kapcsolódó kutatások, tárgyak, központok. Elsőként 2008-ban az Illinoisi Egyetemen (Maiellaro, 2008), de nagyon gyorsan megjelentek hazánkban is az ezzel foglalkozó központok, az Óbudai Egyetemen már 2008-ban indult ezzel kapcsolatos kutatás, illetve 2009-ben már elindult a Masszívan Párhuzamos Programozás nevű tárgy. GPGPU oktatás során mindenképpen hangsúlyt kell fektetni a hardver környezet megismerésére. Ez természetesen minden eszköz programozása esetén így van, míg azonban a hagyományos programozás egyre magasabb absztrakciós szinteken jelenik meg, így a mögötte lévő gépi architektúra egyre inkább láthatatlanná válik, addig a GPGPU-k esetében mind a fejlesztői eszközök, mind a fejlesztés metodikája meglehetősen kezdetleges, így ott még gépközeli kódok írására van szükség. Időközben a GPGPU-k olyan szinten beépültek a köztudatba, hogy azok hardver ismerete már nem is jelent feltétlenül egy különálló, erre specializált tárgyat, hanem az már szerves részét kell, hogy képezze az 3

4 általánosan elfogadott számítógép architektúrákkal foglalkozó tárgyaknak (Sima, 2013), mint a többmagos CPU-k alternatívái. Környezet és nyelv kiválasztása Ez az előadás azonban főleg a grafikus kártyák programozására fókuszál, ami szintén felvet néhány fontos kérdést. Ezen a területen még messze nem beszélhetünk olyan kiforrott eszközökről, mind a hagyományos CPU-k esetében, ahol évtizedeken keresztül egymással kompatibilis processzorok jelentették a fő irányt, így ez a stabilitás lehetővé tette, hogy készülhessenek végletekig kifinomult programfejleszői környezetek, különféle programozási nyelvek. A grafikus kártyák esetében, bár a legnagyobb gyártók kártyái mind lehetővé teszik azok programozását, azonban maguk az eszközök egymással nem kompatibilisek (sőt, azok felépítése is meglehetősen különböző, így még egyszerű konverzióra sem számíthatunk az egyes architektúrák között). Emiatt két lehetőség közül választhatunk: Egy adott gyártó eszközeinek a választása. Az Nvidia esetében ebben az esetben egyértelműen a gyártó által fejlesztett CUDA programozási környezet jelenti a legegyszerűbb lehetőséget. Platformfüggetlen eszközök választása. Az OpenCL környezet lehetővé teszi olyan adatpárhuzamos programok fejlesztését, amely alkalmas mindkét nagy gyártó (Nvidia, AMD) kártyáinak a használatát. A gyakorlati tapasztalatok azonban azt mutatják, hogy ezek az eszközök valamivel nehézkesebbek, illetve éppen a teljes kompatibilitás miatt ezekkel nem használhatók ki az egyes kártyák apróbb lehetőségei. Így azt az esetet kivéve, amikor valóban szükség van az egyes kártyák között portolható kódok készítésére, ez a megoldás nem jelent különösebb előnyt. A fentiek alapján a CUDA környezetet választottuk (és ajánljuk most is) a fejlesztésekre, ami értelemszerűen azt jelenti, hogy célszerűen Nvidia grafikus kártyákkal felszerelt laborokra van szükség. A hardver eszközök kiválasztása itt szintén meglehetősen nagy odafigyelést igényel. A CPU-k esetében már olyan szinten konszolidálódtak a processzor architektúrák, hogy a sebességen túlmenően nem veszünk észre különösebb változást az egyes eszközök 4

5 között. A grafikus kártyák azonban még a mai napig dinamikusan, és néha drasztikus változásokon keresztül fejlődnek, így nem érdemes régebbi generációkat választani, mivel az nem pusztán lassabb lesz, hanem sok feladatra egyszerűen alkalmatlan. Egy lehetséges tematika Fontos leszögezni, hogy a GPGPU programozás jóval nehezebben sajátítható el, mint a hagyományos programozás, mivel: A rendelkezésre álló eszközök kevésbé kiforrottak. Kevesebb lehetőséggel bírnak, és a megbízhatóságuk sem 100%-os minden esetben (főleg a segédprogramok esetében, pl. debugger). A GPGPU, bár egyre inkább tekinthető általános célú eszköznek, még mindig számos korlátot tartalmaz, amikhez a fejlesztőnek alkalmazkodnia kell. Ez nyilván gyakorlatot igényel, hogy egy esetleges probléma esetén a programozó számára azonnal felmerüljenek alternatív utak, amelyek segítségével meg tudja oldani az adott feladatot. A hardver sajátosságaiból kiindulva, GPGPU programkódoknak főleg akkor érdemes nekiállni, ha maga a feladat nagyon jól párhuzamosítható, ami a gyakorlatban több ezer szál indítását is igényelheti. Mind az ilyen feladatok megértése, mind a megoldások megtervezése és implementálása csak tapasztalt programozók számára lehetséges. Ebből is látható, hogy nem kezdőknek szóló tárgyról van szó, csak olyanoknak ajánlható, akik már túl vannak a programozási alapismereteken, és azokat teljesen magabiztosan bírják, így tudnak rá biztosan építkezni (Tick, 2003). Az alapoknál kezdve célszerű az alábbi lépéseket követni: GPGPU hardver alapismeretek: mindenképpen lényeges megismerni ezeknek az eszközöknek a felépítését, és ha esetleg ennek már birtokában is vannak a hallgatók, akkor is fontos kiemelni a speciális jellemzők hatását magára a programfejlesztési folyamatra. Pl. a gyorsítótár hierarchia, illetve a kontextusváltás gyorsasága vezet ahhoz a felismeréshez, hogy a 5

6 végrehajtóegységek számánál jóval több szál indítása vezet általában a grafikus kártya csúcsteljesítményének kiaknázásához. CUDA programozási alapismeretek: mivel a CUDA a C nyelvre épül, így magának a programozási nyelv alapjainak a megismerése nem jelent különösebb problémát, az már néhány alkalom után elsajátítható. Természetesen számos újdonság is megjelenhet (eszközök kezelése, kernelek fordítása, indítása), de ezek többnyire csak technikai részletek, amelyek egy-két mintapéldán keresztül könnyen megérthetők. Fejlesztői környezet megismerése: bár az alapfogalmak hasonlóak, mégis számos megszokott eszköz másként működik a grafikus kártyák esetében. A fordítóprogram egyszerre fordít a CPU és a GPGPU számára is kódot, több ezer szál esetén egészen másként érdemes használni a nyomkövetést. Ezekre a részletekre mindenképpen célszerű időt szánni, mivel az algoritmusok megtervezését követő lépéseknél, lényegesek lehetnek. CUDA mélyebb ismeretek: mivel a GPGPU programozás célja a lehető legnagyobb teljesítmény elérése, így mindenképpen szükséges az eszközök használatának mélyebb ismerete. Ez amiatt is lényeges, mivel itt nem állnak rendelkezésre magas szintű automatikus optimalizációs lehetőségek, és bizonyos tervezési döntések (pl. megosztott memória használata) akár több százszoros sebesség növekedést, vagy csökkenést is eredményezhetnek. Mintafeladatok megoldása: hagyományos eszközökhöz szokott fejlesztőknek nehézséget okozhat az átállás adatpárhuzamos környezetbe, emiatt érdemes egy-két mintafeladaton keresztül kipróbálni a módszer lehetőségeit. Ezek abban is segíthetnek, hogy még az implementáció előtt tudjunk becslést adni arra, hogy egy esetleges GPGPU-ra való portolás milyen mértékű sebességnövekedést jelentene. Több GPU használata: a gyakorlatban ez már jóval nehezebben kivitelezhető, mivel olyan laborokra lenne szükség, ahol egy gépben egynél több CUDA kompatibilis kártya található, napjainkban ez még nem tekinthető általánosnak. Mindenképpen érdemes azonban szót ejteni ezekről a lehetőségekről, mivel az egyetemeken folyó kutatásokba bekapcsolódva már elérhetőek ezek az eszközök, teljesítményük pedig értelemszerűen többszöröse az egy grafikus kártyát tartalmazó rendszerekének. 6

7 Otthoni feladatok A programozásról általában elmondható, hogy nem tanulható meg pusztán heti 2-3 órában, mindenképpen a hallgató aktív közreműködését igényli. Ebben az esetben ez hatványozottan igaz, mivel a heti néhány órás alkalmak során csak az eszközök bemutatására, illetve néhány mintafeladat bemutatására van lehetőség. A meglehetősen nehézkes fejlesztés miatt már közepes méretű alkalmazások fejlesztésére sincs idő, ez azonban meglehetősen fontos, így célszerű ezt valamilyen otthoni feladat keretében megvalósítani. A mi esetünkben ezt beadandó házi feladat segítségével oldottuk meg, ami nagyon pozitív eredményeket hozott. A feladat egy egyszerű biológiai szimuláció megvalósítása volt: egy megadott területen Fű, Kecskék és Farkasok helyezkednek, megadott szabályok szerint mozognak, szaporodnak, vadásznak. A feladat az egyes szimulációs lépések végrehajtása adatpárhuzamos módon, illetve az aktuális állapot szemléltetése a képernyőn. A házi feladat egyik legnagyobb tanulsága az volt, hogy az adatpárhuzamos programozásban tapasztalatlan hallgatók ezen hiányosságukat nagyfokú kreativitással tudták ellensúlyozni. Az egyszerű feladat számos kérdést fel, már az adatok eltárolásától kezdve (milyen adatszerkezetben, milyen formában) az egyes szimulációs lépésekig (a legnagyobb probléma a különböző versenyhelyzetek kezelése). A hallgatóknak év végén egy rövid előadás formájában kellett bemutatniuk az elkészült programokat, illetve azok működési alapelveit. Tökéletesen működő feladatot ugyan csak kevesen tudtak bemutatni, mégis nagyon sok jó ötlet hangzott el, amelyek összegzéséből már valóban neki lehetne állni egy meglehetősen hatékony megoldásnak. Eredmények A GPGPU programozásban való jártasság napjainkban még nem tekinthető általános elvárásnak, így ennek megfelelően ez a tárgy is csak választható formában indult egymás után több éven keresztül. Azonban mindig meglehetősen nagy érdeklődés övezte, láthatóan a programozás iránt érdeklődő hallgatók számára kimondottan vonzó ez a terület. 7

8 Ennek megfelelően a hallgatók többsége sikeresen teljesítette a félévet, és eljutott arra a szintre, hogy alkalmas adatpárhuzamos algoritmusok tervezésére és azok implementálására. Ezt a tudást a későbbiekben nagyon jól kamatoztathatták egyéb, a programozáson alapuló tárgyak során (Vámossy et al, 2008). Maga az implementáció egy félév alatt szinte hiánytalanul elsajátítható, a tervezés azonban már egy sokkal összetettebb terület, ott a tapasztalatok azt mutatják, hogy mindenképpen szükség van többéves (hagyományos) programozói rutinra, hogy valaki jól átlássa egy feladat megoldási lehetőségeit, és azok közül ki tudja választani azt az alternatívát, ami hatékonyan implementálható GPGPU-n. Külön érdemes megjegyezni, hogy a hallgatók közül többen be tudtak kapcsolódni az egyetemen folyó kutatásokba, több szakdolgozat és diplomamunka témája is a grafikus kártyák programozásával foglalkozik. Hivatkozott források Bridget Maiellaro, University of Illinois named world's first CUDA Center of Excellence, wins parallel computing funding, ECO Illinois, 2008, D. Sima, Architecture of Parallel Systems (MSc course), Óbuda University, Course notes, 2013 J. Tick, How to achive good skills in Software Engineering a practical way to train software developers, 1st Slovalian-Hungarian Joint Symposium on Applied Machine Intelligence, Herlany, 2003 Z. Vámossy, Sz. Sergyán, Képfeldolgozás szakterületi oktatása, Informatika a felsőoktatásban 2008 konferencia, Debrecen, 2008, ISBN: Szerző(k) Szénási Sándor PhD Tanársegéd Óbudai Egyetem, Neumann János Informatika Kar, SZTI szenasi.sandor@nik.uni-obuda.hu 8