1)
Snittkostnad:
2)
Snittkosten går mot når .
3)
Forventet tilgangstid for systemet
= P(Data finnes i ) Tilgangstid for
+ P(Data finnes ikke i ) Tilgangstid for
.
4)
Setter inn for fra c) i uttrykket for E:
5)
1)
Skalar RISC henter en instruksjon pr. sykel, mens superskalar RISC kan vanligvis hente mer enn en instruksjon pr. sykel.
I en superskalar RISC med m enheter, kan opp til m samlebånd være aktive i en base-sykel. En skalar prosessor tilsvarer en superskalar prosessor med m = 1.
En superskalar RISC med m enheter kan ha en ytelse som tilsvarer m ganger en skalar RISC, når vi antar at de har samme klokke-rate og at det ikke er noen data-avhengigheter, kontroll-avhengigheter eller andre ressurs-konflikter mellom instruksjonene.
Både superskalar arkitektur og VLIW-arkitektur har flere funksjonelle enheter. Superskalar arkitektur trenger imidlertid mer avansert maskinvare som f.eks. store ``reorder'' registre og reservasjons-tabeller. Dette er nødvendig for å utnytte ressursene fullt ut. I tillegg trengs programvare løsninger for å håndtere data- og kontroll-avhengigheter og for å øke effektiviteten.
For VLIW-arkitekturer blir instruksjonene ``pakket'' sammen av kompilatoren, slik at flest mulig instruksjoner kan utføres samtidig uten at program-rekkefølge eller algoritme endres. På grunn av denne eksplisitte formen for parallellitet, trengs bare enkel maskinvare- og programvare-støtte under kjøring av programmer. Dekodings-logikk kan f.eks. være enkel.
3)
For skalar CISC eller RISC er bare ett samlebånd aktivt samtidig. I en superskalar RISC kan flere samlebånd være aktive samtidig. For å utnytte alle samlebåndene i en superskalar RISC trengs det derfor avansert maskinvare og programvare. I en VLIW-arkitektur kan flere samlebånd være aktive samtidig. Avanserte kompilatorer samler instruksjoner til lange instruksjons-ord (very long instruction word) slik at flest mulig av de funksjonelle enhetene brukes samtidig.
1)
Data og kode som har nettopp blitt aksessert, vil med stor sannsynlighet aksesseres om igjen, i nær framtid.
Data og kode som har blitt aksessert, vil med stor sannsynlighet ligge i ``nærheten'' av tidligere aksesser.
Utførelses-rekkefølgen av instruksjoner vil følge den sekvensielle program-rekkefølgen.
2)
Arbeids-settet (Eng: the working set) er de adresser eller sider som blir referert i et tidsrom. Sider i arbeids-settet brukes ofte og bør ligge i hoved-lageret.
Hvis vindus-størrelsen er stor, vil de residente sidene omslutte flere lokalitets-regioner og størrelsen på arbeids-settet vil sannsynligvis vokse. En stor vindus-størrelse vil øke treff-raten. Men i et multiprogrammert miljø med mange sider som holdes i hoved-lageret for hver prosess, kan ``trashing'' oppstå. På den andre siden vil en liten vindus-størrelse medføre et mindre arbeids-sett og kan dermed gi en lavere treff-rate siden de aktive brukte sidene endres raskt med tiden.
3)
90-10 regelen: Det har blitt observert at 90% av utførelses tiden blir brukt på ca. 10% av koden. Denne regelen viser at små segmenter av kode utføres flere ganger (løkker) og at data som aksesseres er kontinuerlige elementer i en stor tabell-struktur.