OŠKERA, J. Sada testovacích úloh pro grafické karty [online]. Brno: Vysoké učení technické v Brně. Fakulta informačních technologií. 2024.
Z práce je jasně vidět, že není hotová. Student si špatně rozvrhl práci a na implementaci benchmarků a sepsání textu, tedy faktického jádra práce, mu zbyl cca jeden měsíc. Práce s repositářem pro zdrojové kódy byla podprůměrná. Za největší problém považuji, že jsem před odevzdáním viděl jen torzo práce a měl tak nulovou možnost komentovat výsledky, které jsou z mého pohledu prezentovány silně zavádějícím způsobem.
| Kritérium | Známka | Body | Slovní hodnocení |
|---|---|---|---|
| Informace k zadání | Cílem diplomové práce bylo vytvořit sadu vzorových úloh pro testování výkonnosti grafických karet, které by bylo možné použít ve výuce, a které by demonstrovaly vliv různých optimalizací a technik na výkonnost daného problému. S výsledky práce nejsem spokojen. Student strávil příliš mnoho času s tvorbou GUI aplikace a na vlastní implementace testovacích úloh již nezbylo mnoho času. To se odráží na jejich jednoduchosti, špatné optimalizaci a naprosté absencí HW výkonnostních metriky typu GFLOP/s, GB/s, IPC, cache miss rate, branch miss rate, atd. Hlavní problém vidím v porovnaní výkonnosti jednotlivých variant. Jako základ je použita naivní CPU verze, která nemá implementovanou podporu pro vektorizaci, cache blocking, redukci větvení, atd. Procesorová implementace měla být tou nejlepší možnou, aby se plně odhalil potenciál CPU a bylo možné výkon GPU realisticky porovnat. U GPU bylo naopak záhodno začít s nejjednodušší implementací a postupně je vylepšovat. Autor se však moc daleko nedostal. První problém spatřuji v typech dekompozic, které vedou k silnému podvytížení GPU, o čemž se však práce nezmiňuje. Kernely jsou navíc velice složité, konzumující velké množství registrů (o čemž se autor také nezmínil) a celkově dosahující velice špatného využití GPU. Správně měla být dekompozice provedena tak, že na výpočtu jedné částice se podílí celý blok vláken, ne jen jedno vlákno. Pro menší problémy je tak úroveň paralelismu příliš nízká na to, aby bylo možné vyžít plný potenciál GPU. Práce rovněž nevyužívá plně potenciál sdílené paměti, či pokročilých technik. Vyhodnocení zrychlení jednotlivých algoritmů bez znalostí HW metrik a informace o tom jak se aktuální výkon blíží teoretickému na dané architektuře, je v podstatě bezcenné. Tedy konstatování, že GPU je 10x rychlejší než vícevláknová CPU, aniž bych řekl, že CPU využívá 30% své výpočetní kapacity při 80% využití propustnosti paměti, nedává žádný smysl. Kompletní opomenutí těchto metrik by se dalo vyhodnotit jak nespění části bodu 2 zadání. Varianta s více GPU mohla ukázat časový profil aplikace, čas nutný pro výměnu dat, atd. OpenMP varianta pro GPU bohužel nefunguje. Zde je vidět, že autor již neměl čas implementaci řešit a hledat, kde je chyba. Celkově je tedy z práce použitelné GUI a framework pro implementaci jednotlivých úkolů. Vlastní implementace je však nutné silně přepracovat a přeměřit. | ||
| Práce s literaturou | Student pracoval s literaturou především samostatně. V práci chybí hlubší rozbor existujících benchmarků, případně odkazy na nějaká srovnaní grafických karet. Rovněž bych rád viděl odkazy na existující implementace problému XPDB. | ||
| Aktivita během řešení, konzultace, komunikace | Student byl během řešení poměrně aktivní, chodil na konzultace a předkládal nápady a diskutoval stav prací. Bohužel repositář se zdrojovými kódy byl modifikoval pouze ve velkých kvantech, a to cca 4x za dobu řešení, což je velmi málo. Měl jsem tak silně ztížené podmínky pro identifikaci problémů v implementaci. Jak je již psáno výše, student si špatně rozvrhl práci a strávil příliš mnoho času při návrhu GUI a frameworku, které je sice pěkný a má vysokou přidanou hodnotu, ale díky tomu nestihl jádro práce včas implementovat a otestovat do požadované hloubky. | ||
| Aktivita při dokončování | Aktivita při dokončování byla hektická. Z důvodu nedostatku času jsem neviděl ani finální implementaci, ale ani text zprávy. Viděl jsem cca 40% textu a zbytek až po odevzdání. K práci mám spoustu faktických, formálních i prezenčních výtek, ale bohužel nebyla šance jak je autorovi sdělit. | ||
| Publikační činnost, ocenění |
Výsledek práce studenta (tj., realizační výstup a technickou zprávu) navrhuji ohodnotit stupněm D ; odůvodnění: Zadání považuji za obtížnější , student vykonal nezanedbatelný objem realizačních činností pro splnění požadavků zadání, realizační výstup splňuje stěžejní požadavky zadání a je poměrně kvalitní , technická zpráva je, souhrnně hodnoceno, neuspokojivá .
| Kritérium | Známka | Body | Slovní hodnocení |
|---|---|---|---|
| Náročnost zadání | Zadání považuji za obtížnější , a to zejména kvůli požadavku návrhu sady úloh dle bodu 4 zadání, který bylo nutné splnit s předstihem , což kladlo nároky na načasování souvisejících činností. Za neméně náročnou považuji volbu a přípravu podmínek, prostředků a metod pro otestování navržené sady dle bodu 5 zadání v multi-GPU prostředí tvořeném alespoň čtyřmi grafickými kartami. Zadání považuji za řešitelné pomocí vědomostí, dovedností a zkušeností získaných během dosavadního studia . | ||
| Rozsah splnění požadavků zadání | Jelikož stěžejní body zadání (viz výše, Náročnost zadání) byly splněny, tak zadání považuji za splněné , avšak s vážnou výhradou k řešení požadavků bodů 3 a 7 zadání - požadovanou metodiku (viz bod 3) ani diskusi (viz bod 7) totiž technická zpráva řádně nedokumentuje a je tedy diskutabilní , zda realizační výstup práce naplňuje očekávaný účel . Méně závážnou výtku mám také ke splnění požadavků "prostudujte" a "vyhodnoťte" bodu 2 zadání a požadavku "brát v potaz vysokoúrovňové programovací jazyky" bodu 4 zadání - tyto požadavky sice považuji za splněné , nicméně přinejlepším neuspokojivě . | ||
| Rozsah technické zprávy | Rozsah technické zprávy (TZ) považuji za podprůměrný , a to především kvůli neuspokojivé dokumentaci rešeršní etapy (dokumentaci k bodům 1 a 2 zadání považuji přinejlepším za základní , dokumentace k bodu 3 prakticky schází ), bodem 7 zadání požadovaná diskuze v TZ schází . | ||
| Prezentační úroveň technické zprávy | 55 | Technická zpráva (TZ) je dobře strukturovaná a její jednotlivé části na sebe logicky navazují , nicméně souhrnně její prezentační úroveň považuji za silně podprůměrnou , a to zejména kvůli mnohým nedostatkům , např.: dominující nadměrný počet překlepů a chybějící slova , občasné používání nesprávných, neobvyklých, nevhodných apod. slov či slovních spojení (např. "kdyby jste", "spoustu-krát", "je to taková výrobní linka", "hromada stejných věcí najednou", "klastr" (vláken), "třída je jedináček", "opáčko", testovací počítač ("stroj") označený jako "stařec"), nejednotnost práce se zkratkami (např. cpu-CPU, gpu-GPU, sm-SM), český/anglický abstrakt je velmi stručný - nezmiňuje např. stěžejní prostředky, metody, výsledky a z nich plynoucí zjištění/závěry, po přečtení TZ zůstává řada , při jejím čtení vyvstanuvších, otázek (stěžejní ot. viz část Doplňující otázky k obhajobě) bez odpovědi . | |
| Formální úprava technické zprávy | 60 | Úroveň formální úpravy technické zprávy (TZ) souhrnně považuji za průměrnou . Z hlediska čistě jazykového , bez ohledu na informační hodnotu (viz Rozsah technické zprávy), hodnotím TZ jako podprůměrnou (viz Prezentační úroveň technické zprávy); tu však dále snižuje stránka typografická , jejíž úroveň nicméně hodnotím jako průměrnou - vytýkám především mnohé jednopísmenné spojky/předložky na koncích řádků, opakované neodkazování se na objekty (obrázky, algoritmy aj.), "bílá místa" v textu či přesah textu přes okraj stránky. | |
| Práce s literaturou | 60 | Informační zdroje použité v technické zprávě (TZ) základně pokrývají problematiku řešenou v rámci práce a v TZ je na ně odkazováno způsobem umožňujícím odlišení prvků vlastních od převzatých. Za neuspokojivé však považuji pokrytí TZ informačními zdroji v jejích kap. 3 (Technologie), kap. 4 (Existující možnosti). | |
| Realizační výstup | 79 | Stěžejní část realizačního výstupu (RV) tvoří programové vybavení psané v jazyce C++ , konkrétně třídy GLEngine, Simulation, Storage aj. (viz podkap. 6.1), zadáním požadové úlohy (viz podkap. 6.2) a testy (viz kap. 7), s využitím dalších technologií (mj. CUDA, OpenMP a OpenGL) a knihoven. Až na problémy s vysokoúrovňovou implementací pomocí OpenMP (viz část 7.1.8) je implementace souhrnně nadprůměrně kvalitní (přehledná, dekomponovaná a rozvržená do adresářů a zdrojových souborů, komentáře zdrojových souborů jsou poměrně pečlivé a umožňují generování technické dokumentace pomocí Doxygen atd.), prověřena sadou testů , dle mého názoru, splňuje požadavky zadání , byť požadavek bodu 5 zadání ohledně testování pomocí systému "s minimálně 4 grafickými kartami" je splněn pouze (v zadáním dané) minimální podobě . Dokumentaci implementace v technické zprávě považuji, díky její horší přehlednosti/čitelnosti, souhrnně spíše za průměrnou , ale obsajující vše podstatné k implementaci a jejímu zhodnocení - vyjma diskuze požadované bodem 7 zadání. | |
| Využitelnost výsledků | Především vzhledem k celkově neuspokojivé dokumentaci je využití realizačního výstupu přinejlepším diskutabilní . |
eVSKP id 154573