In welcher Beziehung stehen „std::hardware_destructive_interference_size“ und „std::hardware_constructive_interference_size“ zur L1-Cache-Zeilengröße und welche Auswirkungen hat dies auf plattformübergreifenden Code?

Std::hardware_destructive_interference_size und std::hardware_constructive_interference_size verstehen

Diese Konstanten wurden in C 17 eingeführt, um eine portable Möglichkeit zum Ermitteln der Größe bereitzustellen der L1-Cache-Zeile. Ihre Beziehung zur Cache-Zeilengröße ist jedoch subtiler.

Wie hängen diese Konstanten mit der L1-Cache-Zeilengröße zusammen?

Theoretisch sollten diese Konstanten so sein entweder gleich oder größer als die L1-Cache-Zeilengröße sein. Dies liegt daran, dass die destruktive Interferenzgröße der minimale Versatz zwischen zwei Objekten ist, auf die von verschiedenen Threads zugegriffen wird, um eine falsche gemeinsame Nutzung zu vermeiden, während die konstruktive Interferenzgröße die maximale Größe zweier Objekte ist, die zusammen im Speicher platziert werden können, um eine echte gemeinsame Nutzung zu fördern.

In der Praxis stimmen die Werte dieser Konstanten jedoch aus mehreren Gründen möglicherweise nicht genau mit der L1-Cache-Zeilengröße überein. Erstens verwenden Compiler möglicherweise Heuristiken oder Umgebungshinweise, um die Größe der Cache-Zeile abzuschätzen, was möglicherweise nicht in allen Fällen genau ist. Zweitens kann die Größe der Cache-Zeile je nach Architektur der spezifischen Maschine, auf der der Code ausgeführt wird, variieren.

Gibt es ein gutes Beispiel, das ihre Anwendungsfälle demonstriert?

False Sharing tritt auf, wenn zwei oder mehr Threads auf unterschiedliche Teile derselben Cache-Zeile zugreifen, was dazu führt, dass die Cache-Zeile ungültig gemacht und häufig neu geladen wird. Dies kann zu erheblichen Leistungseinbußen führen. Um eine falsche gemeinsame Nutzung zu vermeiden, sollten Objekte, auf die von verschiedenen Threads zugegriffen wird, mindestens eine Cache-Zeile voneinander entfernt im Speicher abgelegt werden.

Eine echte gemeinsame Nutzung liegt vor, wenn zwei oder mehr Threads auf dieselbe Cache-Zeile zugreifen, wodurch die Cache-Zeile freigegeben werden kann einmal in den Cache geladen und von allen Threads gemeinsam genutzt. Dies kann zu einer erheblichen Leistungsverbesserung führen. Um eine echte gemeinsame Nutzung zu fördern, sollten Objekte, auf die von demselben Thread zugegriffen wird, so im Speicher abgelegt werden, dass sie in eine einzelne Cache-Zeile passen.

Beide sind als statische constexpr definiert. Ist das kein Problem, wenn Sie eine Binärdatei erstellen und diese auf anderen Computern mit unterschiedlichen Cache-Zeilengrößen ausführen? Wie kann es in diesem Szenario vor falscher Freigabe schützen, wenn Sie nicht sicher sind, auf welchem ​​Computer Ihr Code ausgeführt wird?

Die statische Konstruktionsart dieser Konstanten stellt ein potenzielles Problem dar, wenn der Code ausgeführt wird verschiedene Maschinen mit unterschiedlichen Cache-Zeilengrößen. Wie bereits erwähnt, stimmen die Werte dieser Konstanten möglicherweise nicht genau mit der Größe der L1-Cache-Zeile überein, was zu einer falschen Freigabe oder verpassten Gelegenheiten für eine echte Freigabe führen kann.

Um dieses Problem zu entschärfen, können Sie Ihre eigenen Konstanten mit spezifischen Cache-Zeilengrößen für Ihre Zielarchitektur definieren. Alternativ können Sie die Konstanten std::hardware_destructive_interference_size und std::hardware_constructive_interference_size als Fallback-Werte verwenden und die tatsächliche Cache-Zeilengröße zur Laufzeit mithilfe plattformspezifischer Methoden überprüfen.

Das obige ist der detaillierte Inhalt vonIn welcher Beziehung stehen „std::hardware_destructive_interference_size“ und „std::hardware_constructive_interference_size“ zur L1-Cache-Zeilengröße und welche Auswirkungen hat dies auf plattformübergreifenden Code?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!