| dc.description.abstract | Softwaresimulering er en mye brukt metode for å forske på datamaskin arkitekturer. Dessverre er det tregt, spesielt for større parallelle arkitekturer, som GPUer. En detaljert simulering av en GPU kan ta opptil flere dager. FPGAer er konfigurerbare integrerte kretser som kan brukes for å akselerere datamaskin arkitektur simuleringer. De er dermed en middelvei mellom trege softwaresimuleringer og kostbare prototyper.
Vortex er en RISC-V basert GPGPU som kan FPGA-akselereres, og er dermed en god kandidat for forskning innen GPU arkitekturer. Gjennom min prosjektoppgave, la jeg til støtte for å generere CPI stacks for Vortex. Det gjorde at jeg identifiserte mulige ytelsesproblemer knyttet til Vortex sin frontend og skedulerer. Disse problemene hindrer Vortex i å utnytte parallellitet og skjule venting, som reduserer gjennomstrømningen av instruksjoner.
I denne oppgaven, implementerer jeg og evaluerer tre forbedringer til Vortex sin mikroarkitektur. Først implementerer jeg klar skedulering, som gjør det mulig for Vortex å vite hvilke instruksjoner som er klare før de blir utstedt. For det andre, øker jeg gjennomstrømningen av instruksjoner i Vortex sin frontend ved å gjøre det mulig å hente instruksjoner uten å blokkere. I tillegg implementerer jeg stansforutsigelse for at Vortex skal lære når den må blokkere. Til slutt implementerer jeg en grådig så eldst (GTO) skeduleringalgoritme, og sammenlikner dens ytelse med den eksisterende loose round robin (LRR) skedulereren.
I prosjekt oppgaven min var genereringen av CPI stacks koblet til den eksisterende skedulereren. Den samplet bare stansårsaken til instruksjonen valgt av skedulereren. I denne oppgaven utvider jeg denne metoden ved å sample stansårsaken til alle instruksjonene. Dette gir et bedre overblikk over hvorfor Vortex står stille. I tillegg utvider jeg Vortex sin testbenk ved å overføre 16 testprogrammer fra \Gls{rodinia, et mye brukt sett med testprogrammer for GPUer. Denne overføring involverer å endre sentrale komponenter av Vortex sitt system for å lese ytelsesdata, og endre testprogrammene sin kildekode for å tilrettelegge for noe manglende OpenCL funksjonalitet.
Implementasjonen av klar skedulering fjerner alle sykler hvor instruksjoner er klare, men ingen blir utstedt. For testprogrammer med lav-latens blokkader, som psort, er denne endringen nok for å skjule at andre instruksjoner må vente. Dermed fører det til en CPI reduksjon på 20%. Klar skedulering har en mye mindre effekt på testprogrammer som er bundet av høy latens. Forbedringene av frontenden øker frontendens båndbredde og reduserer det gjennomsnittlige antallet blokkeringer relatert til frontenden med 71%. For sfilter, blir alle blokkeringer relatert til frontenden fjernet. Dette er fordi den forbedrede frontenden bare blokkerer for å håndtere flytkontroll, mens sfilter ikke har noen flytkontroll instruksjoner. CPIen blir derimot ikke redusert i samme grad som blokkeringene relatert til frontenden. Ved å kombinere alle endringene, blir den gjennomsnittlige CPIen redusert med 5.4%. Dette er fordi latensen blir for stor til at den kan skjules av den nåværende Vortex konfigurasjonen, som er for liten. Flaskehalsen blir dermed flyttet til backenden av GPUen. Størrelsen på Vortex konfigurasjonen er også grunnen til at det ikke er noen forskjell i ytelse for LRR og GTO skedulererene. | |
| dc.description.abstract | While software simulation is a common method for performing computer architecture research, it is slow for highly parallel architectures such as GPUs. A detailed simulation of a fully sized GPU can take several days. FPGAs are reconfigurable integrated circuits, which can be used to accelerate computer architecture simulations. They are thus a middle ground between slow software simulations and expensive hardware prototypes.
Vortex is a RISC-V based GPGPU capable of being FPGA-accelerated, thus being a good candidate for GPU architecture research. In my project thesis, I added support for generating cycles per instruction (CPI) stacks for Vortex, which enabled me to identify potential performance bottlenecks in Vortex' frontend and schedulers. These issues inhibit Vortex from exploiting parallelism and hiding stalls, reducing its throughput.
In this thesis, I implement and evaluate three improvements to the Vortex microarchitecture. First, I implement ready scheduling, enabling Vortex to know which warps are ready before issuing them. Secondly, I improve the throughput of Vortex' frontend by allowing it to fetch instructions without stalling. I also implement stall prediction to make Vortex learn when stalls are required. Finally, I implement a greedy then oldest (GTO) scheduling algorithm and compare its performance with the existing loose round-robin (LRR) scheduler.
In my project thesis, the generation of CPI stacks was closely connected to the existing issue scheduler. It only sampled the stall cause of the warp selected by the scheduler. In this thesis, I expand upon this method, sampling the stall cause of all warps in the issue stage. This gives a greater overview of why Vortex is stalling. Additionally, I broaden Vortex' lacking benchmark suite by porting 16 benchmarks from Rodinia, a commonly used set of GPU benchmarks. This involves altering core components of Vortex' system for reading performance data and changing the benchmarks' source code to accommodate for some missing OpenCL functionality.
Implementing ready scheduling, removes all missed opportunities for issuing warps. For benchmarks with low-latency stalls, such as psort, this change is enough to hide the stalls, reducing CPI by 20%. Ready scheduling does however have less impact on benchmarks bounded by long-latency stalls. The frontend improvements are able to increase the frontend bandwidth, reducing the average number of frontend-related stalls by 71%. For sfilter, all frontend stalls are removed. This is because the improved frontend only stalls to handle control flow, and sfilter does not have any control flow instructions. However, the CPI is not reduced to the same degree. On average, the combined improvement of the frontend and ready scheduling, reduces CPI by 5.4%. This is because the latencies are too long to be hidden by the current Vortex configuration, which is too small. The bottleneck is thus moved to the backend. The size of the Vortex configuration is also the reason why there is no significant performance difference between using an LRR and GTO scheduler. | |
