OpenMP在實際開發中應用多嗎？

01-05

你們公司的產品有用到OpenMP嗎？
如果需要並行計算，你會選擇OpenMP嗎？

我選C++/AMP，一樣簡單的寫法，卻可以搞進GPU。

2017 年再看 OpenMP 已經是個半死的技術了。Multi-core 的並發基本上都在採用類似 GCD/TBB 的技術。

當年 OpenMP 採用編譯器擴展能贏得開發者，主要是因為 lexical scope closure 沒有被廣泛支持。2017 年各種主要語言都支持 lambda/closure，根本沒有必要再使用 compiler 擴展來隱式並發。

更好粒度的並行演算法可以在 GPU 上實現。

有用也要看代價。這種半吊子的 compiler 擴展，用在產品里就等著出麻煩吧。今天還學到一點，什麼技術吸引什麼人。遇到一堆嘴裡嘟麻煩「圖樣圖森破」的人，第一我更確定這是什麼技術了，第二我也更知道以後工作里要躲開什麼人了。

數值計算中很多，但是主要是歷史原因。在大約2000—2015這個時段單機多核除了openMP 並沒有什麼其他好選擇。尤其是在科學計算領域很多用戶並沒有精力去學習多線程計算，這個時候openmp那種可單線程可多線程的簡單pragma寫法就成為了一個巨大優勢。雖然要優化性能依然需要不少知識，但是至少給了廣大科研人員一個簡單的方法去並行化。

openMP的最大缺點就是非常依賴於編譯器版本和鏈接參數。完全本地開發本地運行的話還沒什麼問題，一旦需要跨平台，哪怕只是gcc4.7和4.8這樣的版本差異帶來的c++標準和openmp版本的微小差異，也都有可能出問題。Linux的拿到mac上跑簡直是一定會多多少少有小問題，更不要說llvm的openmp實現至今都有一些陳年bug沒有消除。如果要鏈接mkl這種自帶openmp runtime的更是要非常小心地閱讀產品文檔，不然一開多線程很可能立刻崩潰。

openMP一定還會存在很長時間，但是從用戶角度我非常希望有不依賴編譯器版本只依賴標準c++的替代產物出現。intel tbb是一個選項但是似乎不論是開源界還是Intel都對它的推廣不是很熱心，用的遠不如openmp廣泛。

openMP現在似乎想用offload把cuda openacc的活都一起幹了，這豈不是連硬體驅動版本都要和編譯器綁定了。。。

在做圖像處理時用到OpenMP，因為只在CPU上使用且同時只有一個worker存在，所以在目標為多核機器時非常好用。

我正在使用Openmp，但是如果你是在集群上計算的話，還是使用MPI的擴展性會好一些。

個人用openMP還算頻繁，感覺主要適合偷懶，因為很方便，一行指令解決幾乎所有並行需求（但是還是要配置環境，設置柵欄什麼的，可能不止一行），而且內存管理、同步什麼的相當粗暴。

各位講的什麼庫，其實那都是中間層的東西，如果只是渲染啊什麼的，調用這些東西當然方便，因為比較成熟，但是如果自己做奇怪的運算，庫中根本不可能存在，只能自己寫，如果我們這些演算法愛好者簡單實現別人的模型都要管理線程的話，那樣耗時太多。

如果只是單純的矩陣的運算的話，還是用BLAS庫吧，畢竟現成的那麼多。

ICC這種東西，可遇不可求，如果用intel平台並且能搞到licence（我有開源軟體作者的）還有極致追求的話，TBB當然吼啦，但各位同志能滿足這個三個條件的不多吧，萬一別人用Power呢？然而當時我學Xeon Phi編程的時候，那個intel的作者用的就是openMP（用ICC），新手友好而且差別不會太大。

openMP不只是用在CPU端，甚至有應用是用openMP來操作多張顯卡的（openMP+openACC）。

openACC是一個很新的東西，還不夠成熟，在粒度並行和向量化等東西上面效果遠不如CUDA，但是人家做出這個東西來還是方便了很多做科學運算的人，因為很多科學代碼很長，邏輯很複雜，用的是C++或者fortran，用CUDA重構成本太高，現在加幾行代碼再重新編譯一遍就可以在GPU上面跑，不是很方便嗎？

有些人提到MPI，那是一個多進程的介面，openMP是多線程的，大家還是要明白其中的差別，而且在大規模的並行演算法上面，這兩種介面混用是很常見的。

我覺得這東西跟你要用的超算的architecture有關係。我們組現在在用Argonne國家實驗室的Theta算東西。Theta用的是Intel的many core system，一個node上64個核，對於這種architecture，MPI+OpenMP會比純MPI要快，而且快不止一點點(我自己實驗過)。因為這64個核每個核的能力不是很強，給每個核分配一個mpi rank的話太heavy了。最重要的一點是，openmp容易上手啊，我覺得MPI，CUDA都比這個難學。你要是有GPU，你也不必一定要用CUDA，OpenMP也是可以在GPU上面用的，不過我沒試過，不知道performance怎麼樣，等我試過了再來更新答案。

OpenMP主要提供了parallel for語義，對於簡單的並行演算法還是非常好用的。當然自己實現一個parallel for或者使用TBB之類的庫也很容易，做並行計算最重要的是演算法設計，用什麼工具是次要的。

It depends.

在CPU上還是很常見的，簡單方便，而且比較成熟。部分庫（比如MKL）自帶OpenMP加速。

GPU上的OpenACC也借鑒了OpenMP的很多interface，但是並不很優化。

具體看應用的需求，OpenMP適合那種並行模式簡單常見，希望通過並行加速但又不想在並行控制上花太多精力的場景，當然一般還要限制在單機同一個線程內才能比較好的發揮他的優勢，總的來說這是一種通過並行加速單個函數的方式，超出這個範圍都不建議使用

當然多了。。。高票回答明顯沒寫過多少數值程序

矩陣相關的計算全是一層套一層的循環，用OpenMP就直接一句 #pragma omp parallel for就並行了，為什麼要用closure自己山寨？

就算是自己寫thread + closure，OpenMP那一大堆優化你真的會自己做嗎？

GCC，ICC，MSVC這些主流編譯器全都支持OpenMP，並且一直在更新OpenMP版本。寫編譯器的人又不傻，沒什麼人用的話，誰還會去一直維護？

還是喜歡想ppl, tbb之類的以庫的形式用，配合lambda函數，也挺方便的。最重要的是，容易造個簡單的輪子或wrapper，跨平台用。

我們公司的遊戲編輯器在一些需要處理大量頂點數據的場合使用了OpenMP，選擇OpenMP的原因是足夠簡單，只要添加一條pragma，不需要修改原有代碼，並且性能也夠用。

用過一次，隱式的並發好頭痛，外加上c++要考慮好多東西

後來還是用Intel顯式並發庫 Threading Building Blocks去做並發，爽很多。

原理很簡單，就是拆成了幾個線程，然後使用事件對象等待所有線程結束，沒有做同步，要想更好的控制建議自己寫多線程或者線程池什麼的。但它的優勢是幾乎不用改原來的代碼

挺好的東西，在一些圖形圖像處理上大量用，配合sse指令，提速十幾倍是非常容易的。關鍵在於沒有openmp，結果一點不受影響。

至於最高票答案，希望用openmp解決所有並行運算，然後又因為openmp不能滿足其希望表現的態度，我只能說圖樣圖森破。

不同意最高票。

OpenMP在實際應用中還是很多的，重點是比較簡單，如果你的任務之間是完全無依賴，那就一句OpenMP引語就搞定了，相比其他的TBB/Pthread 實在簡單太多，而且現代編譯器都內置支持，標準也在一直進化。

其實並行來說在shared-memory範圍內，OpenMP是個不錯的選擇。

我的所有隨機分析程序都用了這個玩意

尤其是蒙特卡洛抽樣，神器啊