Kann ich jemand Punkt zu Benchmark-Ergebnissen Vergleich Leistung von C11/C++ 11-Code entspannt atomare Operationen unter Verwendung von (insbesondere memory_order_release und memory_order_acquire, sondern auch memory_order_consume und memory_order_relaxed) im Vergleich zu dem Standard memory_order_seq_cst? Alle Architekturen sind von Interesse. Danke im Voraus.C11/C++ 11 schwache Speicher-Benchmarks
Dies ist vielleicht nicht die beste Lösung, aber bisher habe ich CDSChecker für einige Benchmarks in einem meiner Projekte verwendet. Ich habe es noch nicht für komplette Programme verwendet, sondern nur für unabhängige Einheiten.
CDSChecker ist nicht für Benchmarking gedacht, nur für eine gründliche Überprüfung auf Korrektheit. CDSChecker bietet keine Informationen über die Leistung Ihres Codes. – briand
Ich habe ein bisschen Benchmarking auf ARMv7 gemacht, siehe https://github.com/reinhrst/ARMBarriers für den Bericht, die Folien für mein Gespräch bei EuroLLVM und den Seqlock-Code, den ich verwendet habe.
Kurzer Text: Im Seqlock-Code war die Acquire/Release-Funktion etwa 40% schneller als die sequenziell konsistente Version. 
Der Artikel ist sehr nett. Auf der anderen Seite scheint es zu argumentieren, dass die Lücke zwischen sc und acq-rel (zumindest in diesem Beispiel) nur auf eine faule Kompilierung zurückzuführen ist, da mit dem vorgeschlagenen Compiler die oben genannte Lücke im Wesentlichen beseitigt wird, oder? – user2949652
Es ist eine Weile her, seit ich mich darauf eingelassen habe, aber soweit ich mich erinnere, ist die Lücke zwischen sc und acq-rel (in diesem Beispiel) aufgrund fehlender Compileroptimierungen (bevor der im GitHub Repo erwähnte Patch zu llvm hinzugefügt wurde) , denn in diesem Beispiel gibt acq-rel im ARM-Speichermodell die gleichen Garantien wie sc (wieder: im bereitgestellten Beispiel im ARM-Speichermodell, pre-llvm-Patch). In keiner Weise versuche ich zu argumentieren, dass sc und acq-rel im allgemeinen Fall gleich schnell sein sollten. – Claude
Für einen bestimmten Teil des Codes (ein Work-Diebstahl dequeue), fand ich einen sehr schönen paper, die eine C11-Version mit schwachen atomics, mit sc-atomics nur, hand optimierte Montage Benchmarks und eine falsche Version mit völlig entspannten Atomics. (Zufällig wurde später ein Fehler in der C11-Version des oben erwähnten CD-Checkers gefunden.) Ähnliche Beispiele sind willkommen.
Ich wage zu behaupten, dass die Leistung nicht so wichtig ist wie die Korrektheit. Sie sollten die Speicherordnung zur Semantik Ihrer Ladevorgänge verwenden und speichern, nicht etwas anderes verwenden, weil es vielleicht 3 Zyklen schneller ist. OTOH, wenn Sie keine Ahnung haben, bleiben Sie bei der Standardeinstellung, die etwas langsamer sein kann (oft nicht gerade), aber _guaranteed_ ist korrekt. Es gibt keinen Albtraum mehr als "optimierten" Multithread-Code, der nicht korrekt ist. – Damon
Die standardmäßige sequenzielle konsistente Speicherordnung ist strenger als die der anderen. Daher ist die Leistung der einzige Grund, schwächere Ordnungen zu verwenden. Ich weiß, wie man in beiden Fällen über die Richtigkeit argumentiert, aber die Argumentation ist bei schwächeren Ordnungen schwieriger. In jedem Fall ist es keine Frage von 3 Zyklen; selbst auf einem i7 ist das Löschen des Speicherpuffers in der Regel einige Dutzend Zyklen (vielleicht viel mehr auf älteren Prozessoren), und der Unterschied zwischen seq_cst und verbrauchen auf ARM ist noch viel größer. – user2949652
Es ist kaum möglich, aussagekräftige Ergebnisse aus einem Benchmark zu erhalten. Eine einzelne Ladung/Lagerung ist kaum zuverlässig messbar. Das Laden und Speichern des gleichen Werts (oder einer Gruppe von Werten) ohne Synchronisation wird nur das Cache-Thrashing, nicht aber die tatsächliche Operation vergleichen. Synchronisieren wird das Synchronisationsgrundelement messen, das ~ 1000X teurer ist. Das und Sie haben wirklich keine andere Wahl, als den richtigen Code zu schreiben. Wenn Sie für einige Daten eine "happen-before" -Garantie benötigen, können Sie _cannot_ nicht auslassen, nur weil es schneller wäre. – Damon