Cache Miss Stresstest: atemberaubende Ergebnisse .. irgendwelche Erklärungen?

9

Um die tatsächliche Leistung eines modernen Computers relativ zu Cache-Fehlern zu erhalten (wie "Spread" ist die Daten im Speicher), führte ich einen einfachen Test, wo ich 500 MB RAM zuweisen, und führen Sie dann eine konstante Anzahl von liest, und ich führe diesen Test mit steigenden Byteversätzen durch. Schließlich schließe ich das Ende des 1000 MB-Puffers, wenn ich es erreiche.

Ich bin ziemlich überrascht von den Ergebnissen. Es sieht so aus, als gäbe es eine Kostenbarriere um 32 Bytes und eine weitere um 32 KB. Ich nehme an, das hat etwas mit L1 / L2 / L3-Cache-Laden oder virtueller Speicher Seitengröße zu tun? Was mich am meisten betäubt hat, ist, dass es anscheinend nur 16 völlig unterschiedliche Speicherplätze gibt, die zwischengespeichert werden. Das ist sehr niedrig !!! Irgendwelche Erklärungen (OS, Hardware)?

Hier sind die Ergebnisse auf 3 verschiedenen Computern, von der schnellsten zur billigsten, gefolgt von meinem einfachen Testcode (benutzt nur Standard-Bibliotheken).

16 GB RAM schnelle HP Workstation (Test in 32 Bit Windows):

%Vor%

4 GB RAM MacBookPro 2010 (Test in 32 Bit Windows):

%Vor%

4GB RAM billiger Acer "Familiencomputer":

%Vor%

Code:

%Vor%

Basierend auf einigen Kommentaren habe ich meinen Test so modifiziert, dass nur 250 MB RAM verwendet werden, und für jeden "Lesevorgang" 16 aufeinanderfolgende Lesevorgänge ausgeführt, falls der Prefetch aktiviert wird. Es hat immer noch ähnliche Ergebnisse, aber es ist der Fall, dass die letzten Tests, die wenige entfernte Orte lesen, eine bessere Leistung haben (2 Sekunden statt 5), wahrscheinlich deshalb, weil der Vorabruf beim ersten Test nicht aktiviert wurde / p> %Vor%

Ergebnisse für diesen aktualisierten Test für MacBookPro 2010:

%Vor%     
Jerome CG 02.11.2012, 10:37
quelle

1 Antwort

4

Beachten Sie, dass die meisten der folgenden Aussagen spekulativ sind. Memory Benchmarking ist sehr komplex, und ein relativ naives Benchmarking, so wie Sie es gemacht haben, liefert selten eine Menge aussagekräftiger Informationen über die Leistung eines echten Programms.

Die primäre "Kostenbarriere", wie Sie sie bei 32 kiB nennen, ist wahrscheinlich mehr bei 64kB (oder einer Kombination von beidem). Da Sie den Speicher nicht initialisieren, wird Windows beim Lesen von ihnen keine Seiten einziehen. Die Zuordnungsgranularität beträgt 64 kB, und Seiten werden in dieser Größe immer "vorbereitet" (und vorab geholt, wenn Sie eine Arbeitsspeicherzuordnung haben), selbst wenn nur eine der Seiten im 64 kB-Bereich in Ihre Arbeitsumgebung verschoben wird. Das ist etwas, was ich beim Experimentieren mit Memory Mapping herausgefunden habe.

Ihr Prozess-Working-Set, wie es von Windows eingestellt wird, ist standardmäßig lächerlich klein. Wenn Sie also über diesen Speicherblock iterieren, haben Sie ständig Seitenfehler. Einige sind weniger teuer, nur ein Flag im Seitendeskriptor ändern, andere (mit 64 KiB) sind teurer, ziehen 16 neue Seiten aus dem Zero-Pool (oder im schlimmsten Fall, wenn der Pool leer ist, Seiten null). Dies kann eine der "Kostenbarrieren", die Sie sehen, sehr gut erklären.

Eine weitere Kostenbarriere ist, wie Sie richtig bemerkt haben, Cache-Assoziativität. Unterschiedliche Adressen bei größeren Zweier-Offsets verwenden die gleichen Cache-Einträge. Bei "ungesunden" Offsets kann es vorkommen, dass die gleichen Cache-Zeilen immer wieder gelöscht werden. Dies ist einer der beiden Hauptgründe, warum die Ausrichtung gut ist, aber eine übermäßige Ausrichtung ist schlecht (der andere ist keine Datenlokalität).

Die Kostenbarriere bei 32 Bytes ist überraschend, wenn überhaupt, könnte man sich vorstellen, dass sie bei 64 Bytes liegt (Cache-Zeilen in der Testarchitektur). Prefetching sollte diese Art von Blockierung größtenteils eliminieren, aber Prefetching wird normalerweise nur aktiviert (wenn Sie es nicht explizit andeuten) , nachdem die zweite Cache-Zeile mit einem bestimmten Schritt verfehlt wurde .

Dies ist absolut akzeptabel für "echte" Programme, die entweder nur einen Ort oder einen anderen lesen oder nacheinander über mehrere Datenmengen iterieren. Andererseits kann es leicht zu verwirrenden Ergebnissen führen, wenn künstliche Messungen durchgeführt werden. Es kann auch eine mögliche Erklärung sein, warum Sie eine Kostenbarriere von 32 kiB sehen. Wenn Prefetching nicht funktioniert, wäre das der Punkt, an dem Sie den L1-Cache auf einem typischen x86 nicht mehr verwenden können.

    
Damon 02.11.2012 11:05
quelle

Tags und Links