MPI並行化有助於多次讀取大量數據

我被要求並行化現有的c程序以減少其運行時間。我只有一些（非常有限）使用基本MPI的經驗（而且我所有的編程知識都是自學的，所以它有點不準確）。我目前正試圖找出最佳的並行化方法。MPI並行化有助於多次讀取大量數據

當前，在主循環的每次迭代（M =迭代次數）期間，程序順序地訪問一組輸入文件（N =文件數） - 每個文件長度不同。在所有輸入文件被讀取後，程序對數據進行排序並更新一組輸出文件。 N和M在開始時都是已知的，並且N總是大於M.實際上，N太大而無法將所有輸入數據讀入內存，因此每次讀取文件時，只有與該主循環相關的信息迭代被保留。

我相信我可以使每個主循環迭代獨立，但每次迭代仍然需要訪問所有N個文件。使用OpenMPI（在Rocks上運行的技術上的OpenRTE 1.6.2，即RedHat Linux）來並行化該程序的最佳方式是什麼？

我的第一個想法是簡單地在多個線程中分離輸入文件的讀入，每個線程處理文件的子集，然後在最後對輸入進行排序。

我的第二個想法是將線程中的主M循環分開，這將更好地利用MPI。但是這種方法是否需要複製每個線程中的所有輸入文件（以避免讀取衝突）？如果是這樣，我擔心複製文件可能會抵消從主循環並行獲得的任何時間。另外，除了爲每種方法構建測試程序之外，是否還有更簡單的方法來確定哪種方法更快？

編輯：文件系統是NFS。

閱讀完評論後，我回過頭去對代碼進行了一些測試。該程序將其運行時讀數的93％用於數據。從已經說過的話來看，單獨的並行可能並不是最好的解決方案。在這一點上，似乎有必要真正查看程序的計算並儘量減少讀入需求。

非常感謝您的答覆。

來源

2016-02-08 Lance

你將在哪種文件系統上運行？並行化多少將有助於完全取決於文件系統的類型。單一的本地文件系統或共享的NFS將迅速收回報酬。如果你有一個並行的文件系統，比如光澤，或者你將文件分發到多個本地文件系統，那麼你可能會看到一些性能的提高，但是你需要調查文件系統的持續帶寬處理和在什麼條件下。 – jefflarkin

您可能會發現一對固態硬盤更便宜，性能提高超過幾小時。我認爲在決定優化什麼之前，您需要仔細衡量I/O和處理之間的平衡。 –

我正在使用具有4個節點的岩石羣集（每個節點24個處理器）。文件系統是NFS。除此之外，如果不先在Rocks手冊中查看它，我就不會了解該系統的其他任何內容。 – Lance

基於評論迴應，文件系統是NFS，你的意思是你正在通過網絡讀你的文件？如果你並行化了大約N文件的數量，這可能是非常有問題的。如果N太大，則一次可能會超過最大打開文件指針數量，這通常在/etc/security/limits.conf中定義。我知道如果shell類型是csh或tcsh，那麼如果在提示符下鍵入limit，它將顯示所有這些值。對不起，我忘記了在bash shell中顯示的命令。然後，您還有可能導致NFS超載，以及LAN或WAN帶寬問題。如果您的網絡速度爲100 mbps，那麼最好每秒只有12兆字節的數據量。如果你不檢查它，你怎麼知道它每秒鐘的千字節數不是真的？

如果程序運行時間的最大原因是數據讀取，那麼您可能對此無能爲力。除了NFS問題之外，我還會建議您考慮硬盤驅動器（無論位於何處）將被命令讀取每個數據塊/文件。我認爲通常最好只讀取一個文件指針，儘可能按順序讀取磁盤驅動器中的數據，這將使您瞭解如何緩存要在程序中使用的數據。如果你有足夠的內存，你需要做數學和數字計算。如果不是，那麼這將是你需要增加，否則你被迫依靠磁盤I/O這是一個殺手。

來源

2016-02-09 03:26:03 ron

對NFS的並行I/O是一個傻瓜差事。 MPI實現將盡力而爲，但除了串行外，NFS還會提供可怕的一致性語義。客戶端寫入顯示其他進程在某些未定義的時間。您可以關閉每個操作的緩存和fcntl-lock，但仍然無法達到您所期望的一致性。

MPI實現提供NFS支持，因爲NFS是無處不在，但不更努力，你可以部署類似PVFS/OrangeFS，應該剖析確定I/O實際上是你的一個重要瓶頸。

來源

2016-02-11 17:17:38

MPI並行化有助於多次讀取大量數據

回答

相關問題