なぜboost :: mutexはvs2013のstd :: mutexより速いのですか？

Question

今日私はミューテックスの性能をテストするコードを書いています。

これはO2の最適化とVS2010でコンパイルブースト（1.54）バージョン、次のとおりです。

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; 

そして、これはあまりにもO2の最適化と、VS2013でコンパイルSTDバージョン、次のとおりです。

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、私のOSはWindows 7 64bit、 で、結果は0.7020sと2.1684s、3.08回です。

boost :: mutexは最初に を試し、失敗した場合は大きなチーズWaitForSingleObjectが2番目になります。 これは理解しやすいです。

VS2013のstd :: mutexははるかに複雑なようですが、私はすでに を理解しようとしましたが、私はポイントを得ることができませんでした なぜそれがとても複雑ですか？そこにはもっと速い方法がありますか？

Answer 1

stl::mutexはシステムコールだけを使用しているようですが、オーバーヘッドが大きくなります。 boost::mutexは、プログラムの機能の少なくとも一部を実装しています。つまり、できるだけシステムコールを避けようとしています。WaitForSingleObjectの前に、try _interlockedbittestandsetのチェックが行われます。

私はMSのstlの実際の内部を知りませんが、このようなパフォーマンスの違いはオペレーティングシステムクラスの例と分かりました。

Answer 2

このテストでは、ロックされていないmutexを他のスレッドから競合することなくロックする条件をテストしています。

mutexがロックされていたとします。最初のブーストを試した後、スレッドが回転またはブロックする方が良いでしょうか？それは本当にすべてアプリケーションに依存します。そして、おそらく、stl 1は重い負荷のもとでより良く動作します。

時間が非常に効率的なミューテックスを必要とするときは、同じ目的を達成するためのロックフリーの方法を検討する価値があります。