Gibt es eine Software zum Auslesen, wie viel CPU-Cache ein Programm maximal benötigt?

[latiose88]

Hi bin dabei herauszufinden wo das Limit ist.
Darum will ich ja wissen wie viel cache bestimmte Programm bei ner CPU so benötigen. Die misses also fehlschalge ebenso. Habe zwar ein Tool in English von AMD aber voran kam ich nicht und konnte es daher nicht testen. Gibt es denn noch weitere Programme wo man das testen lassen kann?
Bei festen kernen gibt es ja process lasso aber man kann da ja nur fest einer Anwendung die Kerne zuordnen.

Nun ich will damit einschätzen wie viel cache mehr an mehr Leistung bringt.
Ich gehe mal und das sagt mir mein Gefühl davon aus das der noch mehr Cache keine Leistungs Steigerung mehr gibt.

Und das ram und cache ja getrennt von einander funktioniert. Und wenn mal was benötigt wird es dann einen Teil des RAMs in den cpu Cache ladet.

Naja mehr brauche ich echt nicht mehr zu schreiben. Und wer weiß vielleicht kann ich ja noch was optimieren und noch mehr herauszuholen. Mal sehen.

[Marscel]

Auf Linux gibt es Cachegrind, und auch mit UI (https://kcachegrind.github.io/html/Home.html). Auf Windows Computern mit Intel CPU auch V-Tune.

Andererseits ist deine Frage auf der falschen Seite:

1. Programme brauchen per sé Arbeitsspeicher, keinen CPU-Cache. Größe und Hierarchie dessen sind erstmal komplett ungreifbar für den Softwareentwickler. Der Compiler kann noch Registernutzung am anderen Ende der Hierarchie regeln, aber auch der kriegt nur einen schmalen Rahmen für könnte Cache-freundlicher sein, das so zu machen, abhängig davon, wie die Softare kompiliert wurde.

2. Geh mal davon aus, dass reservierter und tatsächlich benutzter Arbeitsspeicher >> Cache-Größe. Angesichts dessen ist es schon falsch von "benötigen" zu sprechen. Rein rechnerisch, und nur das, benötigt das Programm immer so viel Cache wie Arbeitsspeicher, damit alles richtig flott ist.

Aber gut, was kann eine Software machen:

1. Kram zeitnah abhandeln und dann sein lassen (zeitliche Lokalität). Also wenn irgendwas im Cache liegt, egal was sonst so drin ist, ist die Chance höher, dass der Cacheeintrag dafür bleibt, weil die Chance auf eine Cache-Eviction durch etwas anderes in kurzer Zeit niedriger ist.

2. Kram nah beieinander verwenden (speicherräumliche Lokalität). Caches haben ja Cache Lines von einigen Bytes. Zwei Stücke Daten, die im RAM aufeinander folgen und so gebraucht werden, sind also so mit einem Load im Cache, nicht mit zwei + potentieller Eviction. Bei Programmierung mit größeren Datenobjekten mitunter tückisch, wenn irgendwas davon in eine kühle Cache-Line überhängt, evicted wird und dann bei Zugriff die Performance herunterzieht.

3. Sachen aus 1. und 2. nicht wieder blind von verschiedenen Cores abrattern lassern, wenn mindestens einer davon schreibt. Die Caches der Cores müssen kohärent gehalten werden, und das gibt es mWn auch immer noch nicht für lau.

Und auch das sind alles eher gute Absichten und Best-Practices, um es auf Software-Seite nicht fahrlässig zu verhauen. Konkret muss man sich dann auch die laufende Hardware angucken: Irgendein spezielles Problem mag in der Hinsicht noch auf einem Celeron gut laufen, ein anderes vielleicht erst auf Ryzen 7, und manches ist vergebene Mühe.

Fazit:

1. Du hast ein Program, das macht bei der Lokalität alles ziemlich gut. Leider sind die Caches doch noch zu klein, und so wird es immer wieder Misses geben. Dann hättest du ziemlich gute Chancen, dass ein fetterer Prozessor Upspeed bringt.

2. Du hast ein Program, das macht bei der Lokalität alles ziemlich gut. Im Rahmen seiner Operationen kann das allermeiste von den Caches gepuffert werden. Hier bringt noch dickerer Cache eher nichts mehr.

3. Du hast ein Program, das ohne Rücksicht auf Cache-Freundlichkeit entwickelt wurde. Die Caches wären theoreitsch noch passend für sehr viele Operationen, allerdings sind Code und Daten einfach zu versprenkelt benutzt, sodass eigentlich ständig eine bestehende Cache-Line geopfert und später wiedergeholt werden muss. Hier würde ein größerer Cache vielleicht ein bisschen was retten, in erster Linie sollte man aber mal die Software dahin optimieren.

Wenn du mit einem Tool wie da oben jetzt viele Misses siehst, dann kannst du die CPU tauschen und gucken, ob doppelt so viele Cache die Miss-Rate halbiert. Wenn nicht, oder nur unwesentlich: Red mit den Softwareentwicklern. Tätig werden würden die vermutlich aber auch erst dann, wenn sich für die Gesamtanwendung z. B. dadurch schlechte Performance entfernen lässt, und nicht nur weil das Logging-System dir deine Counter versaut.

[latiose88]

ah ok ich habe jedoch ein AMD System mit WIndows 10,gibt es da denn auch was dazu?
Oder kann ich da auch das Tool wie das von Intel hernehmen?

Und wie Verhält sich das ganze denn mit 2 gleichen Programmen gleichzeitig,das wo das selbe macht aber unterschiedliche Sachen machen.WIe Video 1 wird von Software 1 umgewandelt und Video 2 von Software 2 aber halt nicht die gleichen.Wäre schon interessant wie sich da es bezüglich Software verhält.
Was ich auch gemerkt habe das mehr L3 Cache nicht zu mehr Leistung geführt hat.Ich gehe mal davon aus,es passt wohl noch immer nicht ganz in den CPU Cache weil dann müsste es ja 2x250 MB CPU Cache haben,das der gesammte Ram Inhalt im CPU Cache sich befindet oder ist das zu einfach gedacht das ganze?

[HisN]

Eventuell passt ja Dein Recoder komplett in den Cache.
Aber Deine Videofiles nicht.
Kann man das auseinanderhalten? Ansonsten ist jedes Laden vom nächsten Video-Daten-Block ein Cache-Miss.

[latiose88]

Was meinst du denn mit recoder damit?

Was heißt da auseinander halten. Also ich habe da bei beiden unterschiedliche auslastung der cpu in %. Also denke ich mal wird das wohl das Programm schon richtig machen. Also bisher habe ich noch nie fehlerhafte Videos gehabt. Merkt man ja bei der Wiedergabe oder kann man sich nicht drauf verlassen. Oder verbessert die CPU das autatisch nach?

Achja dieses misses führen ja dazu das es länger dauert nehme ich mal an.
Ich merke von 1 auf 2 gleichzeitig schon eine um 20 Sekunden längeres dauern. Bei Intel ist es aufgrund größeren tsktes etwa abgemildert.

Bei videos mit ner höheren Auflösung jedoch merke ich das ansteigen des RAM Verbrauchs das sich verdoppelt und es viel länger dauert. Da wird wohl irgendwo ein Engpass beim Cache sein. Ist das dies wo ihr gemeint hattest mit den misses und so?

[HisN]

Recoder: X-Media Recode
Auseinanderhalten: Daten und Instruktionen im Cache. Besonders wenn man bedenkt, dass die Daten in den Caches oftmals die gleichen sind, bzw. gleich gehalten werden müssen, denn das ist ein Weg wie die Kerne miteinander kommunizieren können.

Dein Video, dass Du recodierst wird zum "Bearbeiten" eventuell in den CPU-Cache geladen (stückchenweise) und könnte dabei Instruktionen von Deinem Recoder aus dem Cache "rausschmeissen". Und da Dein Video viel viel viel viel viel größer ist als Dein Cache wird jedesmal wenn Video-Daten geladen werden zum verarbeiten und diese nicht im Cache sind ein Cache-Miss stattfinden und die erforderlichen Daten nachgeladen werden.

Wie schon @Marscel erklärt hat, Dein Programm braucht RAM und keinen Cache. Sobald die Daten mit denen Du arbeitest größer sind als der Cache ..... isses doch an sich uninteressant ob das Programm in den Cache passt, spätestens auf die Daten muss die CPU dann warten.

[latiose88]

Stimmt so viel Cache wird das Programm also niemals erhalten können weil AMD und Intel werden l1 und l2 cache immer klein halten da sehr teure. Und auch die Erkenntnis das mehr l3 keinen Gewinn gegeben hatte, lässt diesen Schluss also zu oder?

Achja das erklärt auch warum latenz des RAMs auch ein Gewinn gegeben hatte. Aber merkwürdigerweise nicht bei ddr4 sondern erst seid ddr5. Aber das die Bandbreite des RAMs nicht mehr den Stellenwert des Gewinns bringt heißt das die Daten nicht sehr groß sind weil sie ohne Probleme in den RAM passen. Und. Auch nicht so viele Daten Gleichtzeitig gesendet werden. Also ich weiß noch das es mal wirklich rosige Gewinne beim. RAM gab. Aber nun merkwürdiger weise sich immer mehr verändert und der Gewinn immer kleiner wird.
Bis es dann auch beim RAM kein Gewinn mehr gibt. Was passeriert denn dann wenn weder der RAM noch der Cache der cpu was bewegen können?

[HisN]

Das wäre der Moment in dem das RAM so schnell wie der Cache wäre, bzw. der Zugriff der CPU auf Daten synchron zur CPU verläuft und ohne Wartenzeiten vom RAM beantwortet werden kann.

Dann würdest Du die "wahre" Geschwindigkeit der CPU sehen^^

[Marscel]

re AMD µProf:

Weiß nicht genau, wo jetz dein Problem lag, aber ich kann hier ein Programm auswählen oder einen laufenden Prozess wählen, dann unter "Next" ein Profil auswählen, das der Cache-Analyse von der Beschreibung her passt, und dann "Start Profile".

Dann lässt du das bis Ende oder bis Stop-Button laufen, dann "Analyze" -> "Metrics" und dann solltest du da eine Tabelle Threads, exe/dll-Modulen und teils Funktionen sehen.

Jetzt sehe ich, dass 13s MP3 unter VLC abspielen ein L1 Data Cache Miss Quote von 2,2% hatte.

Und irgendwas, das da "memcpy" nutzt, hat natürlich eine deutlich höhere Miss Rate an der Stelle.

[latiose88]

Ja wo gibt man das denn am besten so ein wie du schriebst wie sobald ich da was. Eingetragen hstte konnte ich dennoch leider nicht auf start Profil klicken weil ausgegraut. Und irgendwie geht es nicht weiter. Welches Problem hat denn diese Programm. Ich verstehe es nicht.

So ich habe es nun ausfühlich getestet gehabt und von Cache wie viel es nutzt habe ich nix gesehen nur sowas wie welche Cores es am liebsten bevorzugt und das ist nicht das was ich mir vorgestellt hatte.Ich konnte auch direkt durch CPU Cache Umwandeln ohne CPU Auslastung und die war um einiges Langsamer gewesen,was nicht das ziel ist von mir.

[latiose88]

Recoder: X-Media Recode
Auseinanderhalten: Daten und Instruktionen im Cache. Besonders wenn man bedenkt, dass die Daten in den Caches oftmals die gleichen sind, bzw. gleich gehalten werden müssen, denn das ist ein Weg wie die Kerne miteinander kommunizieren können.

Dein Video, dass Du recodierst wird zum "Bearbeiten" eventuell in den CPU-Cache geladen (stückchenweise) und könnte dabei Instruktionen von Deinem Recoder aus dem Cache "rausschmeissen". Und da Dein Video viel viel viel viel viel größer ist als Dein Cache wird jedesmal wenn Video-Daten geladen werden zum verarbeiten und diese nicht im Cache sind ein Cache-Miss stattfinden und die erforderlichen Daten nachgeladen werden.

Wie schon @Marscel erklärt hat, Dein Programm braucht RAM und keinen Cache. Sobald die Daten mit denen Du arbeitest größer sind als der Cache ..... isses doch an sich uninteressant ob das Programm in den Cache passt, spätestens auf die Daten muss die CPU dann warten.


Ok habe inzwischen ein Cache miss Rate Test gemacht und dabei kam raus zwischen 0,1 % missrate von L! zu L2 und da standen auch entsprich 2 oder 3 % war es gewesen.Also kaum ne Missrate.Heißt es passt alles in den Cache rein.Nur wie es mit 2 gleichzeitig aussieht,kann ich leider nicht testen.
Oder was sagt es denn sonst so aus,das gute Ergebnis?