Grafikkort till parallella beräkningar

Transkript

1 Teknik och samhälle Datavetenskap Examensarbete 15 högskolepoäng, grundnivå Grafikkort till parallella beräkningar Graphics cards for parallel computations Författare: Sani Music Examen: Högskoleingenjörsexamen 180 hp Huvudämne: Datavetenskap Program: Data och telekom Datum för slutseminarium: Handledare: Mia Persson Examinator: Ivan Kruzela

2 Resumé Den här studien beskriver hur grafikkort kan användas på en bredare front än multimedia. Arbetet förklarar och diskuterar huvudsakliga alternativ som finns till att använda grafikkort till generella operationer i dagsläget. Inom denna studie används Nvidias CUDA arkitektur. Studien beskriver hur grafikkort används till egna operationer rent praktiskt ur perspektivet att vi redan kan programmera i högnivåspråk och har grundläggande kunskap om hur en dator fungerar. Vi använder s.k. accelererade bibliotek på grafikkortet (THRUST och CUBLAS) för att uppnå målet som är utveckling av programvara och prestandatest. Resultatet är program som använder GPU:n till generella och prestandatest av dessa, för lösning av olika problem (matrismultiplikation, sortering, binärsökning och vektor-inventering) där grafikkortet jämförs med processorn seriellt och parallellt. Resultat visar att grafikkortet exekverar upp till ungefär 50 gånger snabbare (tidsmässigt) kod jämfört med seriella program på processorn. Abstract This study describes how we can use graphics cards for general purpose computing which differs from the most usual field where graphics cards are used, multimedia. The study describes and discusses present day alternatives for using graphic cards for general operations. In this study we use and describe Nvidia CUDA architecture. The study describes how we can use graphic cards for general operations from the point of view that we have programming knowledge in some high-level programming language and knowledge of how a computer works. We use accelerated libraries (THRUST and CUBLAS) to achieve our goals on the graphics card, which are software development and benchmarking. The results are programs countering certain problems (matrix multiplication, sorting, binary search, vector inverting) and the execution time and speedup for these programs. The graphics card is compared to the processor in serial and the processor in parallel. Results show a speedup of up to approximatly 50 times compared to serial implementations on the processor. Centrala nyckelord: Nvidia CUDA, THRUST, CUBLAS, Eigen, OpenMP, accelererade bibliotek, prestandatest, GPU, CPU, vektor inventering, sortering, binärsökning, matrismultiplikation

3 Innehåll 1 Inledning Forskningsfråga Syfte Målgrupp Avgränsningar Metod Metodval Experimentkonstruktion Mätdata Litteratur Metodkritik Teknisk bakgrund Parallellism HyperThreading och speedup Grafikkort GPU Grafikkortets minne Grafikkortet till generella beräkningar Standard template library Binärsökning Sortering Vektorinventering Matrismultiplikation Eigen Fördjupning i Nvidia CUDA CUDA C/C Minneshantering i CUDA Kernel i CUDA Parallellism i CUDA Synkrona och asynkrona CUDA exekveringar Accelererade bibliotek och THRUST THRUST CUBLAS Experiment Vektorgeneratorn Struktur på vektorhanterings program Parallellt på CPU med OpenMP Sortering med THRUST och STL Binärsökning med THRUST och STL Vektorinventering med THRUST och STL

4 5.7 Matrismultiplikation av kvadratiska matriser Matrismultiplikation på CPU Matrismultiplikation på GPU med CUBLAS Diskussion Analys av vektor program Analys av matrismultiplikation Slutsats Vidare studier A Mätdata vektorhanterings program 35 B Mätdata matrismultiplikation program 37

5 1 Inledning Spel och annan form av multimedia driver utveckling av grafikkort fort de senaste åren. Grafikkorten tillgängliga på marknaden i nutid är mer kraftfulla och utbudet är större jämfört med förr [21]. Ifall vi jämför grafiken i spel idag med 10 år gamla spel ser vi en visuell förbättring, grafiken (flöde av bilder) skapas på grafikkortet [11]. Om vi omdirigerar kapaciteten som går åt att skapa dessa bilder till andra områden än multimedia får vi någon form av prestanda. Det är denna prestanda och tillväga som diskuteras och analyseras i uppsatsen. Detta är intressant eftersom det undersöker sätt att ge ökad prestanda med hårdvara ofta befintlig i stationära och bärbara datorer. Grafikkort är parallella enheter som utvecklats till many-core (Nvidia GT550M har 144 kärnor) system. Algoritmer som går att tillämpa på grafikkortet är parallella algoritmer. Visa av dessa algoritmer utvecklades under 80 talet för att användas på (då) dyra svåråtkomliga (då) superdatorer. Dessa algoritmer går att implementera på grafikkort idag eftersom dessa är hårdvarumässigt byggda för many-core parallellism. [21] Grafikkort går att använda till generella beräkningar (annat än multimedia). Forskare och utvecklare inser speciellt med lansering av Nvidia Geforce 3 kretsen (år 2001) råkraften grafikkort har i generell beräknings kapacitet. Men att använda denna råkraft till annat än grafiska uppgifter är en då tidskrävande process. Eftersom det endast är möjligt genom att använda grafiska APIs (OpenGL, DirectX) och lura grafikkortet att utföra generella beräkningar. Detta förändras när Nvidia år 2006 (tillsammans med Geforce 8 serien) lanserar sin CUDA arkitektur, speciellt konstruerad att tillåta grafikkort att utföra generella beräkningar. [18] Nvidia menar att det ska gå att få betydligt snabbare programvara vid användning av CUDA arkitekturen jämfört med seriella implementationer, tresiffriga tal används t.ex gånger snabbare [42]. Wynters visar i artikeln Parallell processing on Nvidia graphics cards [53] parallellism rika fall där grafikkort med Nvidia CUDA teknologi presterar upp till 2412 gånger snabbare än motsvarig seriell implementation på processorn. 1.1 Forskningsfråga Har tiden kommit då det finns en aritmetisk superdator i de flesta hem och i så fall hur lätt är det att använda den? Hur mycket tidsmässigt snabbare är parallellt exekverbar programvara på ett Nvidia GT550M grafikkort jämfört med en Intel 2670QM i7 processorn med hänsyn till parallellt och seriellt exekverade program på processorn? 1

6 1.2 Syfte Denna studie syftar till att ge utvecklare och andra intressenter en introduktion, vägledning och mätdata i processen att utnyttja GPU-kapacitet i datorer. Samt förklara vilka alternativ som finns i fältet. Studien syftar att presentera program och prestandamätdata av dessa som är baserad på CUDA teknologi. Mätdata som produceras och tillvägagångsätt för denna är centrum för studien och det är resultatet av dessa som ska hjälpa intressenter i eventuellt val av implementering av CUDA i programvara. 1.3 Målgrupp Delar av denna uppsats är främst till läsare som redan har programmerings kunskap i högnivåspråk helst C, C++ (p.g.a. b.la. minneshantering) dessutom god datorvana och förståelse för grundbegrepp inom datorer. Läsare som inte har dessa kunskaper kan studera diskussions avsnittet utan att förstå studien i detalj. 1.4 Avgränsningar Tabellerna här visar vilken mjukvara respektive hårdvara som används i studien. Samtliga experiment i denna uppsats använder denna hårdvara och mjukvara. Tabell 1: Hårdvaruspecifikation i denna studie Tillverkare Typ Namn Relevant Information Intel Processor Core i7 2670QM 32nm (2nd gen) 2.2GHZ, 6MB Cacheminne, 4 kärnor Nvidia Grafikkort GT 550M (40nm) 144 CUDA cores (1.48GHZ GPU), 1GB GDRAM Samsung Ram RAM DDR MB 1.33 GHZ DDR3 SDRAM-minne [37], [45], [16]. Tabell 2: Mjukvaraspecifikation i denna studie Leverantör Typ Namn Relevant Information Microsoft Operativsystem Windows 7 SP1 Microsoft Kompilator Visual Studio C++ Ver 2010 Ultimate edition OpenMP ARB API Open MP Integrerad i kompilator Nvidia Arkitektur CUDA V4.1 Nvidia Bibliotek CUBLAS V4.1 THRUST Bibliotek THRUST V1.51 (Inkl i CUDA) Eigen Bibliotek Eigen V3.05 [34], [13], [9], [40]. Experiment i denna uppsats är begränsade till enbart Nvidia CUDA teknologi, 2

7 andra teknologier diskuteras kort men behandlas ej i denna uppsats p.g.a. uppsatsens omfattning i tid. 3

8 2 Metod Vi diskuterar några möjliga empiriska studier som tas upp av Heiko Koziolek i The Role of Experimentation in Software engineering [24]. Kontrollerade experiment är metoden med högst pålitlighet eftersom den tillåter mest kontroll över variabler som kan påverka resultatet förutom den oberoende variabeln. En mindre strikt metod är fallstudien där ett specialfall analyseras, initiala förhållande kan analyseras men slutsatsen är inte generaliserbar. Metastudier analyserar andra studier för att sedan jämföra resultaten. Experiment är byggda runt en mini verklighet vilket innebär att det handlar om en förenklad bild av verkligheten där problemen är isolerade (Många variabler abstraheras bort). Fördelen att använda experiment är återupprepningsbarheten och att vi har stor kontroll över variabler som påverkar studien. [4] 2.1 Metodval Vi väljer en kvantitativ empiriska studie med kontrollerade experiment där mätdata samlas och analyseras. Experimenten och resultatet av dem är centralt för studien och det viktigaste. Teorin som används finns i kapitel 3, 4 och motiverar detaljerat vilka val som tas praktiskt och varför just dessa anses vara bäst. Kapitel 5 visar detaljerat experimenten, hur dessa utförs (mätdata finns som appendix). Experiment kapitlet diskuterar val som tas i detalj med experimenten och motiverar varför dessa val tas. Resultatet vi strävar efter är av orsak-verkan typ. Vi skriver egna CUDA applikationer som vi sedan jämför med likvärdiga egenskrivna C++ program i experiment och observerar tiden (mätdata) som krävs för olika subrutiner att exekvera. Det skulle även gå att använda existerande program och studier för att uppnå syftet (utan hårdvaru avgränsningen). Men detta sätt är inte lika intressant då det inte medför någon ny mätdata till området. Genom experiment ser vi en praktisk implementation av teorin och hårdvaran vi använder. Vi skriver inte program ämnade åt absoluta slutanvändare då denna typ av programvara kräver resurser utanför vår tidsram d.v.s. accepterar vi att våra program inte är absolut felfria Experimentkonstruktion Det finns några olika sätt att uppnå syftet praktiskt med kontrollerade experiment. Ett sätt är att skriva egna algoritmer på processorn och grafikkortet och sedan jämföra exekverings tid av dessa. Detta är det svåraste sättet och det som kräver mest djup förståelse för b.la. hårdvara och mjukvara. Syftet skulle gå att uppfylla på detta sätt men det är inte best practice eftersom det inte visar hänsyn till teorin (se kapitel 3,4) från b.la Nvidia och tidigare studier speciellt Langdons debuging cuda [25]. Fördelen med detta sätt är att vi kan skapa nya algoritmer kanske bättre än de som existerar i specialfall. 4

9 I denna studie väljs fyra problem att behandla på grafikkort och processorn. Dessa är binärsökning, vektor inventering, sortering, matrismultiplikation. Samtliga av dessa fyra problem är återkommande i datavetenskap. Vi väljer i denna uppsats att arbeta med existerande bibliotek och algoritmer (CUDA och CUBLAS på grafikkortet, STL och Eigen på processorn) i full möjlighet då detta ger kvalitativ kod att utföra experiment med och bör därför ge mer relevant mätdata för forskningsområdet och intressenter. 2.2 Mätdata Mätdata byggs runt tid som är oberoende av resten av experiment och går att mäta med instrument helt oberoende av hårdvaran. Prestandatest är upprepningsbara fast med hänsyn till omständigheter (OS bakgrundsaktiviteter) kan avvikelse ske. Mätdata sparas i tabeller bifogade till uppsatsen. Ur mätdata kan vi skapa nya tabeller som ger översiktlig information. Mätdata innehåller alltid ett unikt s.k. Test ID som skiljer exekveringen av det specifika experimentet från resten. Vi tar i beaktning eventuella felkällor i vår mätdata och försökt minimera dess påverkan. Den främsta felkällan som kan störa vår data är att CPU:n är belastad under framtagning av mätdata respektive GPU:n men detta undviks genom att överbevaka systemresurser och inte använda datorn till något annat än experiment vid datainsamling. Vidare så är en annan störning att när vi kallar på GPU:n så är kallelsen asynkron dvs återlämnar GPU exekveringen kontroll till CPU omedelbart efter exekvering. För att kunna ta verklig tidstagning följer vi rekommendationer i "CUDA best practices och gör tidtagning synkroniserat (detaljer finns i teori avsnitt). 2.3 Litteratur Vi använder relevant litteratur i form av internetsidor, böcker, material från Nvidia och vetenskapligt material för att utveckla teori om grafikkort till generella beräkningar. Speciellt används två böcker Programming massivly parallell programs [21] av Kirk, Hwu och introduction by Example to CUDA [18] av Kandrot och Sanders. Från Nvidia är Cuda C Best Practice Guide [35], Cuda C Programming Guide [39], Cublas Documentation V4.1 [41] intressant material. 2.4 Metodkritik Experiment ger hög validitet men kan anses vara en förenklad världsbild som inte ger full i insikt och hänsyn till omgivningen, experiment kan vara dyra att utföra. Ibland missanvänds statistik av mjukvaru experiment. Experimenten kommer endast ge en djup förståelse för den hårdvara som definierats i avgränsningen eftersom det är på denna som experimenten kommer ske. Vi visar (Kapitel 5) i detalj hur experimenten utförs (vilken kod som används), vilket innebär att samma experiment skulle gå enkelt att utföra på annan hårdvara. 5

10 3 Teknisk bakgrund Det är processorn som utför instruktioner i en dator och vi associerar den ofta till hjärnan i datorn. Här refererar vi till processorer som CPU (Central Processing Unit). CPU:n är designat för kontroll av data flöde och det är processorn som i normala fall utför beräkningar på datorn. Cacheminne ligger fysiskt på processor chippet, cacheminnet är relativt litet men snabbt att skriva och läsa till. RAM (Random Access Memory) minnet lagrar kör data och är mycket större än cacheminnet. RAM är samman kopplat till processorn via något gränssnitt i detta fall Intel s Quick path [1]. Processordelen som utför aritmetiska instruktioner och beräkningar förkorttas ALU (Aithmetichal Logical Unit). Intel i7 Processorn lägger mer vikt på cacheminnet än på ALU. Anledningen till att detta är bl.a. att det minskar trafik på quickpath och efterdröjning mellan CPU och RAM. [27] 3.1 Parallellism Vi associerar antagligen parallellt med någonting enkelt som t.ex. två räta linjer som inte korsar varandra, på sätt och viss är två parallella program två linjer som inte korsar varandra. Dessa två linjer är tillåtna att kommunicera, och även dela data under förutsättning att de inte korsar varandra. Detta känns naturligt eftersom t.ex. två program inte kan samtidigt finnas på identiska adresser i RAM minnet och vara olika. Amdhals lag beräknar hur mycket snabbare en applikation blir ifall källkoden parallelliseras. S nabbarekod = 1 F + (1 F ) N (1) Andel av koden som inte går att parallellisera betecknas som F. Ett illustrerande exempel på detta är i fallet vi uppnår 50 procent parallellism då tilldelas F värdet 0.5. Variabeln N beskriver antalet kärnor som används. Vi måste ha en kärna för att exekvera applikationen. Om det finns 10 parallella kärnor tilldelas N värdet 10. Med dessa variabeltilldelningar så erhåller vi följande värden. S nabbarekod = = En applikation som är nästan två gånger snabbare p.g.a. parallellism kan verka som mycket men vi inser snabbt att med ett lägre F och större N kan det bli betydligt mer. Testar vi olika värden med Amdhals lag ser vi snabbt att antalet trådar och andel parallelliserad kod samverkar och att det är oerhört viktigt att ha en stor 6

11 andel av koden parallelliserad (litet värde på F ). Följande bild visar en kontroll i ett program som skulle vara helt meningslös att köra i parellallism. Figur 1: Kontroll av födelsedatum Det finns ingen mening i att försöka uppnå parallellism vid inmatning av t.ex. födelsedatum från en användare. Även Ifall vi uppnår en parallellism på 100 procent så är det meningslöst. Problemet är inte av den typ vi kan bemöta med parallell databehandling eftersom det inte finns data att behandla parallellt.[2] Denna studie använder parallellism på CPU:n med OpenMP API:et som redan finns tillgängligt i kompilatorn, men vi måste aktivera användning av OpenMP i kompilatorn [44]. I denna studie refereras till parallell exekvering på CPU:n som CPU/P och seriell som CPU/S. Trådsynkroniseringen i denna studie är av typen nowait vilket innebär att trådar exekverar samtidigt, detta konfigureras genom att inte ge OpenMP s.k. direktiv klamrar [31]. 3.2 HyperThreading och speedup Intel processorer levereras med en teknologi som heter HyperThreading (HT). I vårt fall har vi inte 8 processor kärnor trots att operativsystemet tror att vi har det. Denna hårdvara har 4 riktiga och 4 emulerade kärnor för prestanda d.v.s. finns 2 emulerade processor trådar per varje en riktig kärna. [15] Figur 2: Operativsystemets uppfattning av antalet processor kärnor på CPU:n 7

12 Men ur operativsystemets perspektiv har vi 8 stycken kärnor. Detta är betydelsefullt så att vi vet vilka variabelvärden att använda i Amdahls formel när vi försöker förutse hur mycket snabbare mjukvara blir på processorn. Om vi lyckas uppnå 100 procent parallellism kommer programmen inte bli 8 gånger snabbare men de kan bli snabbare än 4 gånger beroende på hur mycket HT som kan tillämpas. Processorn som används i studien har ytterligare en teknologi vi måste förstå som heter SpeedUP och möjliggör att processorn vid intensiva arbete kan öka frekvensen upp t.o.m. 3.10GHZ från de ursprungliga 2.20GHZ. [14] [16] 3.3 Grafikkort Det är grafikkortets uppgift att skapa och visa bilder på skärmen. Ett modernt grafikkort kopplas till datorns moderkort genom gränssnittet PCI-E 2 (Peripheral Component Interconnect Express 2) [45]. Det finns grafikkort som använder andra gränssnitt men här har vi ett separerat grafikkort kopplat via PCI-E 2 [37]. 3.4 GPU Här refererar vi till grafikkortets processor Graphical Processing Unit som GPU. Till skillnad från CPU är GPU dedikerat åt parallella databeräkningar. En GPU består av många multi cores, kärnor på svenska som exekverar parallellt kod. Varje multicore har bland annat 8 CUDA cores vi har 18 multicores med denna hårdvara eftersom denna hårdvara har 144 CUDA cores. GPU:n har sitt eget cacheminne på chippet. [39] 3.5 Grafikkortets minne Ett grafikkort har sitt eget RAM-minne separerat från RAM-minnet på moderkortet. RAM-minnet lagrar data av olika typer som t.ex. färdigställda bilder, positioner på skärmen etc. De flesta grafikkort som lanseras idag har över 1024 Megabyte RAM minne [23]. På GT550M kortet är gränssnittet mellan GPU och grafikkortets RAM 28.8GB/sec [37]. Bandbredden på PCIE 2 interfacet ligger på 8GB/s [45], av bl.a. denna anledning är det eftersträvat att hålla data så länge som möjligt på grafikkortet och undvika kommunikation mellan CPU:n och GPU:n även om det inte finns någon kortsiktig prestanda-vinst på att utföra subrutiner på GPU:n. Det finns fler typer av minne på ett GT550M kort, cacheminne är det minnet som ligger på GPU:n och är extremt snabbt, cacheminne är dock extremt lite tillgängligt precis som på CPU:n. [35] [21] 3.6 Grafikkortet till generella beräkningar Det finns olika alternativ till att programmera grafikkort att utföra mer generella uppgifter än multimedia, dessa uppgifter kan vara helt orelaterade till grafik. De tre dominerande alternativen är Nvidias CUDA, OpenCL och Microsofts Directcompute 8

13 [20]. Här väljer vi Nvidia CUDA teknologin p.g.a. allt material som erbjuds av Nvidia och lätt tillgängligheten av GPU som stödjer CUDA samt hårdvaran på systemet som används. Nvidia har inte exkluderat användning av OpenCL och Directcompute på deras hårdvara [19]. CUDA förkortat för Compute Unified Device Architecture och är Nvidias modell till att använda GPU:s och integrerade komponenter till icke grafiska operationer. CUDA kräver ingen licens och kostar ingenting. CUDA började lanseras år 2007 tillsammans med Nvidia 8 serien och har levererats med över 100 miljoner GPU enheter [21]. Ett externt grafikkort med CUDA kan idag kosta mellan några hundra kronor och flera tusen enligt priser på webbsidan [22]. Förutom ett Nvidia grafikkort med CUDA stöd behövs inga andra specifika hårdvara komponenter för att använda CUDA. Priset och Nvidias marknads andelar gör att CUDA teknologi är lättillgänglig. CUDA C/C++ är en utvidgad version av programmerings språket C och är standard språket som används till att programmera GPU enheter som stödjer CUDA. [32]. Det finns även tredjeparts tillägg som möjliggör att Cuda används med programmerings språk så som JAVA SE, C# [17], i denna studie används enbart CUDA C/C Standard template library STL (Standard Template Library) är ett bibliotek som tillhör C++ standardbiblioteket och erbjuder många algoritmer, datastrukturer, klasser etc. som ofta återanvänds. STL är ett generiskt bibliotek vilket innebär att det är skrivet på ett sätt att vi kan använda samma kod med olika datatyper. [51] 3.8 Binärsökning Binär sökning är ett sätt att söka igenom en sorterad lista genom att halvera listan vid varje försök. Om vi har 1 miljon sorterade element i en lista och ska hitta just ett element kommer listan att halveras vid varje försök. Exempelvis om talet 77 ska hittas hade sökningen börjat på element och undersökt om elementet är större än eller mindre än 77. Om talet är större jämförs annars etc. Komplexiteten för en sådan sökning är O(logN) där den sökta listans längd är N. Vanligen är komplexiteten i vårt fall 6 sökningar men i bästa fall O(1) om talet hittas just i mitten. Det finns en funktion i STL för binärsökning på vektorer. [5], [30] 3.9 Sortering Det finns olika algoritmer i datavetenskap att sortera data med, i olika situationer kan vissa algoritmer vara bättre val än andra då de erbjuder t.ex. stabilitet eller snabbhet. I denna studie används sorteringsfunktioner från STL (sort respektive stable_sort). Sort har en vanlig komplexitet på NlogN och i värsta fall N 2, stable_sort har en komplexitet mellan NlogN och N(logN 2 ). [47],[6], [7] 9

14 3.10 Vektorinventering Vektor inventering betyder att vektorn vänder på sina element eller en del av dem. Om vektor A innehåller elementen 1, 3, 4, 5, 7 skulle vektor A inventerat bli 7, 5, 4, 3, 1. Det finns en funktion för detta i STL och den har en linjär komplexitet O(N). [8], [47] 3.11 Matrismultiplikation Matriser används mycket i datavetenskap t.ex. i bildbehandling och beräkningar i rummet. I denna studie behandlas tvådimensionella matriser de multipliceras med varandra på CPU:n och GPU:n och resultaten jämförs. Om vi har två matriser A och B och vill multiplicera dem med varandra måste vi kontrollera att A har lika många kolumner som B har rader. Om C är resultatet av AB så gäller för C följande C i,j = A i,1 B 1,j + A i,2 B 2,j A i,n B n,j = Där i anger rader och j kolumner. Ett exempel: A = ( ) 1 2, B = 3 4 ( ) C = AB ( ) ((1 0) + (2 2)) ((1 5) + (2 6)) C = = ((3 0) + (4 2)) ((3 5) + (4 6)) n A i,r B r,j (2) r=1 ( ) [48] Dessa matriser är dense matriser eftersom de innehåller data i majoriteten av elementen. Alternativet är sparse matriser som innehåller majoriteten nollor [10]. I denna studie behandlar vi endast dense matriser. Komplexiteten för matrismultiplikation av nxn storlek är O(N 3 ) [52] Eigen Matrismultiplikation verkar som en enkel uppgift att implementera i t.ex. C/C++. Allt vi behöver är tre iterationer, problemet med denna retorik är att matrismultiplikation (likt mycket annat) kräver en hel del hänsyn och djup förståelse till minne för att vara optimerat på hårdvaran som används. Det finns detaljerad text om själva optimeringen av Drepper [50]. Eftersom de matrisoperationer som behandlas i experiment här är återkommande och vanliga använder vi existerande, optimerade bibliotek. Vi väljer att använda Eigen biblioteket till CPU program (Publicerat med GNU free document license) p.g.a. erhållen prestanda mätning av matris-matris multiplikation på projektets sida. Eigen är enkelt att implementera och använda, för att implementera Eigen inkluderas relevanta filer (C++). [9] 10

15 4 Fördjupning i Nvidia CUDA Vi går kort igenom CUDA i detta introducerande avsnitt, för detaljer rekommenderas litteraturen som används här. För att kunna utveckla i CUDA hämtas och installeras först nödvändiga komponenter (SDK, drivrutiner och toolkit) som finns tillgängliga kostnadsfritt på Nvidias hemsida [42]. Det medföljer vissa filer som hjälper oss att snabbt komma igång med CUDA. [39],[35],[36] I denna studie används Visual studio 10 Ultimate Edition som kompilator. För att separera CPU och GPU kod inbäddas en såkallad Nvidia C Compiler (nvcc) i utvecklings miljön. Källkod som används av GPU:n levereras i PTX format. Kompilatorn vet om att den ska använda CUDA p.g.a. fil ändelsen till CUDA filer är *.cu. CUDA är designat att tillåta skalbarhet utan att utvecklare oroar sig för hur samma kod skall exekvera på olika GPU. Detta fungerar därför att Nvidia C kompilatorn levererar kod i PTX som kompileras vid kör tid. [33] 4.1 CUDA C/C++ Nvidia utvecklar CUDA C/C++ (Oftast kallat CUDA C) som ett utbrett språk till programmering språket C med minimalt nödvändig utveckling. Syntaxen är samma som C++ och går att (som med vanlig C kod) blanda med C++ källkod. [18] 4.2 Minneshantering i CUDA Vi måste med CUDA allokera respektive deallokera grafikkorts-minne men även skicka minne fram och tillbaka mellan CPU:n och GPU:n eftersom grafikkort inte kan hantera sitt eget minne. Vi allokerar och deallokerar minne med specifika instruktioner till CUDA C/C++ i denna studie. [35] Enligt bl.a. tidigare studie av Langdon [26] är det viktigt att undvika data-kommunikation till och från GPU:n p.g.a att detta är en tidskrävande operation. Ifall problem som går att bemöta med GPU:n (parallella problem) är databeroende (filer på t.ex. hårddisken) kan de behandlas relativt snabbt p.g.a. GPU:ns parallella struktur. Men det blir svårt att konstant skicka in data ifall problemet inte är datarikt. 4.3 Kernel i CUDA I detta sammanhang är funktioner som anropas från CPU men exekveras på GPU benämnda Kernels. Endast en Kernel exekveras åt gången i experiment här. Anrop till Kernel är asynkrona och återlämnar kontroll till CPU:n efter några mikrosekunder detta är viktigt att förstå vid tidtagning. En Kernel börjar först exekvera när föregående CUDA operationer är färdiga (med vårt system). Vid en exekvering av en Kernel i CUDA C definieras antal trådar, blocks, grids där dessa tre är relaterade till problemets storlek, vid användning av bibliotek är detta inte nödvändigt. [39] 11

16 4.4 Parallellism i CUDA CUDA exekveras som en SIMT (Single Instruction Multiple Thread) arkitektur vilket innebär att Kernel/s körs som lättviktstrådar (många trådar körs åt gången och är lättvikts trådar (kan skapas och förstöras fort ) av en instruktion från CPU:n. Alla trådar kör samma Kernel kod, trådar har sitt eget ID för att separera dem från varandra. Trådar är grupperade i olika tråd-block. Trådar kan kommunicera med andra trådar i samma tråd-block genom delat minne, trådar i samma tråd-block kan synkronisera exekvering. Trådar kan inte kommunicera med trådar i andra tråd-block på vår hårdvara. [39] Synkrona och asynkrona CUDA exekveringar CUDA exekveringar är asynkrona detta innebär att kontrollen återgår direkt till CPU tråden som kallade på CUDA operationen. Detta är problematiskt om vi ska ta tiden med CPU tråden eftersom tiden som visas kommer inte vara tiden för själva CUDA operationen att exekvera utan endast tiden att ge GPU:n instruktioner. För att undvika detta följs teorin i Cuda C programming Guide [38] som säger att vi ska synkronisera CPU-tråden med CUDA exekveringen vid tidtagning. Detta gör vi under alla experiment även om vi inte påpekar det. Listing 1: Synkronisering av CPU och GPU 1 cudathreadsynchronize(); [38] 4.5 Accelererade bibliotek och THRUST Det finns en mängd accelererade bibliotek till CUDA C/C++ som möjliggör programmerare att förbipassera lågnivåprogrammering i CUDA C/C++ inom områden som t.ex. matematik, strömningsmekanik, bild bearbetning m.fl. genom att använda dessa vältestade lösningar kan programmerare flytta fokus till resten av programvaran. En del av dessa accelererade bibliotek finns på Nvidia s hemsida. Många är gratis men en del kostar (vissa ges ut i begränsade utgåvor utan betalning t.ex. CULA) THRUST Vi använder ett CUDA bibliotek som heter THRUST och försöker efterlikna C++ biblioteket Standard Template Library (STL). THRUST är inkluderat i Nvidia CUDA 4.0 och nyare versioner. För att implementera THRUST funktioner i vår källkod används inkludera direktivet (med relevanta instruktioner) likadant som med STL. För att anropa THRUST funktioner skriver vi thrust som namnrymd istället för t.ex. std. [12] Sorterings funktioner som THRUST använder har en komplexitet på O(nlogn) när mergesort används och O(n) när radix sortering används. THURST väljer radix 12

17 sortering vid inbyggda data-typer (float, int) och mergesort när radix sort inte kan användas. [28], [46]. Att implementera egna sorteringsalgoritmer är utanför omfattningen av denna studie men det finns en intressant artikel av Assarsson och Sintorn [3] som visar ett sätt att implementera sortering med CUDA och resultat av implementationen. Vi använder även THRUST till vektor inventering och binärsökning på GPU:n, det finns fullt stöd för dessa operationer [12] CUBLAS För matris-matris operationer använder vi här CUBLAS som står för Cuda Basic Linear Algebra Subprograms. Problemet med att skriva egna GPU applikationer (Kernels) som utför matris-matris beräkningar är optimeringen av dem. Om vi skriver egna matris-matrismultiplikationer är det även redundant eftersom det är ett standard problem som är återkommande i datavetenskap. Även om vi inte behöver lika ingående kunskaper för CUBLAS som vi hade (För att utföra matris-matris applikationer) i CUDA C/C++ är det viktigt att förstå grunderna inom t.ex. GPUstruktur, minneshantering, trådar, Kernels (synkronisering etc) för att kunna få korrekta värden och dra rätt slutsatser. Nvidia skriver att de i tester fått upp till 7 gånger snabbare prestanda än CPU/P med Intels MKL (Math Kernel Library) bibliotek som är ett ej kostnadsfritt, proprietär bibliotek[40] [41]. Prestandamätning på Eigens hemsida visar att den nya versionen (3.0.0) har liknande prestanda vid matris-matris multiplikation som Intels MKL. [9] 13

18 5 Experiment I denna studie utförs två sorters experiment. Det första experimentet handlar om vektorer och sortering, binärsökning, vektorinventering av dessa. Det andra experimentet handlar om matrismultiplikation. Först skrivs program som behandlar stora mängder individuella dataelement från ett exakt antal filer på hårddisken (8). Vi applicerar teorin praktiskt och samlar mätdata att analysera. Att behandla stora datamängder (bestående av många individuella element) är ett problem som går att parallellisera och bemöta med det accelererade biblioteket THRUST och C++ biblioteket STL. Precis 8 filer behandlas vilket ger CPU:n bästa möjlighet att uppnå maximal parallellism eftersom STL algoritmerna är sekventiella exekverade på 4 parallella kärnor (8 emulerade trådar). Ur detta perspektiv uppnås hundra procent parallellism jämfört med de ursprungliga seriella programmen. Matrismultiplikation program är den andra delen av experimenten. Slumpmässiga matriser genereras lokalt på processorns RAM minne och GPU:ns GDRAM minne. Matriser som behandlas är kvadratiska i stigande ordning (2, 16, 128, 256, 512, 2048, 4096). Det är viktigt att mäta tiden på ett korrekt sätt som teorin påpekar. För att ta högupplöst tidmätning används windows QueryPerformanceCounter [29] i samtliga experiment. t = (t klockaefter t klockaföre ) (3) Tiden för exekvering av en operation får vi med formeln ovan praktiskt implementerad. Variabeln t klockaföre anger vi värdet 0 vid tidmätningen. För att minimera felkällor kontrollerar vi i aktivitetshanteraren att alla systemresurser som kan påverkas allokeras åt experimenten. Med de parallella programmen används prestanda fliken i aktivitetshanteraren för att verifiera att samtliga 8 trådar och 4 kärnor allokeras till vårt exekverade program. Figur 3: Bilden visar aktivitetshanteraren vid exekvering av den parallella delen av CPU vektorprogrammet. 14

19 Figur 4: Bilden visar antalet trådar som används vid exekvering av CPU vektorprogrammet i underfönstret systemresurser. Average CPU har inte värdet men detta är inte ett problem eftersom värdet gäller även tiden för applikationen att köra igång, läsa in filerna vi genererat samt skriva ut data till ett cmd fönster. Figur 5: Bilden visar ströminställningen som används. Bilden med ströminställningar visar att vi väljer hög prestanda inställningen vilket gör att CPU:n får spendera mer ström. CPU:n ökar frekvensen (speedup) och valet gör vi får maximal tillgänglig prestanda. I samtliga experiment i denna studie används samma inställning. 5.1 Vektorgeneratorn Vi skriver en generator som skapar olikt stora fält fyllda med slumpdata. Generatorn skapar ett fördefinierat antal N fält av datatypen flyttal (float), i detta experiment 8 st. Fälten fylls med fördefinierat antal slumptal M med radbrytning mellan dem, inom denna studie 1024, 16384, en miljon och fem miljoner element. Exempel på dessa tal ur en fil är 5.411, , På fälten utförs olika vektoroperationer med THRUST och STL. 15

20 Figur 6: Flödesschema på programmet som skriver ut stora fält fyllda med slumpmässiga flyttal till filer på hårddisken. Genom att definiera N som 8 får vi en fil/processor tråd. 5.2 Struktur på vektorhanterings program CPU-seriella och CPU-parallella vektorhantering programmen beskrivs översiktligt av flödesschemat under. 16

21 Figur 7: Bilden visar översiktligt algoritmen som används till CPU vektor programmen. Start är början på subrutinen som hanterar filerna som genereras. Filerna läses in till vars en individuell vektor. CPU operationer bearbetar (binärsöker, inventerar och sorterar) vektorerna. Vid varje vektor händelse tas tiden och lagras i en separatt vektor s.k. timetoabc på detta sätt har vektorn timetoabc tider vi är intresserade av. Vid varje iteration sker dessa operationer på varje fil som läses in till en vektor. För att veta tiden som något behöver att exekveras parallellt på CPU:n tas ur klocka vektorn det största elementet. Alla andra mätningar måste ha avslutats innan därför ger största elementet totala tiden för hela vektoroperationen i parallella CPU subrutiner. Listing 2: Vektor operationer vector<float> timetoabc(numberoffiles); for(int f=0; f<numberoffiles; f++){ take_time tn;.... vektoroperation pa CPU. timerto = tn.get_time(); timetoabc.push_back(timerto); } Med GPU:n måste vi enligt teorin skicka data till och från grafikkortet manuellt. Vi måste även synkronisera GPU:n med CPU:n vid tidtagning på en GPU händelse med en CPU klocka, för att ta korrekt tid. 17

22 Figur 8: Bilden visar översiktligt algoritmen som används till GPU vektor programmen. Listing 3: Skicka data till GPU cudathreadsynchronize(); take_time t0; thrust::device_vector<float> gpuvector=cpuvector; cudathreadsynchronize(); timertosend= t0.get_time(); TimeToSendDataToDevice.push_back(timerToSend); Vi tar inte hänsyn till hur CPU:n ska allokera resurser på GPU:n när THRUST används. Men vi måste säga till GPU:n vilken grafikkorts vektor vi menar d.v.s. måste vi sköta minneshantering men vi måste inte gå in på detaljer med trådar, trådblock etc. Vi allokerar och skickar data till en vektor på GPU:n med THRUST genom ett lika med tecken mellan GPU vektorn och CPU vektorn. Detta fungerar eftersom THRUST är programmerat att vara kompatibelt med STL. 18

23 Listing 4: Hämta data från GPU cudathreadsynchronize(); take_time t4; thrust::copy(gpuvector.begin(), gpuvector.end(), cpuvector.begin()); cudathreadsynchronize(); timerto4 = t4.get_time(); TimeToReciveDataFromDevice.push_back(timerTo4); För att hämta tillbaka vektorn till CPU:n (för att kunna läsa vektorn) måste vi ange tre parametrar till THRUST copy funktionen. Dessa tre parametrar är början på vektorn vi vill skicka, slutet och början på CPU vektorn som ska ta emot innehållet. 5.3 Parallellt på CPU med OpenMP De parallella implementationerna av CPU programmen är inkapslade av en nowait OpenMP deklaration på detta sätt exekveras alla trådar samtidigt. I övrigt ser de parallella delarna av CPU programmen ut på samma sätt som de seriella därför behöver vi inte separat beskriva de olika vektor-operationerna för de parallella och seriella programmen. Listing 5: Parallellt på CPU med OpenMP #define NumberOfFiles 8.. char startname = a ; omp_set_num_threads(numberoffiles); #pragma omp parallel for shared(startname) for(int j=0; j<numberoffiles; j++){... } Koden ovan visar att NumberOfFiles definieras till 8 (vi har 8 emulerade kärnor). Denna tilldelning används som parameter till antalet trådar som ska användas vid OpenMP direktivet. For loopen inkapslas av ett OpenMP direktiv där argumentet startname används för att skilja de olika trådarna åt. Bokstäverna a och b är enda skillnaden i namnet på den första och andra filen vi läser in. 5.4 Sortering med THRUST och STL För att sortera de slumpmässiga elementen används STL sorterings funktion och THRUST motsvarighet på GPU:n. Listorna sorteras till stigande ordning, vektorn som sorterings funktionen returnerar har tal från minsta till högsta ordning istället för den tidigare slumpmässiga ordningen. 19

24 Listing 6: Sortering på CPU STL s sort take_time t1; std::sort(veccpu.begin(), veccpu.end()); timerto = t1.get_time(); timetosort.push_back(timerto); Koden ovan skickar argument till sorterings funktionen som början på en vektor (veccpu) och slutet på en vektor. För att sortera på GPU:n kan vi använda THRUST på liknande sätt. Klocka vektorn heter timerto. Listing 7: Sortering på GPU med THRUST cudathreadsynchronize(); take_time t1; thrust::sort(gpuvector.begin(), gpuvector.end()); cudathreadsynchronize(); timerto = t1.get_time(); timetosort.push_back(timerto); i koden ovan implementerar vi THRUST sortering på en osorterad vektor gpuvec. För att få korrekt resultat på tidtagningen är det viktigt att vi som teorin föreslår synkroniserar GPU med CPU vid tidtagning. Om vi inte gör detta kommer vi att ta tiden CPU:n behöver för att skicka instruktioner till GPU:n och sedan fortsätta ner i koden detta tar inte alls lika lång tid. 5.5 Binärsökning med THRUST och STL Vi kontrollerar ifall ett element ( ) finns i sorterade vektorn cpuvec respektive gpuvec med binärsökning. Men binärsökningen sker på en redan sorterad vektor (sorterad i förra avsnittet). Listing 8: Binär sökning på CPU med STL take_time t2; bool findval = std::binary_search(veccpu.begin(), veccpu.end(), ); timerto = t2.get_time(); timetobinarysearch.push_back(timerto); Om flyttalet hittas i vektorn kommer variabeln findval få värdet 1 annars 0. Argumenten vi skickar in beskriver var sökningen ska börja, sluta och vilket tal vi letar efter. Listing 9: Binär sökning på GPU med THRUST cudathreadsynchronize(); take_time t2; bool findval = thrust::binary_search(gpuvector.begin(), gpuvector.end(), ); cudathreadsynchronize(); timerto2 = t2.get_time(); timetobinarysearch.push_back(timerto2); 20

25 På GPU sidan anropar vi funktionen binary_search i thrust med samma typ argument. Som vi ser är det relativt enkelt att implementera binärsökning med THRUST. 5.6 Vektorinventering med THRUST och STL Vektor inventering med STL på CPU:n implementeras med följande kod. Listing 10: Vektor inventering med STL på CPU take_time t3; std::reverse(veccpu.begin(), veccpu.end()); timerto = t3.get_time(); timetoreversevector.push_back(timerto); Nu är vektorn returnerad i omvänd ordning med hjälp av CPU:n och tid är tagen på detta. På GPU sidan kan vi till använda THRUST igen. Listing 11: Vektorinventering på GPU med thrust cudathreadsynchronize(); take_time t3; thrust::reverse(gpuvector.begin(), gpuvector.end()); cudathreadsynchronize(); timerto3 = t3.get_time(); timetovectorreverse.push_back(timerto3); 5.7 Matrismultiplikation av kvadratiska matriser Den andra delen av experimenten handlar om matrismultiplikation. Denna del är oberoende av vektorhanterings programmen. Vi genererar matriser i en stigande ordning, matriserna innehåller slumpmässiga flyttal. Två matriser A och B multipliceras till C biblioteken CUBLAS och Eigen används på GPU:n respektive CPU:n Matrismultiplikation på CPU Matrismultiplikation på CPU utförs parallellt och seriellt. Listing 12: MatrisMultiplikation på CPU:n med Eigen #include "Eigen\Dense" using Eigen::MatrixXd;... const int size = 256; MatrixXd a(size,size); MatrixXd b(size,size);... //fyll a och b med slumpdata... MatrixXd res(size,size); omp_set_num_threads(8); res = a*b; 21

26 Vårt parallella CPU program har en OpenMP deklaration omp_set_num_threads(8). Den seriella versionen är identisk fast saknar OpenMP deklarationen. Matriserna vi multiplicerar är a och b, resultatet lagras i matrisen res. Vi tar tid på matrismultiplikationen genom att ta tiden innan och efter. Matris storleken ändras för att ta fram olika mätdata och varje ändring skiljs åt med Test ID Matrismultiplikation på GPU med CUBLAS Vi använder i denna studie biblioteket CUBLAS för matrismultiplikationer på GPU. CUBLAS ger oss kvalitativ kod på vår GPU. Precis som innan synkroniserar vi CPU med GPU vid tidtagning för att få korrekta mätdata. Till matrismultiplikation använder vi CUDA C mer tydligt. Vi måste allokera minne på grafikkortet det gör vi nu med cudamalloc. Vi måste kopiera den slumpmässiga datan till grafikkortet det gör vi med cudamemcpy. Listing 13: Allokera och skicka data till GPU:n cudamalloc((void**) &devicea, memorysizea); cudamalloc((void**) &deviceb, memorysizeb); cudamalloc((void**) &devicec, memorysizec); cudamemcpy(devicea, hosta, memorysizea, cudamemcpyhosttodevice) ; cudamemcpy(deviceb, hostb, memorysizeb, cudamemcpyhosttodevice) ; Hur mycket att allokera (memmorysize) räknar vi ut genom att multiplicera höjden och bredden för matriserna och sedan multiplicera resultatet med storleken av flyttal. Vi behöver inte skicka devicec till grafikkortet eftersom den är tom. Vi genererar två matriser separat (hosta, hostb) fyllda med slumpdata på CPU:n. Den slumpmässiga datan kopieras till grafikkortet (devicea resp B) med cuda- Memcpy funktionen. Listing 14: MatrisMultiplikation på GPU:n med CUBLAS.. cublassgemm(handle, CUBLAS_OP_N, CUBLAS_OP_N, m, n, k, &alpha, deviceb, m, devicea, k, &beta, devicec, k); Funktionen cublassgem utför en matris-matris operation och matrisen C som skapas blir C = αop(a)op(b) + βc (4) CublasSgem är funktionen i CUBLAS som används för single-precision matrismultiplikation på GPU:n och är förkortat för singleprecision general matrix multiply. Där single innebär att innehållet är i 32bitar (4byte) [49]. Vi måste ange en del argument till funktionen. Exakta API definitionen av dessa finns definerade i Nvidia dokumentet CUDAToolkit 4.1 CUBLAS Library [40]. Den första parametern handle är en pekare till CUBLAS bibliotekets kontext. 22

27 Kontexten handlar om b.la. vilken GPU som CUBLAS ska exekveras på och på vilken CPU-tråd i en multitråd applikation (samtliga CUBLAS funktioner behöver en handle och denna skapas med cublascreate() funktionen). Andra och tredje parametern säger att vi inte ska utföra transponent matris operationer därför kommer op(a) och op(b) att kvarstå som A resp B. m anger antal rader matris A och C har. n anger antal kolumner matris B och C har. Det andra m anger antal kolumner Matris A har och antal rader matris B har. Alpha är skalären till matris A i detta fall 1. deviceb pekar mot minnet vi allokerar för B. m är första indexet i matris B. devicea pekar mot minnet vi allokerar för A. k efter devicea är första index i matris A. Beta är en skalär som används till multiplikationen. Om Beta är noll är C inte valid input (vilket den inte är i vårt fall). devicec lagrar resultatet av matrismultiplikationen. Sista k är första index i devicec matrisen. Nu är matrismultiplikationen färdig men vi måste utföra några steg till innan experimentet är färdigt. Listing 15: Skicka tillbaka data till CPU cudamemcpy(host_res, devicec, memorysizec, cudamemcpydevicetohost); Nu kopieras resultatet av matrismultiplikationen från devicec till host_res på CPU:n därför används devicetohost som den sista parametern i cudamemcpy funktionen. Slutligen släpps allokerar minne fritt med free (CPU) funktionen och cudafree (GPU) funktionen. Med denna kod utför vi matrismultiplikationen på GPU och antecknar mätdata. 23

28 6 Diskussion Mätdata från experimenten analyseras här. Mätdata presenteras med hjälp av tabeller och stapeldiagram. Olika experiment skiljs åt av kolumnen Test ID. Fullständig mätdata finns bifogade som appendix A resp B. 6.1 Analys av vektor program Det är viktigt att vi är medvetna om att parallella CPU vektorprogrammen har fått en maximal parallellism (inget är seriellt) p.g.a. tekniska implementationen. Om algoritmen som utför t.ex. sortering parallelliserats hade detta inte nödvändigtvis varit fallet då en del av koden kanske inte går att utföra parallellt. S nabbarekod = (1 0) 4 = 4 (5) CPU vektorprogrammen bör bli ungefär 4 gånger snabbare där HT inte kan användas. Om experiment visar att parallella CPU programmen är mer än 4 gånger snabbare beror det troligtvis på användning av HT teknologi enligt teorin. Hårdvaran i denna studie har endast 4 riktiga kärnor. Tabeller här innehåller mätdata från experimenten med vektorhanteringsprogrammen på CPU:n respektive GPU:n. Varje vektor-experiment involverar 8 filer seriellt på CPU:n, parallellt på CPU:n och på GPU:n. Vektorer sorteras med 1024, 16384, en miljon och 5 miljoner element. Genom att börja med små vektorer och sen öka i storlek observerar vi hur mycket operationer blir snabbare på GPU:n beroende på hur mycket data som skickas in. Vi letar efter en ungefärlig nedre gräns på antal data-element som behövs skickas in till GPU:n för att få snabbare programvara jämfört med CPU programmen. Tabell 6, 7, 8 i appendix A innehåller mätdata för experimenten med CPU/S, CPU/P och GPU vektorprogrammen. Mätdata i tabell 8 gäller THRUST funktioner på GPU:n exkluderat tiden att skicka data till och från GPU:n. Tiden för minneshantering behandlas i tabell 9. Genom att dividera värden från tabell 6, 7, 8 räknar vi ut antalet gånger GPU:n, CPU/P blev snabbare än CPU/S. Resultat av divisionen finns i tabell 3 detta resultat är inte räknat med tiden att skicka data fram och tillbaka till GPU:n. 24

29 Tabell 3: Resultat för olika vektorhanterings subrutiner exkluderat tiden att skicka data till och från grafikkortet, x betyder antal gånger snabbare. CPU/P vs CPU/S GPU vs CPU/S GPU vs CPU/P Operation Storlek Test ID 6.4x 1.078x 0.168x Sortering , 5, x x x Sortering (16384) 2, 6, x x x Sortering , 7, x x x Sortering 5(10 6 ) 4, 8, x 1.366x x Stabil sort , 5, x x 4.795x Stabil sort (16384) 2, 6, x x 52.69x Stabil sort , 7, x x x Stabil sort 5(10 6 ) 4, 8, x x x Vektor inv , 5, x x 3.406x Vektor inv (16384) 2, 6, x x 8.741x Vektor inv , 7, x x x Vektor inv 5(10 6 ) 4, 8, x 0.013x x Binärsök , 5, x 0.013x x Binärsök (16384) 2, 8, 10 5x 0.013x 0.002x Binärsök , 7, x 0.014x 0.003x Binärsök 5(10 6 ) 4, 8, 12 Genom att dividera tidsåtgången för tiden på de olika operationerna i tabellerna i appendix A (6 7 och 8) individuellt har vi fått fram ovanstående tabell. Kolumnen Test ID visar här vilka Test ID som divideras. Amdhals lag förutspår väl hur mycket CPU/P programmen blir snabbare än CPU/S programmen när större mängder data behandlas. Men underskattar antalet gånger koden blir snabbare på de små datamängderna vid sortering och stabil sortering. Detta kan vara fallet eftersom HT kommer in i spel vid de små datamängderna. Vektor inventering verkar bete sig mer parallellt vid större vektorer och väldigt dåligt vid små storlekar kan det bero på för små problem d.v.s. tar tiden för OpenMP biblioteket att allokera resurser längre än själva problemlösningen. Binärsökning verkar inte gå att behandla snabbt på GPU:n med THRUST. Men eftersom data tar relativt lång tid att skicka mellan GPU:n och CPU:n (se tabell 9) och tiden att binärsöka är kort är det bra att funktionen är tillgänglig med THRUST på GPU:n. Som vi ser i resultat tabellen (se tabell 3) har vi snabbare kod med THRUST på sorteringen parallellt först när vi använder vektorer som har ca 16 tusen element. Någonstans mellan 1024 och 16 tusen element finns det en gräns där GPU:n blir mer fördelaktig att använda än de parallella CPU programmen. Problemet är att även om GPU:n blir fördelaktig att utföra operationer på måste vi skicka data fram och tillbaka till GPU:n och den tiden är inte inkluderad i tabellen. Detaljerad tid för att skicka data till och från grafikkortet i vektoroperationerna finns i tabell 9 i appendix A. När vi matar in mer data till sorteringsoperationen ser vi att GPU:n blir bättre på 25