DHBW_AI_16/Rechnerarchitektur_Roethig
1
1
Fork 0
Code Pull requests Releases Activity

[Speicher] Ergänze Abschnitt "Cache bei Mehrprozessorsystemen"

Browse source
This commit is contained in:
Andre Meyering 2017-12-04 09:36:22 +01:00
parent 38fba031e3
commit a85900c418
Signed by: Andre
GPG key ID: 5A1BBB0FB1D4716B
2 changed files with 40 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
Bilder/CPU_Mehrprozessor.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 32 KiB

41
Kapitel/03_Speicher.tex
View file

@ -195,10 +195,11 @@ $\Rightarrow$ sobald das Zugriffsmuster Lokalität aufweist, ergibt sich eine be
Schreibzugriff durch die \acs{CPU} findet im \acl{HS} statt. Parallel dazu müssen die Daten im Cache invalidiert (schlecht) oder ebenfalls geschrieben werden (gut).
\begin{itemize}[leftmargin=5mm]
\item[$\oplus$] optimale Konsistenz der Daten
\item[$\ominus$] Schreiben nur in \acl{HS}-Geschwindigkeit möglich
\item[$\ominus$] Schreiben nur in \acs{HS}-Geschwindigkeit möglich
\end{itemize}
\end{paracol}
\hspace*{-5mm}
\begin{tabular}{p{32mm}|p{62mm}|p{62mm}}
\textbf{Cachearchitektur} \newline \newline \textbf{Schreibstrategie}
& \textbf{Write-Bac}k
@ -603,3 +604,41 @@ Dividieren ist damit überflüssig (alle Zeitscheiben sind gleich lang): Additio
Bei der Verdrängung gibt ein Problem bei der Suche nach der niedrigsten \enquote{Häufigkeit}. \newline
$\Rightarrow$ evtl. Lösung über eine bei Beginn jedes Zeitslots neu aufzubauende verkettete Liste. \newline
\phantom{$\Rightarrow$ }Hier gibt es viel Platz für Optimierungen der \acs{CPU}-Hersteller.
\subsection{Cache bei Mehrprozessor-/Mehrkernsystemen} \index{Mehrkernprozessor}
In \autoref{fig:cpu_mehrprozessor} besitzt jeder Kern einen eigenen Cache. Möglich wäre auch ein gemeinsamer Cache. Verglichen werden diese beiden Möglichkeiten in \autoref{tbl:mehrprozessor_cache}.
\begin{figure}[!ht]
\centering
\includegraphics[width=\textwidth-3cm]{./Bilder/CPU_Mehrprozessor.png}
\caption{Mehrprozessor-/Mehrkernsystem}
\label{fig:cpu_mehrprozessor}
\end{figure}
\begin{table}[ht]
\hspace*{-5mm}
\begin{tabular}{@{}cp{7.6cm}|cp{7.6cm}}
& \textbf{gemeinsamer Cache} & & \textbf{getrennter Cache} \\ \midrule
$\oplus$ & dieselben Daten für beide Kerne benötigt bedeutet nur einmaliges Einlagern im Cache (Platzvorteil).
& $\ominus$ & Dieselben Daten müssen ggf. mehrfach in den Caches gehalten werden.
\\ [4ex]
$\ominus$ & komplexer Bus mit Zugriffsprotokoll (Zeitverlust zumindest bei Zugriffskollision)
& $\oplus$ & einfache 1:1-Verbindungen (kein komplexes Zugriffsprotokoll)
\\ [2ex]
& & $\ominus$ & keine Konsistenz trotz Write-Through Strategie gewährleistet\\
\end{tabular}
\caption{Vergleich von getrennten/gemeinsamen Caches bei Mehrkernsystemen}
\label{tbl:mehrprozessor_cache}
\end{table}
Abhilfe für Inkonsistenz bei mehreren Caches und Mehrprozessorsystemen:
\begin{itemize}[noitemsep]
\item gemeinsamer Cache (ungünstige Performance aufgrund eines Bus)
\item Snoop-Logik, \dash jeder Cache schnüffelt bei den anderen Caches bzw. beim \acs{HS}, welche Daten geschrieben wurden und invalidiert diese ggf. im eigenen Cache.
\end{itemize}
Tatsächlich haben moderne \acsp{CPU} beim L1-Cache getrennte Caches für jeden Kern und beim L3-Cache einen gemeinsamen Cache. Ob eine Snoop-Logik verwendet wird, ist davon abhängig, ob es für das Level notwendig ist oder nicht.