htop和OpenMP線程

Question

在主要功能中，我設置了：

omp_set_num_threads(20);

它告訴OpenMP使用20個線程（有40個可用線程）。

然后，我執行包含指令的代碼：

#pragma omp parallel for shared(x,y,z)

用於主要的for循環，並通過htop監視CPU使用情況（也許不是最好的方法，但仍然可以）。 for循環必須執行50個“任務”，每個任務都需要花費相當長的時間。 我通過htop觀察到的是，任務完成后，線程數下降了。 具體來說，我希望使用20個線程，直到剩余的任務少於20個之后，線程才能“釋放”自己，從而看到2000％的cpu使用率。 但是，我看到的是前2000％，在完成n個任務后，我看到了2000％-（n * 100％）的性能。 因此，似乎隨着任務的完成，線程將關閉而不是接管新任務。

這是意料之中的還是聽起來很奇怪？

Answer 1

幾乎所有現有OpenMP編譯器的默認並行循環調度是static ，這意味着OpenMP運行時將嘗試在線程之間平均分配迭代空間並進行靜態工作分配。 由於您有50個迭代和20個線程，因此工作無法平均分配，因為20不會除以50。因此，一半的線程將執行三個迭代，而另一半則將執行兩個迭代。

在（組合parallel ）的末尾有一個隱式屏障， for構造，即較早完成的線程等待其余線程完成。 根據OpenMP的實現，屏障可以實現為繁忙的等待循環，某些OS同步對象上的等待操作或兩者的組合。 在后兩種情況下，遇到障礙的線程的CPU使用率將在它們進入可中斷睡眠時立即下降為零，或者最初在短時間內保持100％（繁忙循環），然后下降為零（這段等待）。

如果循環迭代花費的時間完全相同，則將發生以下情況：最初的CPU使用率將為2000％，然后經過兩次迭代（如果barrier實現使用短繁忙循環，則將增加更多），將降至1000 ％。 如果每次迭代花費不同的時間，那么線程將在不同的時刻到達障礙，並且CPU使用率將逐漸降低。

在任何情況下，都可以使用schedule(dynamic)使每個線程的每個迭代都可用。 在迭代花費不同時間的情況下，這將提高CPU利用率。 當每次迭代花費相同的時間量時，這將無濟於事。 在后一種情況下，解決方案是使迭代數為線程數的整數倍。