Oppositionsprotokoll Rapportförfattare: CARL BJÖRKMAN, MICHEL CUPURDIJA Rapportens titel: Igenkänning av instanslösningar i OpenCL Opponent: SAMUEL WEJÉUS Var det lätt att förstå vad exjobbet gick ut på? Kommentarer. Tyvärr var det rätt krångligt att förstå vilket problem de hade för avsikt att undersöka. Många olika begrepp togs upp och det var rätt svårt att förstå vad de specifierade sig mot innan hela rapporten lästs. Titeln för rapporten anger att arbetet kommer handla om Igenkänning av instanslösningar i OpenCL. I referatet anges att rapporten kommer handla om en undersökning av ramverket OpenCL genom att skapa en implementation av en problemlösare för verbalaritmetik. Vad sedan rapporten faktiskt handlar om är en jämförelse mellan olika verbalaritmetiklösare som körs, och använder sig av, olika typer av hårdvara. Jag är av den uppfattningen att en stor del av projektet gick ut på att konstruera en verbalaritmetiklösare (nämns i referatet) men prolemformuleringen nämner inget om detta och förklaringen av vad verbalaritmetik är kommer först i kapitel 4. För att vidareutveckla problematiken i de frågeställningar som identifierats i texten samt den fakta jag som läsare förväntar mig kunna hitta i rapporten ger jag här en punktlista över de frågor och påståenden som ställs och för vika jag inte kunnat hitta något svar! I denna uppsats ska vi undersöka hur mycket prestanda man kan vinna vid beräkningsintensiva probleminstanser och hur mycket tid som går åt till att göra implementationen i detta ramverk istället för en sekventiell implementation i språket C+ +. Denna fråga tolkar jag som att de även ämnar undersöka skillnaden i utvecklingstid. Ingen disskusion för denna fråga går att finna så när som på en kort mening över hur många timmar som lades ner på implmentation. Som testproblem använder vi det matematiska spelet verbalaritmetik. Detta problem har visats vara NP-fullständigt[8] och instanser av problemet blir därav väldigt beräkningsintensiva att lösa med en brute force-algoritm. Denna egenskap gör att problemet lämpar sig väl för testningsändamål. Varför gör dessa egenskaper att problemet är lämpligt? Vår hypotes är att en probleminstans av tillräckligt hög storlek kommer att kunna lösas snabbare med OpenCL på en dator med ett tillräckligt kraftfullt grafikkort än en vanlig C+ +-implementation kan lösa samma instans. Vad är en tillräckligt hög storlek på probleminstans? Hur tycker du att titeln avspeglar rapportens innehåll?
Mycket av svaret är gett genom tidigare kommentar. Björkman och Cupurdija anger i inledningen till kapitel 4, jag citerar; Vårt syfte är att använda OpenCL för att hitta lösningar till instanser av svåra problem. vilket är en direkt motsägelse mot titeln för rapporten då titeln syftar till igenkänning och inte att finna lösningar. Jag anser det vara två helt skilda syften. Hur beskrev författaren bakgrunden till exjobbet? Finns det en introduktion till och översikt av området? (följande paragraf är skrivet mot bakgrund av vad som presenterats i kapitel 1: Introduktion ) Det finns en kort introduktion som rätt knapphändigt motiverar vikten av deras undersökta ämne, nämligen paralellprogrammering. Efter en kort introduktion av hur konstruktion av hårdvara, specifikt CPU konstruktion, förändras mot nya arkitekturer dras snabb slutsatsen att varje utvecklare bör satsa på parallella beräkningar. Givet slutsatsen om parallellprogrammeirng känns den inte helt motivierad, eller korrekt, med bakgrund av den fakta som presenteras. Vidare ställer jag mig tveksam till deras resonemang då inledande presentation innehåller flertalet faktafel, rörig blandning av begrepp och icke logiska slutsatser. Som exempel kan ges hur de presenteras Mooreʼs lag som om det vore given fakta, men då det egentligen handlar om en förutsägelse, skapar det en känsla av att de inte riktigt har utforskat området ordentligt. (följande paragraf är skrivet mot bakgrund av vad som presenterats i kapitel 2: Bakgrund samt tidigare kapitel) Bakgrunden beskriver problemet, behovet av parallelism och OpenCL. Vad jag saknar är relaterad forskning samt referenser till denna. Finns det fler alternativ än OpenCL för parallellberäkningar? Det enda som tas upp är två sätt att använda GPU men finns det några andra alternativ som ger samma funktionalitet som OpenCL dvs, kan utnyttja godtycklig beräknings enhet? Jag saknar även referenser till sådan information. Även bakgrunden innehåller faktafel som drar ner helhetsintrycket, som exempel påstår de att företaget AMD skapade och lanserade ett interface kallat Close to metal men faktum är att det var ATI som stod för det (vilket numer är en del av AMD, men vid lanseringstillfället var ett fristående företag). Exempel två: Förutsatt att P!=NP tar det exponentiell tid att känna igen en lösning till en instans. Jag anar att detta möjligtvis kan vara en felskrivning, men vad som denna mening (genom användnng av orden känna igen ) säger är att verifiera en lösning tar exponentiell tid. För det första motsäger de sig själva här då författarna tidigare i texten påstår att en verifikation går i polynomisk tid vidare är det ett felaktigt påstående då det faktiskt finns NP-fullständiga problem som kan lösas i icke-exponentiell tid. Tex independent-set problemet är NP-fullständigt då det begränsas till planära grafer men kan lösas i subexpoentielltid (vilket fortfarande är högt men lägre än exponentiell). Hur väl har författaren motiverat sitt val av metod att angripa problemet? Är metoden väl beskriven? Metoden, att jämföra två olika implementationer (parallell resp. icke-parallell) är väl beskriven men motivationen till varför den icke-parallella implementationen är utformad på
det sättet den är saknas. Att utelämna en sådan vital del skapar frågor så som: är den icke-parallella jämförelse implementationen verkligen optimal?. Denna fundamentala fråga påverkar resultatet av deras undersökning då jag som läsare inte helt kan lita på de resultat som presenteras, nämligen den relativa skillnaden i prestanda mellan parallella och icke-parallella program. I kapitel två presenteras en sats Brents Theorem som, vad jag förstår det som, används i hypotesen i kapitel 4. Dock saknas helt och hållet en referens till att denna sats använts och på vilket sätt. Analysen av komplexitet är väldigt krånglig att följa, ett exempel kanske skulle ha underlättat? Författarna påstår att: Det faller naturligt att lösa instanser av verbalaritmetik med rekursion. men ingen motivation ges så jag ställer mig frågande till varför detta val gjorts och om det verkligen är det optimala. Diskuterar författaren huruvida de förutsättningar som gäller för att metoden ska kunna användas är uppfyllda? Ja, här tycker jag att författarna ger tillräckligt med information. Som exempel tas upp hur vissa begränsningar (alternativt kallat designval) gjorda av NVIDIA (se Nvidia watchdog) påverkar resultatet och hur detta har tagits i beaktning i resultat. Har författaren presenterat sina resultat tydligt? Kapitel 4: Hypotes och metod består till stor del av en analys av tidskomplexitet för program skrivna genom användning av parallellprogrammering. Vid presentation av resultat ställs denna nyvunna information aldrig mot förväntat resultat (som borde erhållits genom komplexitetsanalys) denna koppling anser jag väldigt viktig och vid eventuell förbättring av rapporten så rekommenderar jag att prioritera denna punkt. Presentation av resultat sker genom användning av stapeldiagram vilket är väldigt bra då jag som läsare får har lättare att visualisera skillnaden. Jag saknar dock data för dessa diagram i form av tabeller med faktiska värden så att jag själv kan observera resultat. Detta hindrar mig från att eventuellt kunna upprepa försöket och jämföra med tidigare resultat på ett effektivt sätt. Jag saknar även en djupare förklaring av diagrammen, för att motverka eventuella missförstånd. En enkel mening som skulle sagt lägre värde är bättre skulle tex underlättat. författarens slutsatser trovärdiga? Mot bakgrund av vad jag tidigare påpekat angående faktafel, bristande information om implementation av det icke-parallella referens programmet. Den enda slutsats jag vågar lita på är att enbart parallellprogrammering av CPU ger prestanda vinst. Här vill jag även påpeka att författarna har en ger en teori som känns väldigt trovärdig till varför CPU utklassar GPU och det är att en CPU har större mängd cache minne än GPU vilket ger högre prestanda.
Vad tycker du om litteraturlistan? Vilken typ av litteratur finns med? Förefaller litteraturen relevant? Litteraturlistan är välspecifierad och känns relevant. Författarna har tydligt angett vilka delar av en källa de har använt och jag upplever att det är enkelt för mig som läsare att gå in och kontrollera påståenden. Vilka avsnitt i rapporten var svåra att förstå? Kapitel 4: Hypotes och metod. Först vill jag nämna att först här presenteras det problem, verbalaritmetik, författarna ämnar använda sig av jag anser att det istället borde presenterats tidigare, förslagsvis inom ramen för bakgrund. Komplexitetsanalysen som görs för problemet är ganska svår att följa, möjligtvis skulle lite diagram och bilder underlätta. Jag förstår heller inte vikten av att göra denna analys då resultatet av denna analys aldrig används i resultatet för rapportens problemformulering? Av hela kapitlet om hypotes och metod så är det egentligen enbart följnade paragrafer som säger något om just hypotes och metod: Vår hypotes är att en probleminstans av tillräckligt hög storlek kommer att kunna lösas snabbare med OpenCL på en dator med ett tillräckligt kraftfullt grafikkort än en vanlig C++implementation kan lösa samma instans. Enligt PRAM-modellen (se kapitel 2.2) har vi i detta problem att t =θ( m2), då evalueringen är det enda som inte går att parallellisera. Om vi har O( b)!" antal processorer (vilket vi kan enligt resonemang i PRAM-modellen) får vi då en tidskomplexitet på O( m ). Vi implementerar en lösare i ren C++ och en i C++ med OpenCL. Vi låter sedan genera testfall, kör dessa med olika konfigurationer och låter analysera resultaten. Denna snutt känns alldeles för kort och lämnar för många frågor öppna om metod, tex om konfigurationer, hårdvara, vad är tillräckligt hög storlek av problem instans? Hur kommer testfallen se ut? Hur kommer resultaten analyseras? Viss information om hur testfallen är utformade, vilken hårdvara som använts och hur konfigurationerna är upplagda ges förs i resultatdelen men vad är det vitsen med att ha ett separat kapitel om hypotes och metod? Ren kod för testfallen förkommer dock i appendixet för den som är villig att studera denna men jag som läsare skulle även vilja ha en översiktsbild på hur dessa test är utformade i just hypotes och metod kapitlet. Övriga kommentarer om rapporten och dess struktur. Personligen tycker jag hela diskussionen om NP problem är rätt onödig, det hade räckt med att presentera ett problem som är beräkningstungt och kort motivera dess användning. Det faktum att problemet som användes var NP-fullständigt hade inte påverkat resultatet. Språket i texten innehåller många upprepningar (som exempel används ordet ʻdettaʼ alldeles för mycket) och är ganska rörig. Texten är svår att läsa då det förekommer många syftingsfel.
Användning av ordet man sänker kvaliten på texten. Motivation varför ordet ʻmanʼ inte bör användas: Ordet man är ett opersonligt pronomen och är användbart när man talar i allmänna termer och inte åsyftar någon speciell person (som i det här stycket till exempel). Men så snart man behandlar personer eller grupper som kan ges en mera bestämd beteckning bör ordet man undvikas. (http://www.svet.lu.se/mikromanualer_och_gula/gula/skriva_och_tala_svensk/ Gula_kap4.html) Överdriven användning av kursiv text i ett försök att understryka viktiga punkter. Övriga åsikter är gjorda direkt i rapportenʼs PDF version, tydligt utmärkt med markeringar och kommentarer. Vilka är arbetets/rapportens starka sidor? Presentationen av OpenCL ger en väldigt övergripande bild av hur OpenCL fungerar och vad det kan användas till. Jag känner att jag fick en tillräckligt grundlig introduktion av OpenCL och det sådde ett frö för vidare personliga studier av OpenCL. Möjligtvis kan presentationen av OpenCL C behöva utökas något (lite rörigt). Vilka är arbetets/rapportens svaga sidor? Förekomsten av faktafel och till viss del presentation av egna åsikter som fakta gör att jag känner att jag som läsare inte kan lita på att det jag läser är korrekt. Texten är ganska rörig då det inom olika kapitel framkommer ny information som borde avhandlats i andra sektioner. Språkmässigt håller rapporten ganska låg standard vilket ger ett negativt intryck. Hur bedömer du arbetets nyhetsvärde? Beroende på målgrupp skulle jag vilja säga att för tex universitetsstudenter på grundnivå kan det vara en intressant introduktion till parallellprogrammering och OpenCL genom att vidga vyerna med vilka möjligheter som finns. För en läsare på högre kompetensnivå anser jag att nyhetsvärdet är otillfredsställande på grund av otillräcklig dokumentation av hypotes, metod och resultat. Då flertalet faktafel förekommer måste jag tyvärr säga att rapporten inte känns helt genomarbetad och jag ställer mig tveksam till om jag kan lita på resultaten. Sammanfatta arbetet på ett par rader. Frågor till författaren: Varför valde ni att lösa verbalaritmetikproblem genom rekursion? Varför är detta optimalt? Skulle det gå att lösa på något annat sätt? Hur använder ni resultatet från komplexitetsanalysen av verbalaritmetik problemet och till vad? Vart går grånsen för tillräckligt hög probleminstans? Förklara ytterligare då jag inte kan utläsa det tillräckligt tydligt från er text.
Vilket är ditt sammanfattande omdöme om exjobbet? Efter lite rörigt upplägg och svårighet i att enas om problemformulering tycker jag endå att det var intressant läsning då det, för mig personligen, gav en introduktion till de möjligheter som finns för parallellprogrammering.