[分享] CUDA 程式設計(8) -- OpenMP vs. SIMT

看板C_and_CPP (C/C++)作者a5000ml (咖啡裡的海洋藍)時間16年前 (2008/11/06 03:10)推噓2(2推 0噓 0→)

留言2則, 2人參與討論串1/1

※ [本文轉錄自 VideoCard 看板] 作者: a5000ml (咖啡裡的海洋藍) 看板: VideoCard 標題: [分享] CUDA 程式設計(8) -- OpenMP vs. SIMT 時間: Wed Nov 5 20:30:35 2008 ※ 第 7 章 SIMT vs OpenMP 最近為了要對 SIMT 做更精確的描述，所以做了以下的對照表 +------+--------------------------------+-----------------------------------+ | | OpenMP | SIMT | +------+--------------------------------+-----------------------------------+ | 運作 | 程式設計師站在管理者的角度， | 程式設計師站在員工的角度(執行緒)，| | 方式 | 對執行緒進行任務派遣。 | 對工作進行主動切割。 | +------+--------------------------------+-----------------------------------+ |執行緒| 執行緒「被動的」接受任務。 | 執行緒「主動的」切割任務。 | | 觀點 | | | +------+--------------------------------+-----------------------------------+ |硬體面| 傾向於 CISC，管理執行緒的指令 | 傾向於 RISC，管理執行緒的指令 | | | 相對較多。 | 相對少。 | +------+--------------------------------+-----------------------------------+ | | 1.程式容易設計&管理 | 1.容易發出大量執行緒 | | 優點 | 2.序列化處理比較不浪費資源 | 2.硬體設計簡單, 易於實現超多核心 | | | 3.編譯器最佳化已有一段時間 | 3.指令拮取可以合併 (warp) | | | 4.執行緒任務分配較為彈性 | 4.記憶體讀取可以併 (coalesced) | +------+--------------------------------+-----------------------------------+ | | 1.不易發出大量執行緒 | 1.程式不易設計&管理 | | 缺點 | 2.硬體需處理複雜的執行緒問題 | 2.工作切割需要處理正交性問題 | | | 3.資料同步化不易 | 3.序列化處理較浪費資源 | | | 4.不同核心的指令拮取無法合併 | 4.編譯器最佳化不易 (發展較淺) | | | 5.記憶體讀取不易合併 | 5.演算法較缺乏 (發展較淺) | | | 6.快取一致性問題 | 6.執行緒彈性較差 | +------+--------------------------------+-----------------------------------+ ◆ 先談 OpenMP 好了 (1) 可以在單線程的程序中插入平行化的指令，對軟體設計的確是很方便的，但為了達到這個目的，它需要動態調節執行緒的指令，指令集就相對的多，所以會演化成 CISC，晶片空間會不夠實做大量暫存器 (差不多幾百個)。 (2) 在調整執行緒數目時，那些本來閒置的 core 必需重做指令拮取 (fetch)，也就是重置管線，所以會有 overhead。 (3) 因為是原本的單線程做 invoke，若這些工作不同時，就不易發出大量執行緒，想像一個老闆要叫 10 個員工去做 10 個不同的工作，就要一個一個叫過來談，那不是很花時間嗎？所以大量發出執行緒有困難。 (4) 但也因為這 10 個員工都能獨立做事，所以執行緒任務分配上較為彈性，不過各自能力都很強，同步化的就不容易了，必需使用 wait 機制。 (5) 每個核心都很完整，連指令和資料管線都獨立，也就是不能合併來做，除了透過快取層來協調之外，直接合併指令和資料很難，而快取比暫存器和 ALU 運作慢，這種情況下的指令的合併有不如無。 (6) 資料在各核心之間的同步，其實和快取一致性的有關，現在 x86 這族的 CPU 還沒有出現 shared memory，所以同步化的上限頂多就是和 texture 一樣而己 (它也是用 cache) (7) 在需要序列化的處理時，它可以關閉其它 core，比較不會佔用資源。 ---------------------------------------------------------------------- ◆ 再來談 SIMT (1) 因為設計成執行緒群組，所以指令拮取和資料讀取很容易合併，老闆叫 10 個員工一起做一件事，只需溝通一次即可，而做的工作又類似，要拿的記憶體位址也都很近，可以一次叫 RAM 送來。 (2) 但這 10 個員工要協調好，不要重覆做到相同的事，那就是正交性的問題，這些分割現在要由軟體負責，所以程式設計上會比較困難一點。 (3) 執行緒切換時，因為是群組切換(warp)，所以 overhead 很小，很容易就可以發出大量且運作順暢的執行緒， (4) 因為執行緒硬體上並不完全獨立(MP & warps)，所以彈性較差，有些需要轉為序列化處理的部份，會比較卡資源。 (5) 現階段的 SIMT 和硬體相依性頗高 (MP, warps, 最大暫存器數, branch...)，所以在做最佳化時常要考慮硬體細節，比較複雜的情況下，有時會覺得像在寫組合語言的延伸而不是 C++ 的延伸~~ XD (6) 演算法在這個領域很缺乏，是值得發展的空間。 .:+: (7) 硬體較簡單，傾向於 RISC，所以暫存器光是 G80 的一個 MP 就有 8,192 個， 16 個 MP 的 32-bit 暫存器總量就是 8,192 * 16 = 131,072 13萬個，真是嚇死人 GTX280 每個 MP 暫存器數量加倍，30 個 MP 的暫存器總量就是 16,384 * 30 = 491,520 將近 50 萬個 @_@ 看這個趨勢，明年 NV 不知道會不會推出「百萬暫存器」的晶片。 ------------------------------------------------------------------- 小弟先去體育館運動一下，回頭再來吐泡泡 ...oO -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.45.208.148