MPI_Allgather是我的代碼瓶頸，如何解決？

Question

我有一個程序，目的是將特定數據添加到一個主數組中。 passesTest(randomNumber)執行百萬次隨機數測試passesTest(randomNumber) ，偶爾通過測試，並將隨機數壓入數組的末尾。 因此，在大多數情況下，數組只是在計算進行時坐在那里。

我決定將此過程與MPI並行化，因為我發現執行隨機數測試的1000個處理器將大大提高速度，並且由於內存寫入很少，因此MPI應該非常適合這項工作。 令我非常沮喪的是，使用mpirun -np 1可以使我的程序運行最快，而添加的每個進程的運行速度都大大降低。

在包含passesTest(randomNumber) while循環結束while ，我有MPI::COMM_WORLD.Allgather()從每個進程中收集一個標志，該標志指示是否存在需要推入數組的新隨機數。 如果任何標志為true那么我將執行另一個Allgather()來實際收集此數據，並將其推入數組的每個進程的本地副本中。 同樣，第二個Allgather()很少執行，因為該測試很少通過。

所以我猜我的瓶頸是從每個MPI進程收集所有標志，以查看是否有新數據。 對每個隨機數的測試都可以快速執行，因此，我認為由於從多個進程收集數據的開銷，現在每秒減少了數十億次while循環。 這是一個很好的猜測嗎？ 我是MPI的新手，所以我不知道Allgather()涉及哪種時間表。

如果這是原因，那么通過測試后，我如何才能僅與其他進程“交互”？ 這真的是我要做的。 換句話說，如果一個隨機數通過了測試，則向所有其他進程發送一條消息，以停止它們正在執行的操作並將該數字添加到其數組中。

Answer 1

首先，我強烈支持Voo和Hristo Iliev的評論。

從MPI_Allreduce開始檢查通過顯然是更快的-它需要傳輸的數據要少得多。 但是，Allreduce仍然需要> 2 * log2(n) * latency 。 對於1000個進程，取決於您的系統，可能約為100微秒。 如果您每秒進行數百萬次測試，這意味着每個測試僅花費100納秒，那么很明顯，每次測試之后的集體操作確實會破壞您的性能-不管每個通信步驟的設計多么理想。

現在，在不了解依賴性的情況下，很難提出基本的改進建議。 您可以考慮在假設沒有命中的情況下以推測方式執行多個迭代，並在發現有命中之后丟棄無效的迭代。

除此之外，我建議使用MPI_Allreduce和MAX來確定需要添加的最高隨機數。 重復該操作，直到所有添加。 很明顯，這通常只有在添加很少的情況下才有效。