C11/C++ 11弱內存基準測試

任何人都可以點用寬鬆的原子操作（尤其是memory_order_release和memory_order_acquire，也memory_order_consume和memory_order_relaxed）與默認memory_order_seq_cst比較C11/C++ 11的代碼性能的基準測試結果？所有架構都是有趣的。提前致謝。C11/C++ 11弱內存基準測試

來源

2013-11-03 user2949652

我敢說表現並不那麼重要了一樣正確性。你應該使用內存順序來加載和存儲正確的語義，而不是使用不同的東西，因爲它可能快3個週期。 OTOH，如果你不知道，保持默認值，_may_會稍微慢一點（通常不是偶數），但是_guaranteed_是正確的。除了「優化」的多線程代碼不正確之外，沒有什麼更多的噩夢了。 – Damon

默認的順序是一致的存儲排序比任何其他人更嚴格，所以性能是使用弱排序的唯一原因。在任何一種情況下，我都知道如何推理正確性，但是對於較弱的排序，推理是比較困難的。無論如何，這不是3個週期的問題;即使在i7上，刷新存儲緩衝區的次數通常是數十個週期（可能在更舊的處理器上會多得多），並且ARM上的seq_cst和消耗之間的差異仍然更大。 – user2949652

從基準測試中獲得有意義的結果幾乎是不可能的。單一的加載/存儲幾乎不可靠。在沒有同步的情況下多次加載和存儲相同的值（或一組值）只會對緩存抖動進行基準測試，而不是實際的操作。同步將測量同步原語，這是約1000倍的昂貴。那，你真的別無選擇，只能寫出正確的代碼。如果你需要發生 - 在保證某些數據之前，你不能將它放棄，因爲它會更快。 – Damon

這可能不是最好的解決辦法，但到目前爲止，我一直在使用CDSChecker一些基準標記在我的項目之一。我還沒有在完整的程序中使用它，而更多的是在獨立的單元上使用它。

來源

2014-03-28 11:00:28 McLoving

CDSChecker不是爲基準測試而設計的，只是爲了正確性的詳盡測試。 CDSChecker不提供有關代碼性能的信息。 – briand

我在ARMv7上做了一些基準測試，請參閱https://github.com/reinhrst/ARMBarriers的報告，我在EuroLLVM上演講的幻燈片以及我使用的seqlock代碼。

短篇小說：在順序鎖碼，採樣/發佈功能比順序一致的版本快40％左右。 enter image description here

來源

2014-04-13 07:27:02 Claude

該文章非常好。另一方面，似乎認爲sc和acq-rel之間的差距（至少在這個例子中）純粹是由於懶惰的編譯，因爲在你提出的編譯器通過的地方，上面的差距基本上被消除了，對嗎？ – user2949652

我已經有一段時間了，但是據我所知，sc和acq-rel之間的差距（在本例中）是由於缺少編譯器優化（在GitHub repo中提到的補丁被添加到llvm之前），因爲在本例中，在ARM內存模型中，acq-rel爲您提供與sc相同的保證（再次：在所提供的示例中，在ARM內存模型中，pre-llvm-patch）。在任何情況下，我都不認爲sc和acq-rel在一般情況下應該同樣快。 – Claude

對於一個特定的代碼塊（一個工作竊取出隊），我發現了一個很不錯的 paper該基準的C11版弱原子公司，與SC-原子能只，手工優化的彙編，以及不正確的版本使用完全放鬆的原子。（巧合的是，後來在上述CDSChecker的C11版本中發現了一個錯誤。）歡迎使用類似的例子。

來源

2015-06-28 14:24:21 user2949652

C11/C++ 11弱內存基準測試

回答

相關問題