CE_O8. Cacheminne. Hemlaboration 2.

Transkript

1 IS1200 Lösningsförslag till övning CE_O8, 2015 CE_O8. Cacheminne. Hemlaboration Medeltidshistoria Diskutera förloppet då CPU:n gör en läsreferens i huvudminnet dvs information kopieras från huvudminne via bus till CPU. Förklara hur olika blockstorlek inverkar och varför det kan löna sig att hämta flera ord i följd jämfört med enstaka ord. Lösningsförslag: Ett rimligt antagande när det gäller datorer med cache-minne är att de är försedda med ett externt minne, huvudminne (Main Memory-MM, RAM-Minne säger man lite slarvigt i PC-världen) som oftast är av typen DRAM (Dynamiskt RAM) och som är anslutet till CPU-kretsen via en bus, och eventuellt via en eller flera kretsar som brukar kallas chipset. Chipset kretsarna innehåller kontroll-logik för den typ av minneskretar som används i huvudminnet. Om man byter minnnestyp i huvudminnet måste man troligen även byta chipset (dvs man måste byta moderkort). Om man vill arbeta med typiska siffervärden på hur snabb CPU:n och bussen är får man leta efter MHz-angivelser. CPU:n är "snabb" och har idag (2003) ofta en klockfrekvens runt 2 GHz, medan bussen har en klockfrekvens runt 200 MHz. Ibland förekommer siffran 800. En intressant kvalitetsegenskap förutom busfrekvensen är bithastigheten eller "busbandbredd". Bussbandbredd beror av antal bitar på databusen samt hur många överföringar som maximalt kan utföras per busklockcykel. Siffran 800 torde kunna hänföras till en buscykelfart av 200 MHz med 4 överföringar om 64 bitar per buscykel. Bussbandbredden blir då (200 * 4 * 64 )/8 = (800 * 64)/8 MBytes per sekund vilket uträknat blir MByte per sekund. Om det ska överföras information från Main Memory, MM, till CPU krävs tre moment. 1. Överför adressinformation (32 eller 64 bitars adressbuss) från CPU via bus till MM 2. Leta fram datainformation i minnet (64 bitar) 3. Överför datainformation från MM till CPU (64 bitars databus) Räknat i antal busscykler tar detta minst 3 cykler, under förutsättning att man i MM kan få fram informationen inom en busscykel. Det är en rimlig strävan att minneskretsar har en hastighet som är i bra balans med bussfrekvensen dvs att man i bästa fall kan få fram information inom en busscykel. I verkligheten är minneskretsarna ofta komplicerat uppbyggda internt vilket medför att det tar mer än en busscykel att få fram information. Speciellt om man ska leta fram information i minneskretsen på en plats som inte finns i närheten" av den man alldeles nyss refererade. DRAM är ofta organiserat i rader och kolumner och så fort man byter rad, tillkommer extra tid (cykler) för detta. Alltså, i bästa fall tar det en buss (minnes-) klockcykel att få fram information. Om man ska läsa i MM från flera platser som ligger "i samma rad" kan man göra adminstrativa vinster så att den första referensen tar en (eller flera) busscykler och Lösningsförslag Sida 1 av

2 närmast efterföljande tar (exakt) en enda buscykel. Det bygger på att man antingen kan använda bussen med pipe-line teknik och överlappa de tre stegen ovan tidsmässigt, eller att minneskretsen internt sparar och uppdaterar aktuell adress så att informationen hämtas från platser som ligger "i rad" i kretsen. Detta innebär att om CPU:n efterfrågar 4 enheter i rad från MM så kommer medelhämtetiden per enhet att bli lägre än om CPU:n bara hämtar en enhet i taget. Man för ett referensmönster där siffrorna anger bästa tänkbara utfall räknat i busscykler per hämtad enhet. Medelhämtetiden blir ( )/4 busscykler dvs 1,5 busscykel per enhet om man hämtar 4 i rad jämfört med 3 busscykler per enhet om man hämtar en enhet i taget. Sammanfattning: Om man ökar blockstorleken vid (läs-) referenser från CPU:n till MM kan man minska medeltid per läsreferens. Denna tidsvinst kan man ta vara på om man lyckas hämta in information som kommer att användas. Om inhämtad information inte används får man i stället en större medelhämtetid per enhet. Om man exempelvis hämtar in 4 enheter men bara använder 1 enhet blir ju medelhämtetiden för denna enda enhet 6 busscykler i stället för 3 om man bara hade hämtat in just den. Slutsats: För att det ska vara någon vits/vinst med att hämta in flera enheter vid varje referens till MM krävs 2 saker: 1. Medelhämtetiden per enhet ska minska vid ökad blockstorlek 2. Sannolikheten att alla inhämtade enheter används, ska vara (tillräckligt) stor. Parentes: Minneskretsar som kan leverera 4 enheter per klockcykel kan använda en teknik som kallas interleaving, vilket kortfattat innebär att man delar in minnet i 4 delar som arbetar parallellt men förskjutet 1/4 klockperiod i tiden. Var och en av de fyra enheterna levererar en enhet per (sin) klockperiod. Accessmönster torde kunna bli 3-1/4-1/4-1/4. Detta ger inte så stor utdelning jämfört med vid små block men vid tillämpningar med "streaming data", dvs jättestora block, kan man få hög bussbandbredd. Lösningsförslag Sida 2 av

3 8.2. Referenslokalitet: tidslokalitet och rumslokalitet Vad menas med att ett program vid sin exekvering har lokalitetsegenskaper: tidslokalitet och rumslokalitet? Försök ge förslag på ett program som vid sin exekvering har dålig lokalitet (noll?) och diskutera vilken inverkan det har vid användning av cache. Lokalitetsegenskaper finns både i program och data. Diskutera hur man kan skriva sina program för att öka lokaliteten. Lösningsförslag: Vi tar en lokalitetsegenskap i taget. Tidslokalitet innebär: Om man har refererat minnet på en viss adress är det mer sannolikt att just denna minnesadress refereras snart igen (återanvndning) jämfört med sannolikheten att referera andra godtyckliga adresser. Typexempel på "återanvändning" av information i minnet finns i programloopar samt i datareferenser där man gör Read-Modify-Write och det gör man typiskt av loopräknare och indexvariabler. Även vid beräkningar görs ofta Read-Modify-Write av en variabel som lagras i minnet. Ett exempel på ett program som saknar tidslokalitet är alltså ett program utan loopar (med enbart "rak kod") som aldrig gör dubbla referenser till samma data-area. (Ytterligare tänkvärda frågor: Ett vanligt typiskt program innehåller tidslokalitet. Kan man ange ett siffervärde på hur "stor" tidslokalitet ett program har? Kan man på något sätt be kompilatorer att försöka öka tidslokaliteten? Kan kompilatorn öka antalet loopar?) Rumslokalitet innebär: Om man har refererat minnet på en viss adress är det mer sannolikt att nära liggande minnesceller refereras jämfört med sannolikheten att referera andra godtyckliga adresser. Typexempel på rumslokalitet finns i raka programdelar där en följd av instruktioner finns lagrade efter varandra i minnet, och bearbetning av data i matriser som normalt lagras i rad i minnet och som refereras i rad i minnet. Ett exempel på program som saknar rumslokalitet är ett program med extremt många hoppinstruktioner (kan man ha hopp i varje instruktion?) och bearbetning av data som ligger helt slumpvis i minnet (allt annat än organiserat systematiskt i matriser eller vektorer). (Ytterligare tänkvärda frågor: Ett vanligt typiskt program innehåller rumslokalitet. Kan man ange ett siffervärde på hur "stor" rumslokalitet ett program har? Kan man på något sätt be kompilatorer att försöka öka rumslokaliteten? Placera mest sannolika programvägen i en rak sekvens. Allokera datastrukturer som är anpassade till referensmönster typ rad/kolumn i matrisarbeten.) Lösningsförslag Sida 3 av

4 8.3. Adressering i Main Memory och Cache Memory Antag att Main Memory, MM, har en viss storlek, t.ex. 3x128 Mbyte (384 Mbyte) Hur många adressbitar krävs för adressera MM dvs att kunna peka ut varje enskild byte i MM. Visa hur adressen ovan delas upp i olika fält för att ange var i ett cacheminne man ska lagra den information som pekas ut i Main Memory. Antag att cacheminnet innehåller 16 Kbyte och man vid varje referens till Main Memory överför ett block om 4 Word om vardera 64 bitar (8 byte)). Visa för olika fall enligt nedan. Visa även hur antal bitar i de olika fälten i adressen ändras om man ändrar storlek respektive blockstorlek i cacheminnet. a) Direkt adressavbildning (1-vägs associativ adressavbildning) b) 2- och 4-vägs mängdassociativ adressavbildning c) Fullt associativ adressavbildning Lösningsförslag: En bra minnesregel är att man med 10 binära bitar kan peka ut 1024 platser. Man säger då t.ex. att man med 10 bitar kan adressera varje byte i ett minne om 1 KByte. Med 20 bitar kan man adressera 1024x1024 platser dvs varje byte i ett minne med 1 MByte (1K gånger 1K blir 1M). Nu har vi 3 x 128 MByte. 128 MByte kan vi adressera med 20 bitar + ytterligare 7 bitar för att välja 1 av 128 (MByte) och ska vi sen klara att välja en av de tre 128 MByte delarna krävs ytterligare 2 bitar som troligen har värden 00, 01 och 10 för att välja mellan tre stycken 128 MByte områden. Sammanglatt behövs alltså 29 bitar (klarar egentligen 4 x 128MByte = 512 MByte). Om man i ett cacheminne som rymmer 16 KByte ska kunna peka ut varje enskild byte krävs en adress med 14 bitar. Den adress som pekar ut en byte i MM används för att peka ut en byte i cachen genom att de minst signifikanta bitarna används för att peka ut en byte i cachen. Alltså används de 14 minst signifikanta bitarna för att adressera cachen. Vid varje överföring mellan MM och cache överförs ett block om 32 byte. Denna enhet kallas för block size eller line size. I adressen används tillräckligt många minst signifikanta bitar för att kunna peka ut en enskild byte inom ett block. Eftersom varje block innehåller 32 byte behövs i vårt exempel 5 bitar för detta ty 2 upphöjt till 5 är 32. Vi får då 9 bitar kvar för att använda som INDEX-bitar till block eller rad. a) För ett cacheminne som använder direkt adressavbildning gäller att varje byte/block i MM bara kan lagras på en enda tillåten plats i cachen, och den platsen anges av värdet på bitarna i INDEX-fältet i adressen. Om man ska kopiera information från en viss plats i MM till cache-minnet kan data placeras på en enda plats i cachen. På denna plats i cachen kan man placera data från många olika platser i MM. På något sätt måste man kunna ta reda på vilka data som just nu finns i cachen. Genom att lagra en adresslapp, TAG, i varje block/rad i cachen kan man bokföra varifrån i MM man hämtat data till utpekad rad. TAG- Lösningsförslag Sida 4 av

5 informationen som lagras i cachen tillsammans med ett block utgörs av de mest signifikanta bitarna i adressen till det block som finns i cachen. I detta exempel blir det 15 bitar i TAG-fältet. Vid läsning av ett block från MM görs en undersökning om detta block finns i cachen genom att jämföra adressens TAG (lagom många mest signifikanta bitar) med det TAG-värde som finns lagrat i cachen på den enda plats där aktuellt block kan vara lagrat, dvs den rad som pekas ut av INDEX-bitarna. Om dess TAG-bitar är lika så finns data i cachen och man har en cache-hit. Av adressens 29 bitar har vi nu fått ett BYTE-i-BLOCK om 5 bitar, ett INDEX-fält om 9 bitar och ett TAG-fält om 15 bitar (de bitar som blir över). Från början är cachen tom, och för att administrera detta finns för varje rad i cachen en extra VALID-bit som med värde 0 markerar "tomt" och med värde 1 markererar "valid". För att tolka en cacheminnesreferens som en HIT krävs att utpekad valid-bit är ettställd dvs anger "valid". b) Vid fullt associativ adressavbildning gäller att ett block av information som ska kopieras från MM till cache får placeras på vilken rad som helst i cachen. Detta försvårar administrationen. Dels måste man när man ska skriva till cachen leta reda på en ledig plats, och dels måste man när man vill leta efter information i cachen jämöra aktuellt TAG-värde i adressen med samtliga befintliga TAG-värden i cachen (för de rader vars VALID-bit är ettställd). Dessutom tillkommer uppgiften att, när cachen är fullskriven, välja vilken plats som man ska skriva till då ny information ska skrivas till cachen. Detta senare kallas utbytes-algoritm. Adressen, om 29 bitar, delas upp i BYTE-i-BLOCK som kräver de 5 minst signifikanta bitarna precis som i a) och övriga 24 bitar blir TAG-fält. Ett fullt associativt cacheminne kräver alltså större administrativ plats för att lagra större TAG-fält. Det finns inga bitar alls i INDEX-fältet eftersom man inte behöver välja mellan olika tänkbara platser i cachen utan cachen består av en enda rad. c) 2-vägs mängdassociativ adressavbildning, 2-way set associative mapping, 2-vägsassociativt cacheminne. I detta fall kan varje utpekat block i MM lagras på två olika platser i cachen. Man kan illustrera detta på olika sätt. Antingen delar man in hela cachen så att man grupperar rader 2 och 2 (liknande fig 6.11 i kursboken) eller också ritar man cachen "dubbelt så bred" så att varje rad innehåller två block (som man gör i cache-simulatorn till hemlaboration 2). I denna lösning väljer vi att placera 2 block per rad för ett 2-vägs associativt minne. Effekten blir att vi får hälften så många rader som i uppgift a) men 2 block per rad i stället för ett block som vi hade i a). Adressens 29 bitar delas nu upp i följande fält. För att ange BYTE-i-BLOCK behövs fortfarande 5 minst signifikanta bitar. För att ange vilken enda rad (exakt vilka 2 block) i cachen som informationen kan vara lagrad krävs endast 8 bitar eftersom det bara finns 256 rader (med vardera 2 block dvs bytes vilket blir 16 KBytes). Detta medför att resten av bitarna, dvs = 16 bitar ska lagras i TAG-fältet. Då vi ändrar minnet från direktavbildande (associativitet 1) till 2-vägs associativitet Lösningsförslag Sida 5 av

6 (dubblar associativiteten) kommer antalet bitar i TAG att öka med 1 och antalet bitar i INDEX att minska med 1, medan antal bitar i BYTE-i-BLOCK är oförändrat. Om vi ökar associativiteten från 2 till 4 och illustrerar det genom att öka bredden till 4 block och minska antal rader, höjden, till häften, kommer ytterligare en bit att "flyttas" från INDEX till TAG dvs gränsen mellan TAG och INDEX förskjuts ett steg åt höger. Varje gång vi dubblerar associativiteten "flyttas" en bit från INDEX-fältet till TAGfältet. Vi måste öka storleken på kiselytan i cachen för att lagra administrativ information. Sammanfattning: Totala antalet bitar i adressen till ett byteadresserat MM bestäms av storleken på MM. Totala antalet bitar i adressen till en byteadresserad cache bestäms av storleken på cachen. Antal bitar i BYTE-i-BLOCK bestäms av blockstorleken. Antal bitar i INDEX-fältet beror av antal rader (eller set) i cachen Antal bitar i TAG-fältet blir "resten" av bitarna 8.4. Analys av träff och miss i cache-minne Se lösningsförslag till tentamen , uppgift 4. Lösningsförslag Sida 6 av

7 8.5. Analys av träff och miss i cache-minne Cacheminnet är tomt när rad 1 körs. rad 1 movia r8, 0x80a700 ; lägg adress i r8 rad 2 ldw r12,0(r8) ; läs 4 bytes från adress 0x80a700 rad 3 ldw r13,4(r8) ; läs 4 bytes från adress 0x80a704 rad 4 stw r14,20(r8) ; skriv 4 bytes till adress 0x80a714 rad 5 ldw r15,12(r8) ; läs 4 bytes från adress 0x80a70c rad 6 ldw r16,256(r8) ; läs 4 bytes från adress 0x80a800 rad 7 ldw r17,20(r8) ; läs 4 bytes från adress 0x80a714 a) Är tidslokaliteten stor eller liten för instruktionshämtningarna när en dator kör assemblerkoden ovan? Svar: varje instruktion hämtas (och utförs) bara en gång, det finns ingen loop. Därför finns ingen tidslokalitet alls för instruktionshämtningarna. Är rumslokaliteten stor eller liten för instruktionshämtningarna? Svar: när en instruktion har hämtats så hämtas därefter nästa instruktion i adressordning. Det betyder att rumslokaliteten är bra när en adress har lästs så kommer ju snart en mycket näraliggande att läsas. b) Är tidslokaliteten (re-use) stor eller liten för läsning/skrivning av data när en dator kör assemblerkoden här ovanför? Svar: alla läsningar och skrivningar använder olika offsets från r8, så inget dataord läses eller skrivs mer än en gång. Det finns alltså ingen tidslokalitet (no re-use). Är rumslokaliteten (locality) stor eller liten för läsning/skrivning av data? Svar: läsningarna (och skrivningen) gäller huvudsakligen ett litet minnesområde nära adress 0x80a700, så rumslokaliteten är god. c) För varje ldw och stw i assemblerkoden här ovanför, ange om den ger träff eller miss i datacacheminnet (D-cache). Storlek (cache size): 256 byte (64 ord). Blockstorlek (line size): 8 byte (2 ord). Associativitet (blocks in set): 1-vägs (direktmappat). Datacacheminnet ser ut som på bilden till höger. Läsningar/skrivningar är markerade i cacheminnet. rad 1 movia r8, 0x80a700 ; ingen load eller store, påverkar alltså inte D-cache rad 2 ldw r12,0(r8) ; miss, cache-minnet är ju tomt rad 3 ldw r13,4(r8) ; träff, läs 4 bytes i samma block som rad 2 rad 4 stw r14,20(r8) ; miss, skriv till tidigare oanvänt block rad 5 ldw r15,12(r8) ; miss, läsning från ny plats i primärminnet rad 6 ldw r16,256(r8) ; miss, läsning från ny plats i primärminnet rad 7 ldw r17,20(r8) ; träff, läs samma som rad 4 rad rad 3 rad 5 rad Lösningsförslag Sida 7 av

8 d) Ändring av blockstorlek (block size), jämfört med deluppgift c. För varje ldw och stw i assemblerkoden här ovanför, ange om den ger träff eller miss i datacacheminnet (D-cache). Storlek (cache size): 256 byte (64 ord). Blockstorlek (line size): 64 byte (16 ord). Associativitet (blocks in set): 1-vägs (direktmappat). Datacacheminnet ser ut som på bilden här nedanför. Läsningar/skrivningar är markerade i cacheminnet. rad 2 rad 3 rad 5 rad 4 rad 1 movia r8, 0x80a700 ; ingen load eller store, påverkar alltså inte D-cache rad 2 ldw r12,0(r8) ; miss, cache-minnet är ju tomt rad 3 ldw r13,4(r8) ; träff, läs 4 bytes i samma block som rad 2 rad 4 stw r14,20(r8) ; träff, läs 4 bytes i samma block som rad 2 rad 5 ldw r15,12(r8) ; träff, läs 4 bytes i samma block som rad 2 rad 6 ldw r16,256(r8) ; miss, läsning från ny plats i primärminnet ; läsningen gör att översta cacheminnesraden skrivs över rad 7 ldw r17,20(r8) ; miss, översta raden skrevs ju över med nya data nyss e) Ändring av associativitet (blocks in set), jämfört med deluppgift c. För varje ldw och stw i assemblerkoden här ovanför, ange om den ger träff eller miss i datacacheminnet (D-cache). Storlek (cache size): 256 byte (32 ord). Blockstorlek (line size): 8 byte (2 ord). Associativitet (blocks in set): 4-vägs associativt. Utbytespolicy: LRU, Least Recently Used. Datacacheminnet ser ut som på bilden här nedanför. Läsningar/skrivningar är markerade i cacheminnet. rad 2 rad 3 rad 5 rad 4 rad 6 rad 1 movia r8, 0x80a700 ; ingen load eller store, påverkar alltså inte D-cache rad 2 ldw r12,0(r8) ; miss, cache-minnet är ju tomt rad 3 ldw r13,4(r8) ; träff, läs 4 bytes i samma block som rad 2 rad 4 stw r14,20(r8) ; miss, skriv till tidigare oanvänt block rad 5 ldw r15,12(r8) ; miss, läsning från ny plats i primärminnet rad 6 ldw r16,256(r8) ; miss, läsning från ny plats i primärminnet rad 1 ldw r17,20(r8) ; träff, läs samma som rad 4 Lösningsförslag Sida 8 av

9 8.6. Cache-minnes-prestanda för program med slingor (loopar) Varje loop upptar 30 respektive 60 platser/ord. Loop1 med 30 ord ryms ej i en cache med bara 16 ord, men får plats i en cache med 32 ord. Loop2 med 60 ord ryms ej i en cache med 32 ord men får plats i en cache med 64 ord a) Då storleken dubbleras från 16 till 32 ord-platser kommer hit rate att öka märkbart på grund av att hela loop1 men inte loop2 nu ryms i cachen vilket den inte gör om cachen bara rymmer 16 ord. b) Då storleken dubbleras från 32 till 64 ord-platser kommer hit rate att öka märkbart på grund av att hela loop1 och nu även loop2 ryms i cachen vilket de inte gör om cachen bara rymmer 32 ord. c) Då associativiteten ökar från 1 till 2 kommer hit rate att ändras obetydligt. När loop1 exekveras ryms hela loopen i cachen oberoende av associativitet och likadant gäller för loop2. d) Då storleken ökar från 2 ord per block till 8 ord per block kommer hit rate att öka obetydligt eftersom programkörningen största delen av tiden hämtar instruktioner i looparna vilket inte ger några missar, eftersom varje loop ryms var för sig i cachen. Den lilla ökningen beror på att för detta program får färre missar första gången man refererar ord i loop1 eller loop2 eftersom man vid varje miss hämtar in 8 ord i stället för 2 ord. Med 2 ord per block får man miss vid varannan intruktionshämtning men med 8 ord per block får man miss vi var 8:e instruktionshämtning. e) Exekveringstiden kommer att minska i fall a) eftersom antal missar vid instruktionshämtning i loop1 minskar och därmed miss penalty minskar. Samma gäller i fall b) för loop2. I fall c) kommer exekveringstiden ändras obetydligt, eftersom hitrate ändras obetydligt. I fall d) kommer exekveringstiden att obetydligt minska, pga minskat antal missar. Minskningen förutsätter att medeltid per minnesreferens minskar vid ökad blockstorlek. (Med ökad blockstorlek försöker man ta vara på rumslokalitet genom att vid en miss passa på att hämta in information både från den refererade adressen och ett antal efterföljande (eller näraliggande) adresser. Om dessa andra adresser verkligen refereras och dessutom medeltiden per minnesreferens är lägre vid stora block än vid små block kan man minska exekveringstiden genom att öka blockstorlek.) Lösningsförslag Sida 9 av

10 8.7. Cache-minnes-prestanda för matrisberäkning a) Finns tidslokalitet och/eller rumslokalitet för instruktionsreferenserna i programmet? Lösningsförslag: Ja, det finns tidslokalitet: programmet kör en slinga (loop), och instruktionerna i loopen kommer att hämtas om och om igen, så många gånger som programmet kör varv i loopen. Ja, det finns rumslokalitet: efter varje instruktionshämtning så hämtas normalt nästa instruktion i adressordning vilket är en näraliggande adress. b) Finns tidslokalitet och/eller rumslokalitet för datareferenserna i programmet? Lösningsförslag: Nej, det finns inte tidslokalitet: varje arrayelement används bara en gång i detta program. Tidslokalitet är när samma minnescell läses/skrivs flera gånger med kort tidsmellanrum. Ja, det finns rumslokalitet: inom varje array går programmet igenom elementen i nummerordning, vilket gör att datorn kommer att gå igenom dem i adressordning. Rumslokalitet är när en minnescell lästs/skrivits, så läses/skrivs snart en annan minnescell med näraliggande adress, och det kommer att stämma in på datareferenserna eftersom programmet går igenom elementen i nummerordning inom varje array, vilket gör att datorn kommer att gå igenom dem i adressordning. c) Beräkna hit-rate för datacacheminnet (D-cache), när funktionen saxpy körs. Storlek (cache size): 512 byte (128 ord). Blockstorlek (line size): 32 byte (8 ord). Associativitet: direktmappat (direct-mapped). Lösningsförslag: Cacheminnet är lika stort som en array, och arrayerna ligger direkt efter varandra i minnet. Det gör att element 0 från arrayen y krockar med element 0 från arrayen x, och att båda krockar med element 0 i arrayen s. Alla elementen ska in på samma plats i cacheminnet, och då kan cacheminnet inte utnyttja rumslokaliteten i programmet. Hit-rate blir 0%. d) Ändring av storlek (cache size), jämfört med deluppgift c. Beräkna hit-rate om storleken halveras; beräkna också hit-rate om storleken fördubblas. Blockstorlek och associativitet ändras inte när storleken ändras. Lösningsförslag: Halverad storlek medför att storleken hos en array är 2 gånger storleken på cacheminnet, och 2 är ett heltal. Eftersom arrayerna ligger direkt efter varandra i minnet så kommer element 0 från arrayen y fortfarande att krocka med element 0 från arrayen x, och båda krockar med element 0 i arrayen s. Alla elementen ska in på samma plats i cacheminnet, och då kan cacheminnet inte utnyttja rumslokaliteten i programmet. Hit-rate blir 0%. Fördubblad storlek medför att storleken hos en array är ½ gånger storleken på cacheminnet. Arrayerna ligger direkt efter varandra i minnet, så x[0] och y[0] kommer inte att krocka avståndet mellan dem är 0,5 gånger cacheminnets storlek, och 0,5 är ju inget heltal. Däremot så kommer x[0] och s[0] att krocka. Tidslinjen blir som följer. Lösningsförslag Sida 10 av

11 Tidpunkt 1: läs x[0] miss, cacheminnet hämtar från och med x[0] till och med x[7]. Tidpunkt 2: läs y[0] miss, cacheminnet hämtar från och med y[0] till och med y[7]. Tidpunkt 3: skriv s[0] miss, cacheminnet kastar x[0] x[7] och hämtar från och med s[0] till och med s[7], och skriver sedan s[0]. Tidpunkt 4: läs x[1] miss, cacheminnet kastar s[0] s[7] och hämtar från och med x[0] till och med x[7]. Tidpunkt 5: läs y[1] träff Tidpunkt 6: skriv s[1] - miss, cacheminnet kastar x[0] x[7] och hämtar från och med s[0] till och med s[7], och skriver sedan s... Detta fortsätter tills... Tidpunkt 22: läs y[7] träff Tidpunkt 23: skriv s[7] - miss, cacheminnet kastar x[0] x[7] och hämtar från och med s[0] till och med s[7], och skriver sedan s Tidpunkt 24: läs x[7] miss, cacheminnet kastar s[0] s[7] och hämtar från och med x[1] till och med x[7]. Tidpunkt 25: läs x[8] miss, cacheminnet hämtar från och med x[0] till och med x[7]. Tidpunkt 26: läs y[8] miss, cacheminnet hämtar från och med y[0] till och med y[7]. Tidpunkt 27: skriv y[8] miss, cacheminnet hämtar från och med y[0] till och med y[7]. Vi kan se att tidslinjen blir: M, M, M; M, T, M; M, T, M; M, T, M; M, T, M; M, T, M; M, T, M; M, T, M; sedan upprepar den sig: M, M, M; M, T, M;... Från tidslinjen ser vi att vi har en hitrate på 7/24 29%. e) Ändring av associativitet (blocks in sets), jämfört med deluppgift c. Beräkna hit-rate om associativiteten ökas till 2; beräkna också hit-rate om associativiteten ökas till 4. Storlek och blockstorlek ändras inte då associativiteten ändras. LRU är den utbytesalgoritm som ska förutsättas. Lösningsförslag: Fördubblad associativitet innebär att vi får halva antalet rader i cacheminnet. Den cacheminnesstorlek som ska användas för att räkna på eventuella krockar halveras också. Vi får en situation som liknar den med halverad storlek i deluppgift d. Här i e-uppgiften så finns visserligen två olika platser på samma rad, men LRU i kombination med frånvaro av tidslokalitet för data medför att ett element från s kommer att kasta ut element från x, ett element från x kastar ut element från y, och ett element från y kastar ut element från s. Hitrate blir 0%. Med fyrdubblad associativitet uppstår inga krockar, och hitrate blir 7/8 87% Lösningsförslag Sida 11 av