Pipeline hos ARM Cortex-A53 och ARM Cortex-A73

Lunds universitet Pipeline hos ARM Cortex-A53 och ARM Cortex-A73 Kevin Eriksson EITF60 Kursansvarig: Erik Larsson 2017-12-04

Innehållsförteckning Syfte 2 Sammanfattning 2 Jämförelse 3 Pipelinebredd 3 Out of order exekvering 3 Hopprediktion 5 Slutsats 8 Referenser 9 1

Syfte Syftet med denna rapport är att ge en fördjupad kunskap i hur parallellism kan uppnås i processorer samt att undersöka två processorer och jämföra vilka funktioner de två processorerna har för att uppnå parallellism. Sammanfattning Under många års tid har processorer varit en stor del av människans vardag. Processorer hade sitt ursprung i PCs men har genom tiden spridit sig exponentiellt och finns idag i allt från mobiltelefoner och laptops till kylskåp och bilar. I denna rapport skall vi rikta in oss på två specifika RISC-arkitekturer av ARM, nämligen Cortex-A53 och Cortex-A73. Dessa två arkitekturer är byggda av två olika syften där den förstnämnda exempelvis är processorn i den berömda enkortsdatorn Raspberry Pi 3 vars främsta egenskap är sin mångsidighet i förhållande till sitt pris. Cortex-A73 används bland annat av Qualcomm i deras Snapdragon 835. Denna processor används i många av dagens högpresterande mobiltelefoner där kraven på prestanda är hårda. Men vad är det egentligen som skiljer sig under ytan? Vilka funktioner har de två arkitekturerna gentemot varandra? De två områden som kommer behandlas är pipelinebredd, Out-of-Order exekvering samt hopprediktion hos de båda processorerna. 2

Jämförelse Pipelinebredd När man använder sig av pipelining för att minska exekveringstiden för ett program är det viktigt att att ha koll på vilka faktorer som spelar roll för att minska programmets exekvering. Pipeline depth är kort beskrivet hur många samtidiga instruktioner processorn kan utföra simultant och beror på hur många steg processorn behöver gå igenom för att exekvera en instruktion. Har man exempelvis en processor med en pipeline som har ett djup på fem innebär det att fem instruktioner kan utföras simultant och att en instruktion består av fem steg. En låg pipeline depth minskar risken för eventuella hasarder men gör också att programmet kommer att ta längre tid att exekvera. En processor med möjlighet till ett stort antal samtidiga instruktioner kommer att exekvera ett program snabbare förutsatt att det inte ökar risken för hasarder. ARM Cortex-A53 använder sig av en 8-stegad pipeline vilket innebär att varje instruktion består av åtta steg och på så sätt kan åtta instruktioner utföras simultant. Detta skiljer sig från ARM Cortex-A73 som använder sig 11-12 stegs pipeline beroende av vilken typ av instruktion som utförs. Detta innebär att varje instruktion kommer ta längre tid att utföra men att antalet simultana instruktioner som kan utföras är större. Både Cortex-A53 och Cortex-A73 är superskalära processorer vilket innebär att de inte bara kan utnyttja olika delar av processorn samtidigt. De kan även exempelvis utföra flera beräkningar simultant. Prestandan baseras sedan på hur många samtidiga instruktioner processorn klarar att utföra, som i sin tur baseras på andra egenskaper hos processorn. Om processorn klarar att hålla sin pipeline full, genom att exempelvis implementera en bra hopprediktion kommer detta gynna processorn och ge bättre prestanda. Klarar inte processorn att hantera det stora antalet simultana instruktioner kommer detta istället att lämna delar av processorn tom under exekveringen av ett program och ge en sämre prestanda. Det gäller alltså för tillverkaren att hitta en medelväg där så billig hårdvara som möjligt kan prestera så bra som möjligt utan att det sker fördröjningar i exekveringen. Att implementera mer resurser än vad processorn kan utnyttja är onödigt. Att Cortex-A73 kan utföra fler samtidiga instruktioner ger den en teoretiskt högre prestanda än Cortex-A53. Out of order exekvering Många operationer som utförs kan vara krävande operationer som tar lång tid att utföra och därmed stannar upp resten av exekveringen onödigt länge. Exempel på en sådan instruktion är en flyttalsberäkning som ofta kräver fler instruktionscykler för att beräknas än en addition eller subtraktion. När denna typ av instruktioner börjar användas skapar det problem för pipelinen i form av att rytmen i exekveringen bryts och stalls kommer att ske. Detta problem kan lösas genom att använda sig av en så kallar superskalär processor där flera parallella enheter som kan utföra olika instruktioner samtidigt. På så sätt kan exempelvis någon enhet för flyttalsberäkningar och någon annan för andra instruktioner implementeras vilket gör att 3

varje individuell pipeline utnyttjas till sin maximala kapacitet. Problemet med data-hasarder kvarstår dock fortfarande då många på varandra följande instruktioner ofta är beroende av varandra. På grund av detta kommer utnyttjandet av de andra beräkningsenheterna vara mycket låg och effektiviteten kommer inte att vara mycket högre än hos en icke-superskalär processor. Detta kan lösas med hjälp av en metod som heter Out-Of-Order exekvering vars filosofi är att instruktioner inte behöver exekveras i den följd som kompilatorn genererat. På så sätt kan alla pipelines agera individuellt genom att en fördelningsenhet avgör vilka instruktioner som kan utföras simultant. De instruktioner som dispatchern kan välja mellan kallas instruktionsfönster och är en buffert av avkodade instruktioner som fördelningsenheten kan dela ut till de olika beräkningsenheterna. Denna teknik är mycket mer komplicerad att konstruera eftersom fler konflikter behöver kunna hanteras på grund av att instruktioner inte kommer att utföras i rätt ordning. Tidigare har vi nämnt data-hasard som innebär att en instruktion vill ha resultatet från den tidigare instruktionen innan det blivit beräknat, vidare kallat True Data dependency. Med OoO uppstår två nya konflikter som faller inom samma kategori: Output dependency Anti-dependency Dessa två sker till skillnad av True Data dependency inte på grund av kompilatorn utan på grund av att instruktionerna utförs i en annan ordning än kompilatorn tänkt. Output dependency innebär att två, eller fler, instruktioner vill lagra information på samma plats samtidigt. Detta kan undvikas med en metod som kallas register renaming, vilket innebär att de man ändrar instruktionerna så att de skriver till olika register. Anti-dependency innebär att en instruktion vill läsa från ett register medans en annan instruktion skriver till samma register. Även denna konflikt kan lösas med register renaming. En processor som stödjer funktionerna nödvändiga för att lösa dessa konflikter är processor som utnyttjar sina resurser maximalt genom att antalet fördröjningar som kommer ske på grund av data-hasarder minimerats. Mer tidskrävande beräkningar kommer inte heller att hindra andra instruktioner från att exekveras. (Etsion, Y. 2013) Här skiljer sig Cortex-A53 och Cortex-A73 åt då det endast är Cortex-A73 som har Out-of-Order exekvering. Detta betyder att Cortex-A73 är en effektivare processor som, i många fall, kan exekvera program märkbart snabbare än Cortex-A53 men som kräver mer avancerad teknik för att kunna hantera de problem som uppstår med OoO exekvering. På grund av att Cortex-A73 använder sig av out-of-order exekvering kan den dra nytta av ett större antal samtidiga beräkningar vilket ger en stor prestandaskillnad mellan de två processorerna. 4

Cortex-A73 har två ALU enheter för heltalsberäkningar, en enhet för hoppinstruktioner, två AGU enheter för LOAD/STORE operationer och två för NEON enheter för flyttalsoperationer enligt Fig. 1. (Frumusuanu, 2016) Cortex-A53 har tre ALU enheter för heltalsberäkningar, en för hoppinstruktioner, en AGU enhet för LOAD/STORE samt en NEON enhet för flyttalsberäkningar. Antalet enheter och typerna av enheter skiljer sig mellan de två processorerna men den största skillnaden är hur många simultana instruktioner de två enheterna kan utföra. Cortex-A73 implementerar multiple issue vilket innebär att alla beräkningsenheter kan användas simultant. Cortex-A53 implementerar dual issue, dvs att endast två enheter kan användas simultant. Det hade inte varit svårt implementera multiple issue hos Cortex-A53 men som tidigare nämnt så hade ökningen i prestanda varit minimal och i förhållande till kostnaden av de ytterligare beräkningsenheterna hade gett sämre prestanda i förhållande till priset. Att implementera OoO är både dyrt och energikrävande, därför har ARM gjort allt de kan för att utnyttja alla komponenter maximalt utan att behöva implementera OoO. Det är alltså viktigt att hitta den optimala konstruktionen för att dra maximal nytta av alla komponenter. Dvs att minimera flaskhalsarna i processorn. Hopprediktion Ett stort problem som uppstår vid pipelining är att avgöra hur processorn skall agera vid hopp, dvs när instruktionen på nästa adressrad inte längre är nästa instruktion som skall exekveras. Hade situationen varit att dessa hopp med säkerhet tas hade inte effekterna på exekveringstiden varit stora men då det hos de allra flesta processorer finns villkorliga hopp. Dessa hopp är instruktioner som ofta beror på resultatet av en, eller ett par, instruktioner tidigare. På grund av att det inte går att avgöra om hoppet sker eller inte går det inte heller vara säker på vilken som är nästa instruktion som sker. På de tidiga processorerna, som implementerade pipeline, används ofta statiska beslut. Exempelvis att antogs att hoppet alltid skulle tas och tog beslutet att nästa instruktion var instruktionen dit hoppet skulle gjorts. Detta är dock en metod som skapar mycket fördröjningar eftersom fel instruktion börjat exekvera om hoppet inte skulle göras. Detta 5

resulterade i tekniker för att göra bättre beslut om ett hopp kommer att göras eller inte. Dessa tekniker brukar sammanfattas som dynamiska hopprediktioner och innebär att processorn under tiden programmet exekverar på olika sätt skapar en statistik över om tidigare villkorliga hopp gjorts eller inte, för att öka träffsäkerheten på framtida prediktioner. Cortex-A73 använder sig av en teknik som kallas: Two-Level Branch prediction, dvs två-nivå hopprediktion. Denna teknik består av två nivåer och har visats mycket effektiv som teknik för hopprediktion. Tekniken går ut på att man i första nivån har en GHR (Global History Register) som är en bitsekvens som beskriver om tidigare branches har gjorts eller inte. När ett hopp sker skiftas de tidigare bitarna åt vänster för att göra plats åt resultatet från det aktuella hoppet. Längden på bitsekvensen bestäms av hur lång historik som ger den bästa prediktionen i förhållande till hur lång tid det tar att bygga upp en historik. (Lee, Malishevsky, Beck, Schmid and Landry). Denna bitsekvens används senare som address i Pattern History Table, vidare kallat PHT. PHT är en tabell vars rader, entries, består av en adress samt två bitar som beskriver om hoppet skall tas eller inte. Dessa två bitar agerar som ett skiftregister vars tillstånd bestämmer om ett hopp kommer att tas eller inte. De två bitarna symboliserar följande fyra tillstånd: 00: Hoppet kommer med hög säkerhet inte att tas 01: Hoppet kommer förmodligen inte tas 10: Hoppet kommer förmodligen att tas 11: Hoppet kommer med hög säkerhet att tas Beroende av vilket tillstånd registret befinner sig i gör processorn ett beslut vilket med hög sannolikhet kommer stämma när programmet som exekverar beter sig enligt ett mönster. När processorn tagit ett beslut så uppdateras registret beroende av om antagandet var korrekt eller inte enligt Fig.2 där röda pilar symboliserar att hoppet inte togs och gröna pilar symboliserar att hoppet togs. Detta för att kunna göra en mer kvalificerad prediktering nästa gång GHR ser likadant ut. Det finns dock en nackdel till denna teknik. Det tar relativt lång tid för PHT att byggas upp vilket innebär att det kommer att ske många fördröjningar tidigt i exekveringen eftersom en bra predikteringshistorik inte har byggts upp (Mutlu, O 2013) ARM Cortex-A73 använder sig av en PHT med 256 Entries vilket innebär att dess BGH består av 8 bitar för att kunna adressera de 256 entries som finns. Detta innebär att BGH innehåller information om vad som hänt vid de senaste 8 hoppen. Varje unikt fall av de 256 möjligheterna har två bitar som beskriver hur hoppet skall hanteras enligt Fig. 2. Denna teknik implementeras inte av ARM Cortex-A53 då det är en kostsam teknik. Den använder sig istället av en conditional and indirect branching. (Driesen and Hölzle 1997) Detta är en teknik som till viss del kan liknas vid two-level prediction. Man använder sig av samma typ av PHT för att kunna avgöra vilka tidigare hopp som gjorts men man saknar det tvåbitars skiftregister som finns i Cortex-A73, vilket innebär att dess prediktioner inte kommer vara lika precisa som hos Cortex-A73. 6

7

Slutsats ARM Cortex-A73 och Cortex-A53 är två mycket olika processorer där den förstnämnda prioriterar prestanda och den sistnämnda prioriterar effektivitet och kostnad. De två egenskaper som behandlats i denna rapport behandlar parallellism och hantering av hopp. Skillnaden i teoretisk prestanda mellan de två jämförda processorerna är stor då parallellism och hopp är två av de funktioner som ger störst prestandaskillnad i en processor. Att Cortex-A73 använder sig av en two-level branch prediction gör den överlägsen Cortex-A53 när det gäller exekveringstid i program där frekventa hopp sker, exempelvis i program där mycket loopar förekommer eller där samma metoder anropas frekvent. Den är också, i de flesta fall, överlägsen på att hantera många processer parallellt då den kan exekvera beräkningar OoO och på så sätt kan utnyttja hela sin pipeline. Men all denna prestanda kommer till ett pris. Den extra kostnaden hos Cortex-A73 kommer rättfärdiga sig i enheter där kostnaden inte är den viktigaste faktorn utan där maximal prestanda prioriteras. Ett praktexempel på detta är Qualcomm Snapdragon 835 som tillhör företagets prestanda-inriktade serie och exempelvis används i många telefontillverkares flaggskeppsenheter. Då är det viktigaste att kunna exekvera dessa funktioner parallellt och att användaren får en så sömlös användarupplevelse som möjligt. Motsatsen till detta är exempelvis Raspberry Pi 3 som vill ha maximal prestanda för en så liten kostnad som möjligt, där det inte spelar så stor roll om ett program exekverar långsammare så länge det håller kostanden nere. Det finns även andra faktorer som spelar in på en processors prestanda vilket inte har behandlats i denna rapport. 8

Referenser Driesen, K. and Hölzle, U. (1997). Limits of Indirect Branch Prediction. Techincal Report TRCS97-10. Santa Barbara, CA 93106: Department of Computer Science, University of California. http://hoelzle.org/publications/trcs97-10.pdf Prof. Lee, B. Malishevsky, A. Beck, D. Schmid, A. and Landry, E. Dynamic Branch Prediction. ECE 570 High Performance Computer Architecture. Department of Computer Engineering, Oregon State Univerity. http://web.engr.oregonstate.edu/~benl/projects/branch_pred/ Prof. Mutlu, O. (2013). Lecture 11: Branch Prediction. 18-447 Computer Architecture. Carnegie Mellon Univerity https://www.ece.cmu.edu/~ece447/s13/lib/exe/fetch.php?media=onur-447-spring13-lecture11 -branch-prediction-afterlecture.pdf Frumusanu, A. and Smith, R. (2015). ARM A53/A57/T760 investigated - Samsung Galaxy Note 4 Exynos Review. Anandtech.com. https://www.anandtech.com/show/8718/the-samsung-galaxy-note-4-exynos-review/3 [Hämtad 23 Nov. 2017]. Frumusanu, A. (2016). The ARM Cortex A73 - Artemis Unveiled. Anandtech.com. https://www.anandtech.com/show/10347/arm-cortex-a73-artemis-unveiled/2 [Hämtad 23 Nov. 2017] Etsion, Y. 2013. Out-of-order exekvering. Computer Engineering https://iis-people.ee.ethz.ch/~gmichi/asocd/addinfo/out-of-order_execution.pdf 9