OpenMP虛假共享

我相信我遇到了使用OpenMP的虛假共享。有什麼方法可以識別並修復它嗎？OpenMP虛假共享

我的代碼是：https://github.com/wchan/libNN/blob/master/ResilientBackpropagation.hpp線36

使用4芯CPU相比單線程1芯版本中額外的性能僅產生10％。當使用NUMA 32物理（64虛擬）CPU系統時，CPU利用率停留在1.5核心左右，我認爲這是虛假共享的直接症狀，無法擴展。

我也試着用英特爾VTune分析器來運行它，它說大部分時間都花在了「f（）」和「+ =」函數上。我相信這是合理的，並不能真正解釋爲什麼我得到如此糟糕的縮放......

任何想法和建議？

謝謝。

來源

2012-01-27 user1172549

虛假分享不會減少您的CPU利用率。它只會導致大量的緩存未命中。 – Mysticial 2012-01-27 00:52:34

@Mystical - 我的理解是，如果調度程序調度擁有該頁面的處理器上的所有線程以避免過度遷移它，則可能是在NUMA上。 – Flexo 2012-01-27 18:54:37

@awoodland這當然是一種可能 - 儘管將所有事物都記憶在一起的另一個後果。（因爲你在我的聯合國中遺漏了第二個'我'，所以我沒有得到你的支持。） – Mysticial 2012-01-27 20:59:08

使用約簡而不是基於線程ID顯式索引數組。該陣列實際上保證了虛假分享。

如更換此

#pragma omp parallel for 
    clones[omp_get_thread_num()]->mse() += norm_2(dedy); 

for (int i = 0; i < omp_get_max_threads(); i++) { 
    neural_network->mse() += clones[i]->mse();

與此：

#pragma omp parallel for reduction(+ : mse) 
    mse += norm_2(dedy); 

neural_network->mse() = mse;

來源

2012-01-27 00:54:13

一種方式肯定知道是在看高速緩存的統計與像cachegrind工具：

valgrind --tool=cachegrind [command]

來源

2012-01-27 15:02:28 ThomasBastiani

Cachegrind是否能很好地處理多線程程序？ – Flexo 2012-01-27 18:53:15

是的，這是我正在考慮使用線程分析工具+1 – pyCthon 2012-02-03 03:57:35

它支持多線程，但valgrind使用它自己的內部調度程序，所以線程執行是順序化的。我不認爲cachegrind是一個很好的選擇。 – janjust 2012-04-09 16:03:40

OpenMP虛假共享

回答

相關問題