Effektivitetsmätning av multitrådning på ARM Cortex-A53 mikroarkitektur

Transkript

1 Lunds universitet Effektivitetsmätning av multitrådning på ARM Cortex-A53 mikroarkitektur Johan Hermansson EITF60 Kursansvarig: Erik Larsson 4 december 2017 Sammanfattning I projektet utvecklades multitrådad programvara samt icke trådad programvara. Sedan utfördes effektivitetsmätningar i form hur lång exekveringstid de olika versionerna behövde för att lösa det givna problemet på ARM Cortex-A53 mikroarkitekturen.

2 INNEHÅLL INNEHÅLL Innehåll 1 Syfte 2 2 Arkitekturen 3 3 Teori Multitrådning och pipelineing Kontextbyte Utförande 7 5 Resultat 8 6 Diskussion 10 7 Slutsats 11 8 Referenser 12 9 APPENDIX 13 A Information om ARM Coretex-A53 CPU 13 1

3 1 SYFTE 1 Syfte Syftet med projektet är att undersöka hur väl ARM Cortex-A53 arkitekturen lämpar sig till parallell exekvering i form av POSIX-trådar samt ge förståelse för hur trådarna är kopplade till dess pipeline. Genom att utföra praktiska tester är målet att kunna ge ett mått på eventuella prestandavinster vid exekvering av trådad programvara gentemot icke trådad programvara på den ovan nämnda arkitekturen samt att undersöka och försöka påvisa varför det inte alltid är lämpligt eller möjligt att all programvara exekveras parallellt. 2

4 2 ARKITEKTUREN 2 Arkitekturen ARM Cortex-A53 är en superskalär processor som bygger på ARMv8 mikroarkitekturen. Dess prestandamål är att vara energisnål och samtidigt effektiv. I mobila enheter placeras den ofta i en så kallad big.little konfiguration där big enheten innebär en processor som är optimerad för hög prestanda. Big -enheten är ofta en mer avancerad processor som har en out-of-order pipeline och bättre brach-prediction. Detta kräver mer energi samt större chiparea eftersom arkitekturen blir mer komplex. Cortex-A53 befinner sig i den andra sidan av spektrumet och är en så kallad LITTLE enhet vars primära syfte är att ta hand om alla uppgifter utom de mest krävande(arm, 2017b). I en big.little konfiguration är det vanligt att endast en enhet är aktiverad åt gången där LITTLE processorn svarar för majoriteten av tiden. Big processorn schemaläggs enbart när det är nödvändigt och på så sätt kan energi sparas genom att använda kombinationen på mobila enheter utan att tappa beräkningskraft. I detta projektet kommer dock ej Cortex-A53 parkopplas med en big enhet. Fokus kommer istället ligga på att undersöka hur väl multitrådning fungerar på den enskilda processorn. Den aktuella processorn är en så kallad symmetrisk multiprocessor (SMP) (ARM, 2017a). En annan benämning är homogen Chip-Multi Processor (CMP) som fortsättningsvis kommer att användas i rapporten. Den har fyra identiska kärnor (se APPENDIX A) som var och en har sitt eget L1-cache. I övrigt delas övriga resurser som L2- cache, primärminne och I/O -enheter vilket kan innebära begränsningar i systemet (se Fig.1). Varje enskild kärna har endast en tråd och kan därför enbart uppnå instruktionsparallellism (Nayfeh and Olukotun, 1997, s. 79). Däremot kan flera trådar exekveras parallellt på flera kärnor. Detta innebär dock att programvaran behöver stöd för multitrådning för att detta ska fungera tillfredsställande. I annat fall utförs exekveringen på en enskild kärna. Cortex-A53 prestandamål uppnås bland annat genom att implementera en relativt enkel dual-issue in-order pipeline med åtta steg (Humrick, 2017). Dualissue innebär att två instruktioner kan tas emot av pipelinen under samma klockcykel. Varje kärna har en egen pipeline som består av totalt sex beräkningsenheter varav två är ALUs för heltalsaddition, en ALU för heltalsmultiplikation, en enhet för hoppinstruktioner, en AGU för load/store -instruktioner samt en NEON/- flyttals -beräkningsenhet (se Fig.2 på s. 4). För att minimera risken att hela kärnan råkar ut för en stall, vilket innebär att kärnan stannar upp i väntan på problemet ska lösas, har Cortex-A53:s båda issue -platser stöd att utfärda instruktioner till samtliga beräkningsenheter i pipelinen vilket inte var fallet i tidigare modeller, dock kan varken två parallella multiplikationer, hopp, inläsning/lagring eller NEON/flyttals -beräkningar göras eftersom det saknas dubbla uppsättningar av dessa beräkningsenheter (Frumusanu and Smith, 2015). Ett annat skäl till att 3

5 2 ARKITEKTUREN Fig. 1 Illustration av symmetrisk multiprocessor där kärnorna delar minne och I/O -enheter (Larsson, 2017, s. 69). Lägg märke till att bilden visar godtyckligt många processorer alt. kärnor, medan den befintliga hårdvaran enbart har fyra kärnor. Fig. 2 Illustration av ARM Cortex-A53 pipeline. dual issue -enhetens båda platser ska kunna utfärda instruktioner till samtliga beräkningsenheter är att instruktionskön enbart håller tre instruktioner åt gången vilket gör det extra viktigt att se till att de instruktioner som ligger i kön kan exekveras parallellt. Här spelar kompilatorn en viktig roll i att se till så att instruktioner ordnas på ett sådant sätt att parallellismen kan maximeras. Detta kommer att diskuteras mer under avsnitt

6 3 TEORI 3 Teori 3.1 Multitrådning och pipelineing Multitrådning och pipelineing har en del gemensamma egenskaper. De är båda ämnade för att effektivisera och utnyttja resurser på ett bättre sätt genom att öka genomströmningen av instruktioner per tidsenhet. Superskalära processorer försöker uppnå instruktionsparallellism via sin pipeline och dess uppsättning av beräkningsenheter medan multitrådning utnyttjar trådar för att uppnå parallellism. Det finns således flera nivåer av parallellism som kan samverka inom samma arkitektur. Som tidigare nämnts är den aktuella processorn av typen CMP vilket innebär att det inte finns någon multitrådningsteknik implementerad per definition. Här är det istället frågan om ett antal kärnor som kan samverka parallellt om det explicit möjliggörs av antingen kompilator eller programmeraren (Nayfeh and Olukotun, 1997, s. 79). Nackdelen med detta är att den fulla potentialen inte kan utnyttjas såvida programvaran inte har stöd för trådning. Detta skiljer sig mot SMT arkitekturer där hårdvaran försöker parallellexekvera så många instruktioner som möjligt åt gången. Genom att överlåta planering av instruktioner till kompilatorn kan hårdvarukonstruktionen vara relativt enkel med ett mindre och snabbare instruktionsfönster gentemot en SMT arkitektur där det måste finnas en stor mängd instruktioner för att kunna realisera en hög grad av parallellism. Teorin är att kompilatorn i princip har ett oändligt virtuellt instruktionsfönster där instruktioner som ska exekveras parallellt ordnas så att de befinner sig i närheten av varandra i den exekverbara koden (Nayfeh and Olukotun, 1997, s. 80). På så sätt kommer dem att hämtas och läggas i instruktionsfönstret i relativ samtid och kan därefter utfärdas till varsin beräkningsenhet i pipelinen. Ett annat jobb för kompilatorn är att bestämma hur instruktionerna ska fördelas över de tillgängliga kärnorna. I CMP arkitekturer agerar varje kärna som om den vore en tråd i en SMT arkitektur. Detta innebär att det antal trådar den givna programvaran stödjer kommer kompilatorn fördela på ett sådant sätt att maximal tråd/instruktions -parallellism uppnås. Det har visat sig att programvara som ej utvecklats med stöd för trådar ofta också presterar sämre på SMT arkitekturer på grund av att det blir svårare att arrangera instruktionerna i sådan ordning att maximal instruktionsparallellism går att uppnå. Detta resulterar i att SMT arkitekturer ofta bara är bråkdelen snabbare än en CMP arkitektur av det aktuella slaget som har två issue -platser som parallellt kan utfärda instruktioner (se Fig. 2) (Nayfeh and Olukotun, 1997, s. 85). 5

7 3.2 Kontextbyte 3 TEORI 3.2 Kontextbyte Det finns olika typer av kontextbyten som kan samverka i ett system. En variant är att det är implementerat på hårdvaran, vilket ofta är fallet då processorn implementerar multitrådningstekniker som simultan, interleaved eller blocked. Den andra typen av kontextbyte sker genom operativsystemets schemaläggare vilket uteslutande gäller för ARM Cortex-A53. Operativsystemets roll i kontextbyte innebär att se till så att alla processer som är aktiva kan samköras på den befintliga mängden resurser som innebär antalet kärnor i detta fall (CMP). Anledningen är att alla aktiva processer ska kunna hållas igång och ge sken av att de körs parallellt. Innebörden av kontext är registernas innehåll samt programräknaren för den aktiva tråden. Det innebär att kontextbyten som utförs av operativsystemet i regel är beräkningsintensiva. Detta beror på att kontexten av en tråd ska lagras och en annan läsas in vid ett byte (Project, 2006). Ett annat problem som uppkommer när antalet trådar övertrasserar antalet kärnor i denna typen av system är att operativsystemets schemaläggare kommer allokera tidsintervall växelvis där trådarna skiftas om att vara aktiva. Problemet med detta är att kärnas L1-cache med hög sannolikhet kommer vara inaktuell efter merparten av kontextbytena. Detta resulterar i att cacheminnet kommer att uppdateras enligt en ersättningsalgoritm (oftast LRU) efter varje kontextbyte. Detta beteendet degraderar prestandan i dagens processorer som i hög grad beror av det snabba cacheminnet (Shameem and Jason, 2011). 6

8 4 UTFÖRANDE 4 Utförande Prestandamätningen genomfördes med två separat skrivna program. Ett varav all exekvering sker sekventiellt, ett annat där exekveringen sker parallellt med hjälp av variabelt antal trådar. Det gemensamma för de båda programmen är att båda ska beräkna hash-summor av en mängd strängar med en given storlek där resultatet sedan ska skrivas ut till skärmen. I detta projektet undersöks enbart ett prestandamått av många, exekveringstid. Genom att mäta den tid det tar för algoritmen att genomföra beräkningarna är tanken att se hur bra eller dåligt programmet presterar med olika antal trådar och på så sätt jämföra hur prestandavinst förhåller sig till antal trådar på ARM Cortex-A53 arkitekturen. Problemet som algoritmen ska lösa samt algoritmens design är identisk mellan de olika programvaruversionerna för att göra testet så rättvist som möjligt. Källkoden kompilerades med C++ version 11, GNU g++ kompilator i båda fallen. I det sekventiella programmet görs en beräkning per iteration. I det multitrådade programmet är det mer komplicerat. Här skapas en lista med trådstrukturer som var och en innehåller en jobbkö. Genom att tilldela varje tråd ett antal jobb som läggs i denna kö, kan varje tråd exekvera de jobb den blivit tilldelad i tur och ordning. Dock uppstår det en del svårigheter. För det första, bör jobben synkroniseras för att undvika att resultatet skrivs ut i fel ordning. För det anda måste koden implementeras så att de olika trådarna kan dela på de gemensamma resurserna som t.ex. I/O till skärmen. Detta kommer diskuteras vidare under resultat och diskussions delen. 7

9 5 RESULTAT 5 Resultat Fig. 3 En jämförelse av exekveringar med olika antal trådar där arbetsvolym var 600 hashingar av varierande längder på strängarna. Den procentuella förbättringen räknades ut med följande formel: Resultat enligt nedan: P restandavinst = δt t = t 2 t 1 t 2 För hashning av strängar med längden 10 7, löste två trådar exkl. huvudtråden uppgiften 45,82% snabbare än otrådad programvara. För hashning av strängar med längden 10 6, löste två trådar exkl. huvudtråden uppgiften 53,11% snabbare än otrådad programvara. För hashning av strängar med längden 10 5, löste två trådar exkl. huvudtråden uppgiften 53,32% snabbare än otrådad programvara. För hashning av strängar med längden 10 4, löste tre trådar exkl. huvudtråden uppgiften 53,86% snabbare än otrådad programvara. 8

10 5 RESULTAT För hashning av strängar med längden 10 3, löste två trådar exkl. huvudtråden uppgiften 47,46% snabbare än otrådad programvara. Fig. 4 Exekveringar med olika antal trådar. Arbetsvolymen var 10 6 hashningar av strängar med storlek 10. I detta experiment (se Fig.4) presterade den otrådade versionen 39,15% bättre än exekvering med 3 trådar (exkl. huvudtråden) som inom gruppen av parallellexekveringarna presterade bäst i detta testet. 9

11 6 DISKUSSION 6 Diskussion Resultatet i Fig.3 visar tydligt att det finns prestandavinster att hämta genom att utveckla multitrådad programvara för Cortex-A53 arkitekturen trotts dess avsaknad av out-of-order pipeline och simultan multitrådning. Grafen visar även att det är viktigt att balansera antalet trådar så att de har stöd i hårdvaran. C++ standardbibliotek för trådar kan ge en fingervisning om hur många samtidiga trådar som stöds av hårdvaran via följande syntax: std::thread::hardware_concurrency. Uppskattningen visade sig stämma bra med resultatet som genomgående visade att två trådar exklusive huvudtråden löste uppgiften snabbast. Den troliga orsaken till det är att operativsystemet ej behöver utföra onödiga kontextbyten med anledning av att bakgrundsprocesser kan köras på en separat tråd. Med stöd av resultatet verkar två trådar vara den optimala kombinationen på denna arkitekturen då uppgiften uträttades 46-53% snabbare än otrådad exekvering i de tre fallen där de längsta strängarna skulle haschas. I övriga exekveringar presterade denna uppsättning jämbördigt med tre samt fyra trådar då varje sträng var 10 4 samt 10 3 bokstäver lång. Här ska även tilläggas att optimeringsflaggor för arkitekturen ej sattes vid kompilering av programvaran i något av fallen. Här finns det säkert mer prestanda att hämta om så önskas. Även aspekter som hur väl optimerad den faktiska C++ koden är implementerad bör has i åtanke då det troligen går att förbättra ytterligare. Ett exempel vore att införa korta randomiserade väntetider då gemensamma resurser ska användas av de olika trådarna. Detta skulle innebära att risken för att någon tråd väntar på att resursen ska bli ledig minskar ytterligare och på så sätt fås ett bättre flöde i arbetsprocessen. En annan aspekt att förbättra vore att optimera den mängd jobb huvudtråden kan utföra medan den inväntar att alla de andra trådarna ska bli klara med sina uppgifter. I testerna som körts för att extrahera resultatet till Fig. 3 på s. 8 gjorde huvudtråden 20% av det totala arbetet medan 80% av arbetet fördelades på övriga trådar. Sedan finns det problem som helt enkelt inte lämpar sig väl till att lösas parallellt. Ett exempel är t.ex. Fibonaccis talserie där nästa tal i serien beror av de två föregående. Detta innebär som tidigare avhandlats att processorns fulla potential ej kommer att utnyttjas vid denna typ av problemlösning. I Fig.4 illustreras hur prestandan påverkas negativt när själva problemet tar så kort tid att det skapas köer bland trådarna till de gemensamma resurserna, därav presterar den icke multitrådade programvaran bättre i detta fall. 10

12 7 SLUTSATS 7 Slutsats Slutsatsen av projektet är att det finns stora prestandavinster att hämta ur multitrådad exekvering på ARM Cortex-A53 mikroarkitektur. I det mest krävande testerna exekverade programvaran med optimalt antal trådar upp till 54% snabbare än otrådad programvara. På detta sätt utnyttjas resurserna i hårdvaran på ett bättre sätt. Vad som är tydligt är att vinsterna minskar vid tillräckligt enkla problem. En stor bidragande faktor till detta är troligen de gemensamma resurserna som de olika kärnorna delar(se Fig. 1). Här orsakas köer när trådarna försöker få tillgång till dessa resurser och i värsta fall minskar prestandan gentemot otrådad programvara. 11

13 8 Referenser ARM (2017a), Cortex-a53. [Online; Hämtad ]. URL: ARM (2017b), Technologies: big.little, technologies/big-little. [Online; Hämtad ]. Frumusanu, A. and Smith, R. (2015), Arm a53/a57/t760 investigated - samsung galaxy note 4 exynos review, the-samsung-galaxy-note-4-exynos-review/3. [Online; Hämtad ]. Humrick, M. (2017), Exploring dynamiq and arm s new cpus: Cortex-a75, cortex-a55, dynamiq-and-arms-new-cpus-cortex-a75-a55/4. [Online; Hämtad ]. Larsson, E. (2017), Datorarkitekturer med operativsystem. [Online; Hämtad ]. URL: Nayfeh, B. A. and Olukotun, K. (1997), A single-chip multiprocessor, Computer 30(9), Project, T. L. I. (2006), Context switch definition. [Online; Hämtad ]. URL: Shameem, A. and Jason, R. (2011), Avoiding classic threading problems. [Online; Hämtad ]. URL: 12

14 A INFORMATION OM ARM CORETEX-A53 CPU 9 APPENDIX A Information om ARM Coretex-A53 CPU Observera att anledningen till att det står ARMv7 i CPU specifikationen nedan beror på att operativsystemet är 32-bitars version. johan@srv01:~ \$ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 1 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 2 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 13

15 A INFORMATION OM ARM CORETEX-A53 CPU processor : 3 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware Revision Serial : BCM2835 : a02082 : eb