Compiler Optimierungen Wirkung auf FLOPs und L2/L3 Cache Miss Rate mit PAPI

Question

Also wir wurden mit einer Aufgabe beauftragt, etwas Code zu kompilieren (wir sollen es als eine Blackbox behandeln), mit verschiedenen Intel Compiler Optimierungsflags (-O1 und O3) sowie Vektorisierung Flags (-xhost und -no-VEC) und zu beobachten, Veränderungen in:

• Ausführungszeit
• Gleitkommaoperationen (FPO)
• L2 und L3 Cache Miss Rate

Nach Durchführung dieser Optimierungen haben wir einen Rückgang der Ausführungszeit festgestellt, der zu erwarten war, unter Berücksichtigung aller Änderungen, die der Compiler aus Effizienzgründen an Ihrem Code vornimmt. Wir haben aber auch einen Rückgang der FPOs festgestellt, obwohl wir wissen, dass das eine gute Sache ist, sind wir uns nicht sicher, warum das passiert ist. Außerdem haben wir eine Erhöhung der L2-Cache-Miss-Rate bemerkt (und können sie nicht erklären) (mit steigendem Optimierungslevel erhöht), aber keine signifikante Zunahme der Cache-Zugriffe und fast keine Änderungen auf dem L3-Level.

Die Verwendung von keinerlei Vektorisierung oder Optimierung ergab das beste Ergebnis in Bezug auf die L2-Cache-Miss-Rate, und wir haben uns gefragt, ob Sie uns ein paar Einsichten sowie unterstützte Dokumentation, Literatur und Ressourcen geben könnten um unser Wissen zu diesem Thema zu vertiefen.

Vielen Dank.

edit: Die Compiler-Optionen verwendet werden:

• O0 -no-vec (höchste Ausführungszeit, niedrigster L2 Cache Misses)
• O1 (weniger Ausführungszeit, Höheres L2 Cache Misses)
• O3 (Noch weniger Ausführungszeit, noch höhere L2 Cache Misses)
• xhost (gleiche Reihenfolge der O3 Ausführungszeit, höchste L2 Cache Misses)

Update:

Während die Gesamtanzahl der L2-Cache-Zugriffe gering ist, kommt es zu einem massiven Anstieg der tatsächlichen Fehler.

Mit -0O -no-vec

Wanduhr Zeit in usecs: 13.957.075

• L2 Cache-Misses: 207.460.564
• L2-Cache-Zugriffe: 1.476.540.355
• L2-Cache-Miss-Rate: 0,140504
• L3 Cache-Misses: 24.841.999
• L3-Cache-Zugriffe: 207460564
• L3-Cache-Fehlerrate: 0.119743

Mit -xhost

Wanduhr Zeit in usecs: 4.465.243

• L2 Cache-Misses: 547.305.377
• L2-Cache-Zugriffe: 1.051.949.467
• L2-Cache-Miss-Rate: 0,520277
• L3 Cache-Fehler: 86.919.153
• L3 cach e Zugänge: 547.305.377
• L3-Cache-Miss-Rate: 0,158813

Answer 1

auf die reduzierte Anzahl von Gleitkommazahlen ops:
mit einer Optimierung der Compiler aus gemeinsamen Berechnungen von Schleifen, Sicherungskonstanten, pre-calculate Flaschenzug kann Ausdrücke und so weiter.

Bei erhöhter Cache-Fehltrefferrate:
Wenn der Compiler die Vektorisierung verwendet und jedes Mal Daten in voller Vektorbreite lädt, werden insgesamt weniger Ladungen aus dem Speicher verwendet. Aber jedes Mal, wenn es auf eine Cacheline in einer Weise zugreift, die der Prädiktor nicht vorhergesehen hat, verursacht es immer noch einen Cache-Fehltreffer.
Zusammen haben Sie weniger Lasten, aber etwa die gleiche Anzahl von cachelines berührt, so dass die Rate von Misses höher sein kann.

Answer 2

Die Antwort von EOF hat eine gute Erklärung für weniger Fließkomma-Operationen: -ffast-math Stil Kombination von Operationen, so werde ich nur den anderen Teil beantworten.

---

Die Frage hat keine Informationen über welche CPU-Mikroarchitektur verwendet wurde, aber zumindest ist es intel markiert.

Auf Intel-CPUs gibt es einige Logik zum Vorabholen in L1 und komplexere Logik zum Vorabholen in L2 (von L3 oder Hauptspeicher). Jeder Kern hat seine eigene L2, aber niedrigere Ebenen der Cache-Hierarchie werden gemeinsam genutzt, daher ist es der naheliegende Ort, die Haupt-Prefetch-Logik zu setzen.

Wenn Sie langsamer als die Grenzen der Speicherbandbreite lesen, werden Ihre Lasten in L2 ankommen, weil der Hardware-Vorablesefehler diese Zeilen bereits in L2 abgerufen hat. Wenn Prefetching nicht mithalten kann, erhalten Sie L2 Cache-Fehler.

Weniger breitere Lasten statt vieler skalarer Lasten bedeutet auch, dass der Fehlbetrag% bei Vektoren schlechter ist. (Die Antwort von EOF hat diesen Punkt bereits erwähnt). Dieser Effekt erklärt nicht einen Anstieg der absoluten Anzahl von L2-Fehlern, jedoch nur (teilweise) die Fehlbetragsänderung. Bei der Betrachtung der Daten ist es jedoch wichtig, sie zu beachten.

---

Von Intel Optimierung Führung (Links im x86 Tag wiki), Abschnitt 2.3.5.4: Daten Prefetching:

Daten Prefetch zum L2 und Last Level Cache

Streamer: Dieser Prefetcher überwacht Leseanforderungen aus dem L1-Cache nach aufsteigender und absteigender Folge von Adressen ....Wenn ein Vorwärts- oder Rückwärtsstrom von Anforderungen erkannt wird, werden die erwarteten Cache-Zeilen vorabgerufen. Prefetched Cache Zeilen müssen in derselben 4K-Seite sein.

• Der Streamer kann bei jedem L2-Lookup zwei Prefetch-Anforderungen ausgeben. Der Streamer kann bis zu 20 Zeilen vor der Ladeanforderung laufen.
• Passt sich dynamisch an die Anzahl ausstehender Anforderungen pro Kern an. Wenn nicht viele ausstehende Anforderungen vorhanden sind, ruft der Streamer einen weiteren Schritt auf. Wenn es viele ausstehende Anforderungen gibt, ruft es nur die LLC und weniger weit voraus ab.
• Wenn Cache-Zeilen weit voraus sind, wird nur auf den Cache der letzten Ebene und nicht auf L2 geladen. Diese -Methode vermeidet den Austausch von nützlichen Cache-Zeilen im L2-Cache.
• Erkennt und verwaltet bis zu 32 Datenzugriffsströme. Für jede 4-KByte-Seite können Sie einen Vorwärts- und einen Rückwärtsstrom pflegen.

Dies ist aus dem Abschnitt Sandybridge, aber die Haswell und Skylake Abschnitte gehen nicht ins Detail über Änderungen an Prefetching. Sie sagen "verbessertes Prefetching", aber vermutlich ist es das gleiche grundlegende Design, nur mit besseren Heuristiken und/oder besserem Tuning für die vorhandenen Heuristiken und solche Sachen.

---

Dank @HansPassant: seine über die Frage Kommentar hat mich halten denken nicht an Prefetching.