Practicum talstelsels

1COSY1 - 4
http://www.voti.nl/1COSY1
P 1 van 6
Caching
Dit is een individueel practicum.
Student
Sudienummer
In dit practicum gaan we rekenen aan cache systemen en werken met een cache simulator.
Een cache is een geheugen dat tussen een hoofdgeheugen en de gebruiker van dat hoofdgeheugen in
zit. Het cache geheugen is kleiner maar sneller dan het hoofd geheugen. Het doel van de cache is om
zo veel mogelijk geheugen benaderingen (met name lees acties) door de cache te laten afhandelen,
zodat het lijkt of het gecombineerde geheugen systeem (cache + hoofdgeheugen) de omvang van het
hoofdgeheugen heeft, maar de snelheid van het cache geheugen.
Een cache kan je bv vinden tussen de processor en het RAM geheugen (processor cache), maar ook
tussen de processor en een harde schijf (disk cache), of tussen de processor en het internet (web
cache). Voor normaal computer gebruik is vooral de processor cache onontbeerlijk: zonder de cache
zou je computer tergend traag zijn.
We gaan nu eerst wat rekenen. Ga uit van de volgende gegevens (realistisch voor een moderne CPU):
reactiesnelheid hoofdgeheugen
reactiesnelheid cache geheugen
100 μs
1 μs
Om de gemiddelde snelheid van dit geheugensysteem uit te rekenen moeten we ook nog weten
hoeveel hits door de cache worden afgehandeld en hoeveel door het tragere hoofdgeheugen. Als de
cache een hitrate heeft van 80%, dus 80% van de geheugen operaties wordt door de cache
afgehandeld, en 20% door het hoofdgeheugen, dan is dan de gemiddelde snelheid van het geheugen
systeem 0.8 * 1 μs + 0.2 * 100 μs = 20.8 μs. Dat is dus al bijna 5 keer zo snel als hoofdgeheugen,
maar nog wel iets meer dan 4 keer zo langzaam als het cache geheugen.
Als de hitrate 95% is, dus 95% van de geheugen operaties wordt door de cache afgehandeld, en 5%
door het hoofdgeheugen, wat is dan de gemiddelde snelheid van het geheugen systeem? (voor wie dit
niet uit z’n hood kan: Start > run > calc )
1COSY1 - 4
http://www.voti.nl/1COSY1
P 2 van 6
We willen de snelheid van het geheugensysteem flink willen verbeteren. Reken uit wat zinniger is:
a) de snelheid van de cache verhogen (tot bv 0.1 μs)
b) de hitrate van de cache verhogen (tot bv 98%)
Als zeer eenvoudige vuistregel kan je aannemen dat een geheugen-met-cache systeem goed
ontworpen is als ongeveer de helft van de totale geheugen reactietijd wordt bepaald door het
hoofdgeheugen en de andere helft door de cache. De miss-rate (= 1 – hitrate) is dan ongeveer gelijk
aan de verhouding van de snelheden van de cache en het hoofdgeheugen.
Wat moet de hitrate ongeveer zijn voor ons 100 μs / 1 μs geheugensysteem om aan dit criterium te
voldoen?
Een cache is (behalve aan de reactiesnelheid van het systeem) niet waarneembaar voor de gebruiker
(‘transparant’). De truuk van een goede cache is dat hij die geheugen regels (geheugen adressen +
bijbehorende inhoud) bevat die de gebruiker gaat gebruiken. Let op: ‘gaat’ is toekomst. Helaas kan
ook een cache de tekomst niet voorspellen, dus bij het bepalen welke data regels hij moet opslaan kan
hij alleen uitgaan van het verleden. (Resultaten behaald in het verleden…)
De meeste software gebruikt het geheugen niet ‘random’. Als instructie N wordt uitgevoerd, zal in de
meeste gevallen daarna instructie N+1 worden uitgevoerd. Een programma bevat vaak korte loops,
dus het is ook redelijk waarschijnlijk dat in de nabije toekomst instructie N weer wordt uitgevoerd. Als
data op adres Y wordt opgevraagd, dan is er een redelijke kans dat snel daarna de data op adres Y
weer wordt opgevraagd, of anders wel data in de buurt van adres Y. Deze effecten worden localiteit
genoemd.
Wat gebeurt er als de gebruiker (= processor) een geheugen adres opvraagt? Eerst checkt de cache of
hij die geheugen regel heeft opgeslagen. Als dat zo is dan wordt de aanvraag door de cache
afgehandeld, en de processor krijgt dus met de snelheid van de cache de geheugenwaarde
aangeleverd. Zit het opgevraagde adres niet in de cache, dan moet het hoofdgeheugen benaderd
worden, en de processor en cache zitten stil totdat het langzame hoofdgeheugen de waarde heeft
geleverd. Deze waarde wordt aan de processor gegeven en die kan verder. Gezien het
bovengenoemde verschijnsel van localiteit is het waarschijnlijk dat ditzelfde geheugenadres in de
nabije toekomst weer zal worden opgevraagd, dus de cache moet dit adres en de bijbehorende waarde
gaan opslaan. Maar de cache zit al vol, dus er moet een adres dat nu in de cache zit worden
weggegooid.
Welk adres moet er worden weggegooid? Daarvoor zijn in de loop der tijd een aantal strategieën
ontwikkeld, bv:
a) Gooi het oudste (= langst niet gebruikte) adres weg (LRU = least recently used)
b) Gooi het oudste (= langst geleden geladen) adres weg (FIFO)
c) Gooi een willekeurig adres weg (Random)
De eerste optie lijkt op het eerste gezicht erg logisch (en werkt in de praktijk ook erg goed), maar
heeft als nadeel dat er extra hardware in de cache moet worden ingebouwd om van ieder adres te
1COSY1 - 4
http://www.voti.nl/1COSY1
P 3 van 6
onthouden hoe lang geleden het gebruikt is. Bij gelijkblijvende prijs gaat dit ten koste van iets anders,
vaak van de omvang van de cache. De laatste optie lijkt nogal dom, maar werkt in de praktijk voor
een processor cache bijna net zo goed als de alternatieven. FIFO werkt bijna net zo goed als LRU, en
vereist veel minder extra hardware. Voor een disk cache telt het nadeel van ‘extra hardware’ niet
omdat de administratie in software kan worden uitgevoerd. Disk caches, en bv ook de web cache van
je brouwser, gebruiken daarom meestal LRU.
We gaan nu werken met de cache simulator op
http://myweb.lsbu.ac.uk/%7Echalkbs/research/CacheApplet.htm (die link staat natuurlijk ook op de
webpagina van dit practicum). De simulator start in een browser window:
Stel de simulator als volgt in:
Capacity
Speed
Watch
Replacement
Program
Block
Placement
Met de
8
fast
Hits
LRU
Loop, size=6
1-word
Fully associative
knop kan je door het programma heen stappen. Het is een kort lusje:
MOV
MOV
MOV
MOV
LOOP: ADD
MOV
MUL
MOV
CMP
BLE
STP
#0,R0
#0,R1
#2,R1
R1,R2
#1,R0
R0,R2
R1,R0
R1,R2
#256, R0
LOOP
0
Als je door de eerste 8 instructies stapt zie je dat ze worden uitgevoerd en dat de instructies worden
opgeslagen in de (voorheen lege) cache. De volgende twee instructies (CMP #256,R0 en BLE 8) zijn de
9e en 10e, en overschrijven dus de oudste (eerste twee) instructies in de cache (LRU replacement). Na
de “BLE 8” zijn we weer terug bij de 5e instructie, en die zit nog in de cache, en wordt dus door de
cache geleverd. Je ziet de cache entry even opflikkeren. Het zelfde geld voor de volgende instructies:
de loop is korter dan de cache, dus alle instructies in de loop worden (op de eerste keer na) door de
cache geleverd. Uiteindelijk kom je op een STP (= STOP) instructie en je kan links in de simulator zien
wat de performance van de cache is geweest.
1COSY1 - 4
http://www.voti.nl/1COSY1
P 4 van 6
In deze test zijn 42 van de 53 geheugen benaderingen door de cache geleverd, de hitrate is dus 79%.
Wat is, met de snelheden die we eerder aannamen, de gemiddelde snelheid van dit geheugensysteem,
voor dit stukje code?
Welke instructies veroorzaken de cache misses? Wat zal er met de cache hit rate gebeuren als we de
lus niet 7 maar heel vaak (bv 10000 keer) doorlopen?
We hebben nu het LRU replacement algoritme gebruikt, wat in dit geval prima werkte. Selecteer nu
het (theoretisch wat minder goede) FIFO replacement algoritme en test het uit. Je moet de simulator
eerst stoppen en clearen voor je de instellingen kan veranderen en opnieuw kan starten. Wat is het
resultaat van FIFO replacement ten opzichte van LRU replacement? Hoe verklaar je dit? Zou Random
replacement een ander resultaat opleveren?
1COSY1 - 4
http://www.voti.nl/1COSY1
P 5 van 6
Test nu met het “loop, size=12” programma. Zoals de naam al aangeeft is de loop body nu niet 6 maar
12 instructies lang:
MOV #0,R0
MOV R0,TEMP
LOOP:
MUL
MOV
MOV
DIV
MOV
ADD
MOV
ADD
MOV
MOV
CMP
BNE
STP
#0,R4
#2,R1
#4,R5
R5,R1
#2,R2
R2,R3
TEMP,R0
#1,R0
R0,TEMP
#10,R4
R4,R0
LOOP
0
TEMP: DS 1
Bepaald de hitrate met LRU replacement, en met een verschillende cache sizes, en reken de
gemiddelde snelheid van het geheugen systeem uit (met de bekende aannames):
Cache size
Hit rate in %
Snelheid in μs
0
8
16
32
De hit rate bij een cache size van 8 is veel lager dan bij het eerste programma. Verklaar dit.
1COSY1 - 4
http://www.voti.nl/1COSY1
P 6 van 6
Met een cache size van 16 is de hit rate natuurlijk beter dan bij een size van 8. Maar bij het verder
verhogen van de cache size naar 32 neemt de hit rate niet meer toe. Verklaar dit.
Bij een cache zoals we die tot nu toe hebben bekeken kan iedere cache regel een willekeurig geheugen
adres bevatten. Als de cache moet opzoeken of hij het adres dat de processor opvraagt opgeslagen
heeft, dan moet hij dus alle regels bekijken. Vergelijk dit met een bibliotheek waar alle boeken op een
willekeurige plaats kunnen staan. Als je daar snel wil opzoeken heb je 1 assisent per boek nodig: jij
schreeuwt de titel, alle assistenten vergelijken die titel tegelijk (= parallel) met hun boek, en de gene
die het boek heeft schreeuwt terug. Dit is snel, en er zijn geen beperkingen aan waar je een boek kan
opslaan, maar je hebt veel hardware (= assistenten) nodig. Voor een chip betekent dit dat er veel chip
oppervlak gebruikt moet worden voor de comparatoren (een comparator neemt veel meer ruimte in
beslag dan de geheugencel voor het adres), en omdat de comparatoren allemaal tegelijk moeten
werken verbruiken ze dus allemaal stroom, en dat veroorzaakt warmte, wat tegenwoordig vaak een
groter probleem is dan chip oppervalk.
Een oplossing hiervoor is om niet het hele adres te vergelijken, maar een deel, bv alles behalve de
laagste 2 bits. De adressen 0..3, 4..7, 8..11, etc worden zo op 1 hoop gegooid. Dit sluit goed aan bij
moderne RAM hardware: die kan een blok van 4 opeenvolgende adressen bijna net zo snel leveren als
1 los adres. We cachen dus niet meer per adres, maar per blok van 4 adressen.
Gebruik de simulator nu met de volgende settings, kijk wat er gebeurt, en noteer de hit rate. Verklaar
waarom deze cache vorm, met veel minder hardware dan een block=1-word cache, toch beter
presteert.
Capacity
Speed
Watch
Replacement
Program
Block
Placement
Paraaf docent
8
fast
Hits
LRU
Loop, size=6
4-word
Direct mapped