Wie Hardware Prefetcher in Core i3 / i7 in Linux zu besiegen

Ich versuche einen Weg zu finden, den H / W-Prefetcher zu vereiteln, um das Stream-Muster zu erkennen und 4KB-Daten in zufälliger Reihenfolge abzurufen so dass es nicht vom H / w-Prefetcher erkannt und vorabgerufen wird.

Zunächst dachte ich daran, auf alle geraden Indexdaten in einem zufälligen Muster zuzugreifen, da der H / w-Prefetcher die nächsten Cache-Zeilen vorfabriziert immer (wenn ich also auf den Index zugreife, werden die nächsten ungeraden Indexdaten bereits vorab geholt).

Ich habe den Code geschrieben, um auf alle geraden Indexdaten in einem zufälligen Muster zuzugreifen, jedoch zeigen die Ergebnisse an, dass der Vorabrufer das Muster erkannt hat (Weiß nicht wie? Es gibt keinen festen Schritt, alle sind Zufallsschritt)

Ich habe den Grund untersucht - warum das passiert ist, dann habe ich diesen Artikel in Intel gefunden; Ссылка

Laut John D. McCalpin, PhD, "Dr. Bandwidth,

  

In Abschnitt 2.2.5.4 von "Intel 64 und IA-32 Architekturen Optimierung   Referenzhandbuch "(Dokument 248966-028, Juli 2013), heißt es,

     

streamer prefetcher "[d] etet und verwaltet bis zu 32 Datenströme   Zugriffe. Für jede 4-KByte-Seite können Sie eine Vorwärts- und eine weitere Seite verwalten   Rückwärtsstrom kann beibehalten werden.

     

Dies bedeutet, dass der L2-Hardware-Prefetcher die 16 4KiB-Seiten verfolgt   zuletzt zugegriffen und erinnert sich genug der Zugriffsmuster für   Diese Seiten sollen einen Vorwärtsstrom und einen Rückwärtsstrom verfolgen. Damit   um den L2 Streamer Prefetcher mit "zufälligen" Abrufen einfach zu besiegen   Stellen Sie sicher, dass Sie auf mehr als 15 weitere 4 KiB-Seiten zugreifen, bevor Sie etwas tun   ein zweiter Verweis auf eine zuvor referenzierte Seite. Also ein "Zufall"   Abfolgen von Abrufen könnten aus einer zufälligen Permutation von mehr bestehen   als 16 4 KiB Seitenzahlen mit einem zufälligen Offset innerhalb jeder Seite. (ICH   verwende normalerweise mindestens 32 Seiten in meiner Permutationsliste.)

Also bedeutet es zwischen Zugriffen von zwei verschiedenen Zufallsindizes der gleichen 4KB Seiten, dass wir auf mindestens 16 4KB Seiten zugreifen müssen, um den H / W Prefetcher zu besiegen.

Ich habe das von John D. McCalpin vorgeschlagene Konzept implementiert, aber die Ergebnisse zeigen wieder, dass der h / w-Prefetcher nicht besiegt ist. Es kann Muster erkennen und Daten vorlesen (siehe Beispielausgabe). Ich habe die Anzahl der aufgerufenen Seiten von 20-40 4KB Seiten variiert, aber keine Verbesserung / Änderung im Ergebnis.

Hier ist mein Code:

Eine weitere interessante Beobachtung ist, dass die Zugriffszeit von zufälligen Indizes, die vorabgerufen wurden, eine Zugriffszeit von ungefähr 35 bis 70 Ticks aufweist. (siehe Beispielausgabe)

In meinem System ist die L1-Zugriffszeit 36-44 Ticks, L2-Zugriffszeit 50-70 Ticks, L3 Zugriffszeit = 90-120 Ticks.

Experimente wurden sowohl mit Intel® Core ™ i3-2100 CPU bei 3,10 GHz als auch mit Intel® Core ™ i7-3770 CPU bei 3,40 GHz durchgeführt, die Ergebnisse sind jedoch ähnlich.

Wenige interne Details des Systems,

%Vor%

Können Sie mir bitte helfen, zu verstehen, warum der H / W Prefetcher mein zufälliges Muster erkennen kann? Wo mache ich Fehler?

Wie wird das Codieren durchgeführt, damit der Prefetcher und der h / w-Prefetcher nicht meine Daten vorlesen können?

HINWEIS: Ich habe die s / w-Prefetcher-Optimierung beim Kompilieren mit der -OO-Option mit gcc deaktiviert.

Beispielausgabe: