Cachegrössen und Segmentierung

[Haarmann]

Hi,

Ich wollte hier mal nen paar Anregungen auch loswerden.

Etwas, was mich mal interessieren würde ist der Ausnutzungsgrad der Caches bei diversen CPUs in ihren Betriebsarten (HT/no HT 32/64 Bit).

Gibts da nen Bench oder nen Tool, dass Snapshots machen kann? Wär imho mal interessant zu sehen, wie das so abläuft bei gleichen Aufgaben und unterschiedlichen Architekturen.

Weiss da irgendwer was Genaueres?

[mrdigital]

Ich versteh deine Frage nicht ganz, aber ein CPU Cache wird immer komplett gefüllt sein (Sobald die CPU mehr Daten als die Cachegrösse verarbeitet hat). Wie viele Cachelines in einem Moment gültig sind, hängt von verscheidenen Faktoren ab, der Cachestrategie (Write through, Write Back und Spielarten) und natürlich der Software, die Momentan läuft. Allerdings ist nicht jede gültige Cacheline "sinnvoll", es kann je nach verwendeter Cacheverwaltungsstrategie sein, dass recht viele Cachlines zwar gültig sind aber zu Programmteilen gehören, die Momentan nicht bearbeitet werden (nach einem Taskwechsel z.B.).

[Haarmann]

mrdigital

Immerhin hast verstanden, was mich interessiert.

Setzen wir mal nen AMD64 gegen nen P4E. Beide haben ca 1024KB Cache nutzen den aber anders. Nun wärs doch interessant Folgendes zu machen. Man schaut in beliebigen, aber immer den gleichen, Situationen nach, wieviel des Caches als auch genutzt wird, sprich Daten drin hat, die Valid sind. Das Ganze runden wir aber mit der Messung HT, vs kein HT. Ich finde, dass diese Erkenntnisse sehr aufschlussreich sein könnten.

[mrdigital]

diese Messung geht aber nicht bzw bringt nichts, weil der Cache eigentlich immer mit gültigen Daten gefüllt ist, was interessiert ist die Hit-Rate, d.h ob die gültigen Daten überhaupt von interesse sind. Der Athlon XP / 64 hat gegenüber dem P4 den Vorteil, das sich die Cachegrössen von L1 und L2 Cachegrössen addieren (exclusiv Cache, Daten die im L1 liegen sind nicht im L2) und der P4 hat einen inclusiv Cache (der L1 ist eine schnelle Kopie des L2 Cache), d.h der Athlon hat 128KiB L1 + 1024KiB l2 Cache (ist der L1 64KiB Daten und 64KiB Code oder 128KiB Daten + 128KiB Code?) und der P4 hat eben "nur" 1024KiB Cache. Durch den etwas grösseren Cache kann der A64 einen Vorteil haben, andererseits ist der P4 Cache schneller an den CPU Kern angebunden (zumindest war das beim K7 so).

[Haarmann]

http://www.mstar.de/Cache/index.html#SECTION00400000000000000000

Such mal hier...

Je länger die Linie und je weniger Segmentiert der Cache, desto häuffiger sollten Teile davon quasi leer stehen. Leer heisst auch, dass die Daten schlicht nie abgefragt wurden.
Die geringere Segmentierung sollt dabei dafür sorgen, dass häuffiger getrasht wird.
Ich hoffe nun isses klarer, was gefragt ist und wieso.

[mrdigital]

das habe ich doch gesagt, es stehen im Cache Daten (die gültig sind) aber nichts nutzen. Das bei einer steigenden Line Size dieser "Verschnitt" zunimmt, leuchtet ein, das ist ein Granularitätsproblem. Allerdings kann man einen Cache, der aus wenigen (aber grossen) Lines besteht, leicher verwalten, d.h. die Zugriffszeiten auf den Cache sind kürzer. Es muss nun versucht werden einen Kompromiss zu finden. Allerdings kann man schwer messen, wie viel sinnvolle Daten im Cache stehen, denn ob ein Datum sinnvoll oder nicht ist (gültig ist es ja ohnehinn) ist nunmal eine Frage der verwendeten Applikation und kein "objektives" Kriterium.

[Haarmann]

mrdigital

Messbar wärs imho... Das reicht für mich ums auch mal zu messen. Und vor allem interessierte es mich, wieviel mieser das ist bei doppelter Linelänge und halber Assoziativität.

[mrdigital]

ich glaube, dass sowas nur bedingt Aussagekraft hat, denn das ist doch sehr stark von der eingesetzten Software abhängig, welche Schlüsse willst du dann aus dieser Information ziehen? CPU A kann besser als CPU B mit dieser Software, aber dass kann ich ja auch direkt über die Rechenleistung messen. Von Relevanz ist meiner Meinung nach nur die Hit-Rate im Cache, denn das hat ja wirklich Aussagekraft (wenn man mal für verschiedene Programme das durchmisst und dann einen Mittelwert bildet). Man kann dann Vergleiche anstellen in denen man sehen kann, dass CPU A für eine Hitrate zb. 1MiB Cache benötigt, wohingegen eine andere CPU B mit nur 512KiB die selbe Hitrate leisten kann.

[tatarus]

Der Cache ist ein relativ komplexes Gebilde. Er kann direktabbildend, voll-assoziativ oder n-Wege-assoziativ, was eine Mischung aus direktabbildend und voll-assoziativ darstellt, angeordnet sein. Dazu kommt noch, dass eigentlich jedes Programm, je nachdem wie viele Schleifen vorkommen, unterschiedliche Hitrates hat. Die Zugriffszeit auf Caches hängt auch von ihrer Architektur ab und ist bei jeder CPU verschieden.
Hinzu kommen noch verschiedene Pufferspeicher, die vor dem Beschreiben des Caches gebraucht werden und deren Länge auch variieren kann.

Irgendein Benchmark zum Cache ist daher eher fragwürdig. Der Cache ist sowieso immer voll. Einzig die Anzahl der Fehlzugriffe bei Verwendung desselben Programms(wobei da dann das Betriebssystem wahrscheinlich sowieso alles verfälschen würde) könnte für einem Benchmark verwendet werden.

Generell bringt eine Verdoppelung des Caches ab einem gewissen Pnkt nur noch sehr wenig, da die Funktion Cache(einfach logarithmische Achse zu ld) zu Fehlzugriffe(normale dekadische Achse) exponentiell sinkt.

[Haarmann]

mrdigital

Die schlechtere Hitrate ist nur die Folge meiner Idee der Beobachtung, welche die Ursache davon darstellt.

tatarus

Ich hab oben eben definiert, dass ich als voll nur bezeichne, was je auch abgefragt wurde. Der Rest ist ja nur Ballast, den man nie brauchte und nur Bandbreite und somit Zeit frass.

[mrdigital]

Original geschrieben von Haarmann
mrdigital

Die schlechtere Hitrate ist nur die Folge meiner Idee der Beobachtung, welche die Ursache davon darstellt.

...

Diese Messung (wie viel "sinnvolle" oder "unsinnige") Daten im Cache stehen, hängt doch immer von der Andwendung ab, daher hat das nicht besonders viel Aussagekraft. Vielleicht konstruiert der eine einen Cache, der zwar viel Verschnitt speichert, dafür aber sehr schnell ist, der andere hat weniger Verschitt, aber wegen des höheren Verwaltungsaufwandes auch einen schlechteren Durchsatz. Es ist das P4 vs Athlon Problem, kommst du zu deiner Leistung durch eine hohe Taktfrequenz oder durch "smarte" Technik und so ist es auch mit den Cachestrategien, grosse Cachespeicher mit niedrigerer Effizienz oder kleinere mit hoher Effizienz, letztlich interessiert dabei nur, was hinten rauskommt und das ist halt ne gute (oder weniger gute) Hitrate, denn die lässt sich ja direkt in Zeitersparniss übersetzten (jeder Cachehit verhindert ja ein Transfer aus dem CPU Kern in die langsame Peripheriewelt).