Computerarchitectuur 2016 Inleveropdracht 3: Exploiting Memory Hierarchies in Modern Systems

Transcriptie

1 Computerarchitectuur 2016 Inleveropdracht 3: Exploiting Memory Hierarchies in Modern Systems Gesuggereerde Deadline: zondag 27 november 2016 Zoals we in het hoorcollege uitgebreid hebben besproken spelen geheugenhiërarchieën een cruciale rol in hedendaagse computersystemen. In deze opdracht zullen we gaan kijken hoe we onze kennis hiervan kunnen gebruiken om het gedrag van programma s te begrijpen en te optimaliseren. Tevens is er de mogelijkheid een programma te schrijven dat de geheugenhiërarchie van een systeem analyseert. Bij de analyse van het gedrag van de programma s zullen we gebruik maken van hardware performance counters. Deze tellers houden allerlei gebeurtenissen in de processor bij, zoals het aantal cache misses, verkeerd voorspelde branches, enzovoort. Op Linux-systemen kunnen we met het programma perf de hardware performance counters uitlezen 1. We kunnen dit bijvoorbeeld doen voor het programma ls: $ perf stat ls -1 /usr/bin > /dev/null Performance counter stats for ls -1 /usr/bin : task-clock # CPUs utilized 1 context-switches # M/sec 0 CPU-migrations # M/sec 448 page-faults # M/sec 16,994,789 cycles # GHz <not supported> stalled-cycles-frontend <not supported> stalled-cycles-backend 30,483,289 instructions # 1.79 insns per cycle 4,958,601 branches # M/sec 91,145 branch-misses # 1.84% of all branches seconds time elapsed We krijgen allerlei statistieken te zien zoals het aantal uitgevoerde instructies en het aantal clock cycles dat is gebruikt. Met de optie -e kunnen we andere events opgeven, -r geeft aan hoe vaak het experiment moet worden herhaald: $ perf stat -e instructions:u,cycles:u,cache-misses:u,cache-references:u -r 5 \ ls -1 /usr/bin > /dev/null Performance counter stats for ls -1 /usr/bin (5 runs): 25,515,700 instructions:u # 1.96 insns per cycle ( % ) 13,013,545 cycles:u # GHz ( % ) 1,644 cache-misses:u # % of all cache refs ( % ) 21,742 cache-references:u ( % ) seconds time elapsed ( % ) De toevoeging :u duidt aan dat alleen events binnen user-space moeten worden geteld, events binnen de kernel tijdens het uitvoeren van dit programma tellen niet mee. Nog drie punten van aandacht: 1 perf staat alleen geïnstalleerd in zalen 302, 303, 305 en 306 1

2 Alle gerapporteerde getallen zijn schattingen en geen exacte aantallen. Het exact tellen van events brengt zeer veel overhead met zich mee; in feite zou de machine dan alleen maar bezig zijn met het verwerken van de counters en niet met het uitvoeren van het programma zelf. Meet niet te veel events tegelijkertijd. De hardware kan maar een vast aantal events tegelijkertijd meten. Als er meer events worden opgegeven, dan moet de tijd tussen de events worden verdeeld en dit komt de nauwkeurigheid niet ten goede. Voor de nauwkeurigheid van de metingen helpt het vaak om het programma toe te wijzen aan een vaste core. Dit kan als volgt: taskset -c 1./mijnprogramma. En in combinatie met perf stat: perf stat -e cycles:u taskset -c 1./mijnprogramma. Verder is het zeer belangrijk om in de gaten te houden wat er precies wordt geteld bij de verschillende events. Voor cache-misses wordt het aantal LLC (Last-Level Cache of Longest-Latency Cache) misses geteld. cache-references telt het aantal keer dat de last-level cache is benaderd. Het programma perf kent een lijst ingebouwde events die kunnen worden bekeken met het commando perf list. Niet alle events staan echter in deze lijst. Wanneer je een event wilt meten dat niet in de lijst staat, maar wel wordt ondersteund door de processor, dan moet je de exacte code van het event opgeven. Ter inspiratie: r0151 L1D.REPLACEMENT Aantal cache-lines dat in de L1 data cache is ingelezen. r01d1 MEM LOAD UOPS RETIRED.L1 HIT Het aantal retired operaties dat resulteerde in een L1 hit. Retired houdt in dat de operatie de reorder buffer (ROB) verlaat en dus ook moest worden uitgevoerd. Speculatief uitgevoerde instructies die uiteindelijk niet moesten worden uitgevoerd, worden nooit retired. r08d1 MEM LOAD UOPS RETIRED.L1 MISS Op dezelfde manier het aantal L1 misses. r02d1 MEM LOAD UOPS RETIRED.L2 HIT Op dezelfde manier het aantal L2 hits. r10d1 MEM LOAD UOPS RETIRED.L2 MISS Op dezelfde manier het aantal L2 misses. r04d1 MEM LOAD UOPS RETIRED.LLC HIT Op dezelfde manier het aantal LLC (L3) hits. r20d1 MEM LOAD UOPS RETIRED.LLC MISS Op dezelfde manier het aantal LLC (L3) misses. Een dergelijke code wordt gewoon opgegeven bij het -e argument, bijvoorbeeld -e r02d1:u. De liefhebber kan een volledige lijst van events terugvinden in Hoofdstuk 19 van Volume 3 (System Programming Guide) van de Intel 64 and IA-32 Architectures Software Developer s Manual Tenslotte is het belangrijk om in de gaten te houden op welke processor je aan het experimenteren bent. Verschillende processoren gebruiken verschillende codes voor de performance counters en hebben verschillende cache eigenschappen. Met het programma lscpu kunnen een aantal eigenschappen van de processor worden weergegeven. De Dell-machines in zaal 302 bevatten een Intel Core i (dit kan worden opgezocht met cat /proc/cpuinfo) en dit is een chip van de Ivy Bridge generatie, ofwel een derde-generatie Intel Core processor. Deze processor beschikt over 32K L1 data cache per core, 256K L2 cache per core en 8M gedeelde L3 cache. Opgaven Zorg dat je in het ca2016 environment zit, zodat je gebruik kan maken van een recente versie van de gcc compiler: 2

3 source /vol/share/groups/liacs/scratch/ca2016/ca2016.bashrc 1. Als eerste bekijken we een implementatie van matrixvermenigvuldiging. Zie matrixmul.c in de materialen. Gebruik perf om het gedrag van het programma in kaart te brengen. Hoeveel cache misses vinden er plaats? Wat gebeurt er wanneer N (zien bovenaan het bestand) wordt veranderd? Wat is de CPI van het programma? Schrijf in je verslag een korte discussie over je bevindingen. Vermeld ook het processor-type waarop de analyse is uitgevoerd! 2. Maak een kopie van de source code en pas Loop Blocking toe op de matrixvermenigvuldigingsroutine. Kies een geschikte block size om mee te beginnen (in ieder geval een macht van 2!). Denk bij het kiezen van de initiële block size aan de grootte van de L1 cache en wat voor data daar moet worden opgeslagen. Voer vervolgens experimenten uit met de geblokte versie van matrixvermenigvuldiging. Is de performance beter (CPI)? Is het aantal cache misses afgenomen? Is de executietijd afgenomen? Wat gebeurt er voor verschillende waarden van de block size? Plaats de code van je geblokte matrixvermenigvuldiging in je verslag. En schrijf weer een aantal paragrafen over je bevindingen. 3. Het bestand matrixvecadd.c bevat een code (add vec) die elke kolom van een matrix met 2 vermenigvuldigt en daar een kolomvector b bij optelt. Benchmark het programma. Bekijk de source code van add vec. Wat zou je aan deze routine kunnen veranderen om de performance te verbeteren? Pas deze verandering toe en analyseer of deze affect heeft. Plaats in het verslag de aangepaste routine en een discussie over het effect van de aanpassingen. Met behulp van SIMD-instructies is het mogelijk om de performance van de routine verder te verbeteren. De processor in de Dell-machine ondersteunt AVX SIMD instructies. Door gebruik te maken van intrinsics kunnen we deze instructies in ons C-programma gebruiken zonder assembly code te schrijven. Er moeten speciale datatypen worden gebruikt die vectoren voorstellen. Bijvoorbeeld: /* Maak een 256-bit vector met 8 floats en geef elk element de waarde 19 */ float mul = 19.; m256 mul_vector = _mm256_broadcast_ss (&mul); /* Laad 8 floating-point waarden uit het geheugen in een vector, startende bij * het gegeven adres (pointer). */ float array[1024]; m256 tmp1 = _mm256_load_ps (&array[0]); De suffix ss staat voor scalar single-precision en ps voor packed single-precision. packed duidt aan dat het argument meerdere waarden bevat (en dus een vector is). Handig bij het programmeren is de Intel Intrinsics Guide: IntrinsicsGuide/. Je kunt op elke intrinsic klikken voor informatie en documentatie. Gebruik AVX instructies en geen AVX2 instructies (deze laatste worden door deze hardware niet ondersteund). 4. Schrijf nu een SIMD-variant van je geoptimaliseerde add vec routine. Ga uit van N = Benchmark de code en probeer met behulp van SIMD een hogere performance te behalen 3

4 dan de niet-simd code. In je verslag plaats je de SIMD code en een korte discussie. aantal instructies en de CPI. Kijk bijvoorbeeld naar het 5. Voor de liefhebbers: schrijf een programma dat het aantal caches en de grootte van de caches in een systeem kan bepalen. Dit wordt gedaan door data te verwerken in steeds grotere arrays. Voor de verschillende arrays wordt de executietijd bepaald. Dit alles leidt tot een plot waarin de verschillende caches zichtbaar zijn, de plot heeft de vorm van een trap. Stuur het geschreven programma mee en schrijf voor het verslag een korte discussie aan de hand van de geproduceerde plot. Komt de plot min of meer overeen met de caching statistieken zoals gerapporteerd door lscpu? Een aantal hints en tips: Inleveren Je hebt een goede timer nodig om de executietijd van de test-loop te meten. Bijvoorbeeld: #include <time.h> struct timespec start, end, elapsed; clock_gettime(clock_process_cputime_id, &start); /*... */ clock_gettime(clock_process_cputime_id, &end); timespec_subtract(&elapsed, &end, &start); Voor een implementatie van timespec subtract zie libc/manual/html_node/elapsed-time.html. Het experiment moet worden uitgevoerd voor arrays van oplopende grootte. Begin bijvoorbeeld met 256 bytes en vermenigvuldig de grootte steeds met 2. Ga door tot ten minste 64 * 1024 * 1024 bytes. Een experiment bestaat uit de volgende stappen: (1) alloceer een array van de gewenste grootte, (2) initialiseer de array, (3) roep een functie aan die de cache trasht (effectief leegmaakt), (4) lees de array en herhaal dit 1000 keer, (5) geheugen vrijgeven. Cache trashing kan worden gedaan door een array te maken die ruim groter is dan de L3 cache en deze bijvoorbeeld 5 maal volledig te beschrijven. Het lezen van de array moet gebeuren met een niet-regulier toegangspatroon. Als dit niet wordt gedaan, worden de caches niet zichtbaar omdat de prefetcher het toegangspatroon herkent en alle data al klaar kan zetten. Je moet dus zorgen voor een toegangspatroon dat de prefetcher niet kan herkennen. Wat je kunt doen, is de array zo initialiseren dat elk array element wijst naar het volgende te lezen element. En het laatste element wijst weer naar index 0. Dus bijvoorbeeld a[0] = 3, a[3] = 9, a[9] = 11, a[11] = 0. Zorg dat de sprongen die worden gemaakt niet regulier zijn! Gebruik bijvoorbeeld 8 verschillende increments (strides) die je na elkaar gebruikt, zoals hierboven: +3, +6, +2, enz. Het experiment bewandelt dan deze ketting (next = a[next]) totdat je 0 weer tegenkomt. Er mag worden gewerkt in duo s. Het volgende moet worden ingeleverd: 4

5 Het verslag, in tekst- of PDF-formaat. Zorg ervoor dat alle bestanden die worden ingeleverd (source code, verslag, enz.) zijn voorzien van naam en studentnummer! Plaats alle bestanden om in te leveren in een aparte directory (bijv., opdracht3) en maak een gzipped tar bestand (het is prima als source code en verslag in dezelfde tar.gz terechtkomen): tar -czvf opdracht3-sxxxxxxx-syyyyyyy.tar.gz opdracht3/ Vul op de plek van XXXXXXX en YYYYYYY de bijbehorende studentnummers in. De inzendingen kunnen worden verzonden per naar ca2016 (at) handin.liacs.nl met als onderwerp CA Opdracht 3. Vermeld in de ook namen en studentnummers. 5