OpenMP num_threads（1）執行速度快於無OpenMP

Question

我在各種情況下運行我的代碼，導致我認爲是奇怪的行爲。我的測試是使用HT的雙核英特爾至強處理器。

否的OpenMP '的#pragma' 語句，總運行時間=507秒

對於OpenMP '的#pragma' 語句中指定1個芯，總運行時間=117秒

對於OpenMP「的#pragma '語句中指定2芯，總運行時間=150秒

對於OpenMP‘的#pragma’語句中指定3芯，總運行時間=157秒

使用OpenMP'#pragma'語句指定4核心，總運行時間= 144秒

我猜我不明白爲什麼註釋掉我的openmp行會導致程序在1線程之間變慢，而沒有使用openmp和1線程用openmp。

所有我改變之間：

//#pragma omp parallel for shared(segs) private(i, j, p_hough) num_threads(1) schedule(guided) 

and... 

#pragma omp parallel for shared(segs) private(i, j, p_hough) num_threads(1,2,3,4) schedule(guided) 

不管怎麼說，如果任何人有任何想法，爲什麼這可能會發生，請讓我知道！

感謝您的幫助，

佈雷特

編輯：我會解決的一些評論在這裏

我使用NUM_THREADS（1），NUM_THREADS（2）等。

經過進一步調查，事實證明，根據代碼中是否包含「schedule（引導）」行，我的結果不一致。

- 當我使用計劃（引導）行時，無論線程數量多少，我都會生成最快的解決方案。 - 當我使用默認調度程序時，我的結果顯着變慢並且數值不同 -隨着線程數的增加無法獲得進度（指導）改進 - 沒有調度（指導）我通過添加線程獲得改進

我想我還沒有找到一個足夠好的描述什麼時間表（指導）爲我做的，我明白，它試圖分裂循環，使最耗時的迭代首先發生，這應該有一個效果一個線程等待其他人完成迭代的最少時間。

似乎對於我的〜900迭代循環，當我使用schedule（引導）時，我只處理〜200次迭代，其中沒有計劃（指導），我正在處理所有900次迭代。有什麼想法嗎？

Answer 1

OpenMP具有顯着的同步開銷。我發現，除非你有一個很大的工作，並且沒有內部循環同步的大循環，否則使用OpenMP通常是不值得的。

我認爲，當您將線程數設置爲一個（1）時，OpenMP只是對實施該循環的OpenMP過程執行過程調用，因此開銷很小，性能基本上與非OpenMP案件。

否則，我認爲OpenMP的設置了一些信號燈，並等待「工人」線程醒來，同步它們對數據結構的訪問，告訴他們什麼環路參數設置，然後調用該做的工作常規，當他們完成大量的工作，他們再次發出主線程信號。這種同步必須發生在一個線程所做的每個工作塊上，同步成本並不是微不足道的。

使用靜態調度選項可以幫助減少調度/同步開銷，尤其是當循環迭代的數量是相對於核的數量大。