爲什麼boost :: mutex比vs2013的std :: mutex更快？

今天我寫了一些代碼來測試互斥鎖的性能。爲什麼boost :: mutex比vs2013的std :: mutex更快？

這是提升（1.54）版本，編譯於VS2010與O2優化：

boost::mutex m; 
auto start = boost::chrono::system_clock::now(); 
for (size_t i = 0; i < 50000000; ++i) { 
    boost::lock_guard<boost::mutex> lock(m); 
} 
auto end = boost::chrono::system_clock::now(); 
boost::chrono::duration<double> elapsed_seconds = end - start; 
std::cout << elapsed_seconds.count() << std::endl;

這是性病的版本，在VS2013編譯，與O2優化過：

std::mutex m; 
auto start = std::chrono::system_clock::now(); 
for (size_t i = 0; i < 50000000; ++i) { 
    std::lock_guard<std::mutex> lock(m); 
} 
auto end = std::chrono::system_clock::now(); 
std::chrono::duration<double> elapsed_seconds = end - start; 
std::cout << elapsed_seconds.count() << std::endl;

有點不同，但做同樣的事情。我的CPU是Intel Core i7-2600K，我的操作系統是Windows 7 64bit，，結果是：0.7020s vs 2.1684s，3.08倍。

boost :: mutex將首先嚐試_interlockedbittestandset，，如果失敗，則大奶酪WaitForSingleObject將排在第二位，這很容易理解。

VS2013的std :: mutex似乎要複雜得多，我已經嘗試瞭解它，但我無法理解，爲什麼這麼複雜？有更快的方法嗎？

來源

2013-10-20 amanjiang

您是否在兩種情況下都啓用優化的構建（如果Visual Studio爲發佈版本）？ –

是的，當然，使用/ O2優化構建默認版本。 – amanjiang

好的 - 很好的瞭解 - 只要啓用編譯器優化，您會驚訝地發現很多性能問題很容易「修復」。 –

看來，stl::mutex可能只使用系統調用，這需要很大的開銷;但boost::mutex至少以編程方式實現了其某些功能 - 即儘可能避免系統調用，這可能是在WaitForSingleObject之前檢查try _interlockedbittestandset的原因。

我不知道MS的stl的實際內部，但我已經看到類似於操作系統類中的示例的性能差異。

來源

2013-10-23 05:34:44

該測試僅測試鎖定未鎖定的互斥鎖而沒有來自其他線程的任何爭用的情況。

讓我們說互斥鎖被鎖定。嘗試最初的提升之後，線程旋轉還是阻止會更好？這完全取決於應用程序。也許在重負荷下，stl的表現會更好。

當時代需要一個高效率的互斥體時，一個實現相同目標的無鎖選擇是值得探索的。

來源

2014-12-16 18:16:55 edwinc

爲什麼boost :: mutex比vs2013的std :: mutex更快？

回答

相關問題