\documentstyle[a4,oving,block]{article-n}

\begin{document}

\Oppgave{

\begin{enumerate}
 \item Snittkostnad:
       \[ C = \frac{\sum_{i=1}^{2} C_{i}S_{i} }{\sum_{i=1}^{2} S_{i}}
       = \frac{C_{1}S_{1} + C_{2}S_{2}}{S_{1} + S_{2}}
       = \frac{C_{1}\frac{S_{1}}{S_{2}} + C_{2}}{\frac{S_{1}}{S_{2}} + 1}
       \stackrel{ {S_{1}/S_{2}} \rightarrow 0}{\longrightarrow} C_{2} \]

 \item Snittkosten g\aa r mot $C_{2}$ n\aa r $S_{1} \ll S_{2}$.

 \item Forventet tilgangstid for systemet $=t_{a}$\newline
       = P(Data finnes i $M_{1}$) $\ast $ Tilgangstid for $M_{1}$\newline
       + P(Data finnes {\em ikke} i $M_{1}$) $\ast $ Tilgangstid for $M_{2}$\newline
       $ = Ht_{1} + (1-H)t_{2} $ .

 \item Setter inn for $t_{a}$ fra c) i uttrykket for $E$:
       \[E = \frac{t_{1}}{t_{a}} = \frac{1}{r + (1-r)H} \]
%\begin{center}
%\mbox{\psfig{figure=lf4-fig1.ps,height=9cm}}
%\end{center}
% Figuren over er laget med gnuplot:
% gnuplot>set ylabel "E"
% gnuplot>set xlabel "H"
% gnuplot>E(r,H) = 1/(r+(1-r)*H)
% gnuplot>set terminal postscript portrait
% gnuplot>set output "/home/pil/b/almli/somjob/ovinger/lf4-fig1.ps"
% gnuplot>plot [H=0:1] E(1,H),E(2,H),E(10,H),E(100,H)
 \item \[ E = \frac{1}{r + (1-r)H} = \frac{1}{100 - 99H} > 0.9
       \Rightarrow {H > 0.998} \]
\end{enumerate}

}



\Oppgave{% 4.4 og 4.5 i Hwang

\begin{enumerate}

\item % 4.4 c i Hwang:

\begin{description}

\item [Instruksjonshenting:]

Skalar RISC henter en instruksjon pr. sykel, mens superskalar RISC
{\em kan vanligvis} hente mer enn en instruksjon pr. sykel.

\item [Samleb{\aa}ndsarkitektur:]

I en superskalar RISC med $m$ enheter, kan opp til $m$ samleb{\aa}nd
v{\ae}re aktive i en base-sykel.  En skalar prosessor tilsvarer en
superskalar prosessor med $m = 1$.

\item [Prosessor-ytelse:]

En superskalar RISC med $m$ enheter kan ha en ytelse som tilsvarer $m$
ganger en skalar RISC, n{\aa}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.

\end{description}

\item % 4.4 d i Hwang:

B{\aa}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{\o}dvendig for {\aa} utnytte
ressursene fullt ut.  I tillegg trengs programvare l{\o}sninger for
{\aa} h{\aa}ndtere data- og kontroll-avhengigheter og for {\aa} {\o}ke
effektiviteten.

For VLIW-arkitekturer blir instruksjonene ``pakket'' sammen av
kompilatoren, slik at flest mulig instruksjoner kan utf{\o}res
samtidig uten at program-rekkef{\o}lge eller algoritme endres.  P{\aa}
grunn av denne eksplisitte formen for parallellitet, trengs bare enkel
maskinvare- og programvare-st{\o}tte under kj{\o}ring av programmer.
Dekodings-logikk kan f.eks. v{\ae}re enkel.

\item % 4.5 i Hwang:

For skalar CISC eller RISC er bare ett samleb{\aa}nd aktivt samtidig.
I en superskalar RISC kan flere samleb{\aa}nd v{\ae}re aktive
samtidig.  For {\aa} utnytte alle samleb{\aa}ndene i en superskalar
RISC trengs det derfor avansert maskinvare og programvare.   I en
VLIW-arkitektur kan flere samleb{\aa}nd v{\ae}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.


\end{enumerate}
}

\Oppgave{%Problem 4.16, Hwang:

\begin{enumerate}

\item 
\begin{description}

\item [Temporal lokalitet:] 

Data og kode som har nettopp blitt aksessert, vil med stor
sannsynlighet aksesseres om igjen, i n{\ae}r framtid.

\item [Romlig lokalitet:]

Data og kode som har blitt aksessert, vil med stor sannsynlighet ligge
i ``n{\ae}rheten'' av tidligere aksesser.

\item [Sekvensiell lokalitet:]

Utf{\o}relses-rekkef{\o}lgen av instruksjoner vil f{\o}lge den
sekvensielle program-rekkef{\o}lgen.

\end{description}

\item

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{\o}r ligge i hoved-lageret.  

Hvis vindus-st{\o}rrelsen er stor, vil de residente sidene omslutte
flere lokalitets-regioner og st{\o}rrelsen p{\aa} arbeids-settet vil
sannsynligvis vokse.  En stor vindus-st{\o}rrelse vil {\o}ke
treff-raten.  Men i et multiprogrammert milj{\o} med mange sider som
holdes i hoved-lageret for hver prosess, kan ``trashing'' oppst{\aa}. 
P{\aa} den andre siden vil en liten vindus-st{\o}rrelse medf{\o}re et
mindre arbeids-sett og kan dermed gi en lavere treff-rate siden de aktive
brukte sidene endres raskt med tiden. 

\item 90-10 regelen:  Det har blitt observert at 90\% av utf{\o}relses
tiden blir brukt p{\aa} ca. 10\% av koden.  Denne regelen viser at
sm{\aa} segmenter av kode utf{\o}res flere ganger (l{\o}kker) og at
data som aksesseres er kontinuerlige elementer i en stor
tabell-struktur.


\end{enumerate}
}

\end{document}
