Linux
在多執行緒應用程序中同步執行緒
我在具有 16 核、32 執行緒 XEON 處理器和 OpenMPI 版本 4.1.1 的 CentOS 8（核心）系統上使用SIESTA dft 包進行所有計算。
- 因為我有 32 個執行緒，所以我使用其中的 28 個來進行 SIESTA 計算（這會消耗大量記憶體 ~60%）並保持剩餘的 4 個空閒。
- 但是，如果我開始將 2 或 3 個剩餘執行緒用於其他應用程序（記憶體使用量可以忽略不計），同時將 SIESTA 計算保持在 28 個執行緒，我發現 SIESTA 計算的速度降低了大約 50-60 %。
- 我檢查了 CPU 使用率，發現在場景 2 中使用系統時，一個執行緒幾乎保持空閒狀態。
有沒有辦法診斷和解決這個問題？這是因為某些程序調度錯誤而發生的嗎？可以使用某種流程綁定或作業調度包來改善這一點嗎？
CPU 使用率作為一個簡單的百分比無法傳達多核、多執行緒、多執行單元 CPU 和記憶體的複雜性。幾乎可以肯定CPU 實際上在記憶體或記憶體上停滯不前。擁有數據的程序將爭奪執行單元。
這個 CPU 只有 16 個核心。正如您所發現的，將其視為 32 會在某些時候嚴重降低性能。即使使用 SMT 2。也許您可以將執行緒數增加到 125% 的核心 (20)，但 175% (28) 正在推動它。尤其是在其他事情執行的情況下。退迴執行緒。
確保計算每執行緒每秒完成的有用工作。實驗，一次改變一個變數。如果您可以訪問這些配置，也許可以嘗試具有不同記憶體和核心計數配置的處理器。
使用性能監控計數器衡量您的停滯程度。無法在 VM 中工作，但值得在 Linux 上嘗試。來自我之前連結的 Gregg：
perf stat -a -- sleep 10Xeons 的理論最高速度是每個週期 4 或 5 條指令。你不會明白，但 < 1.0 IPC 在記憶體上會額外停滯。
一定要了解應用程序的程式碼和熱點。哪些功能在 CPU 上花費的時間最多？哪些彙編程式碼受到的打擊最大？尤其是 CPU 上的哪些執行單元最努力地處理這些微指令？
火焰圖非常適合視覺化 CPU 功能。您提到了 EL 8，它具有打包的火焰圖工具。
yum install perf js-d3-flame-graph # system wide, 99 Hz, for 60 seconds perf script flamegraph -a -F 99 sleep 60對程序的開發人員級別的理解對於完全解釋結果是必要的。使用符號或原始碼，性能報告可以在類似調試器的體驗中進行註釋。