並行任務使用boost :: thread比使用ppl或OpenMP獲得更好的性能

Question

我有一個可以並行化的C++程序。我正在使用Visual Studio 2010,32位編譯。

在節目的短的結構如下

#define num_iterations 64 //some number 

struct result 
{ 
    //some stuff 
} 

result best_result=initial_bad_result; 

for(i=0; i<many_times; i++) 
{ 
    result *results[num_iterations]; 


    for(j=0; j<num_iterations; j++) 
    { 
     some_computations(results+j); 
    } 

    // update best_result; 
} 

由於每個some_computations()是獨立的（一些全局變量讀取，但沒有全局變量修改）我並行內for -loop。

我第一次嘗試用的boost ::線程，

thread_group group; 
for(j=0; j<num_iterations; j++) 
{ 
    group.create_thread(boost::bind(&some_computation, this, result+j)); 
} 
group.join_all(); 

效果還不錯，但我還是決定嘗試更多。

我試過的OpenMP庫

#pragma omp parallel for 
for(j=0; j<num_iterations; j++) 
{ 
    some_computations(results+j); 
} 

的結果比boost::thread的更爲惡劣。

然後我嘗試了PPL庫和使用parallel_for()：

Concurrency::parallel_for(0,num_iterations, [=](int j) { 
    some_computations(results+j); 
}) 

的結果是最差的。

我發現這種行爲相當令人驚訝。由於OpenMP和ppl是爲並行化設計的，因此我期望得到比boost::thread更好的結果。我錯了嗎？

爲什麼boost::thread能給我更好的結果？

Answer 1

OpenMP或PPL不會做悲觀的事情。他們只是按照他們的說法去做，但是當你試圖平行循環時，你應該考慮一些事情。

沒有看到你如何實現這些東西，很難說真正的原因可能是什麼。

此外，如果每次迭代中的操作都對同一循環中的任何其他迭代具有一定的依賴性，那麼這將創建爭用，這會減慢速度。你沒有顯示你的some_operation函數實際做了什麼，所以很難判斷是否存在數據依賴關係。

一個可以真正並行化的循環必須能夠使每個迭代完全獨立於所有其他迭代運行，在任何迭代中都不會訪問共享內存。所以最好，你會寫東西到本地變量，然後在最後複製。

並非所有的循環都可以並行化，這非常依賴於正在完成的工作類型。

例如，對於並行化來說很好的事情是在屏幕緩衝區的每個像素上進行的工作。每個像素完全獨立於所有其他像素，因此，一個線程可以進行一次循環迭代，並且無需等待迭代之間的循環內的共享內存或數據依賴性即可完成工作。另外，如果你有一個連續的數組，那麼這個數組可能部分在緩存行中，如果你正在編輯線程A中的元素5，然後改變線程B中的元素6，你可能會得到緩存爭用，這將會也會放慢速度，因爲這些會駐留在同一個緩存行中。現象稱爲虛假分享。

在進行循環並行化時，需要考慮很多方面。

Answer 2

簡而言之，openMP主要基於共享內存，額外的任務管理和內存管理成本。 ppl旨在處理常見數據結構和算法的通用模式，它帶來了額外的複雜性成本。他們兩個都有額外的CPU成本，但是你簡單的掉線boost線程不（boost線程只是簡單的API包裝）。這就是爲什麼他們都比你的boost版本慢。而且，由於示例計算彼此獨立，沒有同步，因此openMP應接近boost版本。

它發生在簡單的場景中，但對於複雜的場景，具有複雜的數據佈局和算法，它應該與上下文相關。