2010-12-15 46 views
7

我開始學習OpenMP,在集羣中運行示例(使用gcc 4.3)從https://computing.llnl.gov/tutorials/openMP/exercise.html。所有的例子做工精細,但我有一些問題:OpenMP調試新手問題

  1. 我怎麼知道在哪個節點(或每個節點的核心)有不同的線程是「跑」?
  2. 節點的情況下,發送信息並將其返回的平均傳輸時間(微秒或納秒)是多少?
  3. 什麼是調試OpenMP程序的最佳工具?
  4. 加速真實程序的最佳建議?

回答

7
  1. 通常您的OpenMP程序不知道,也不關心,哪個內核在運行。如果您有一個可以在其日誌文件中提供所需信息的作業管理系統。否則,你可能會在你的線程中插入調用環境並檢查某個環境變量的值。這就是所謂的,以及你如何做到這一點是平臺依賴,我會留給你看看。

  2. 我應該怎麼知道我(或任何其他的SOer)?對於一個有教養的猜測,你必須告訴我們更多關於你的硬件,操作系統,運行時系統等的信息。這個問題的最佳答案是你從你自己的測量中確定的。我擔心你可能會錯誤地認爲信息是通過計算機發送的 - 共享內存中的編程變量通常停留在一個地方(或者至少你應該考慮將它們留在一個地方,現實可能會變得更加混亂但也不可辨別)並且不被髮送或接收。

  3. 並行調試器如TotalViewDDT可能是最好的工具。我還沒有使用英特爾的調試器的並行功能,但他們看起來很有前途。我會把它交給資金不足的程序員來推薦自由/開源軟件,但他們都在那裏。

  4. i)爲您的問題選擇最快的並行算法。這不一定是並行最快的串行算法。

    ii)測試和測量。如果沒有數據,您無法進行優化,因此您必須對程序進行配置並瞭解性能瓶頸的位置。不要相信'X比Y快'的建議。這些言論通常基於非常狹隘且常常過時的案件,並且在其發起人腦海中成爲「真相」。幾乎總能找到反例。這是你想讓你的代碼更快,你的調查是無可替代的。

    iii)從裏面知道你的編譯器。您在調整編譯選項時花費的回報率(以代碼速度改進來衡量)遠遠高於「手動修改代碼」的回報率。

    iv)我堅持的'真理'之一是編譯器在當前處理器體系結構上優化使用內存層次結構方面不是非常好。這是代碼修改可能值得的一個領域,但直到您完成代碼的描述之後,您纔會知道這一點。

+0

+1;對於調試器,我會補充說gdb(和idb)具有非常穩固的線程支持,而對於通常針對OpenMP程序討論的核心計數(例如〜8),通常只需要這些就可以DDT或Eclipse驅動它的好的GUI功能。 – 2010-12-15 12:14:17

1
  1. 你不會知道,在不同的內核線程的分區由操作系統完全處理。你講的是節點,但OpenMP是一個多線程(而不是多進程)並行化,它允許包含多個內核的一臺機器進行並行化。如果你需要在不同的機器上進行並行化,你必須使用像OpenMPI這樣的多進程系統。

  2. 的通信時間數量級是:

    • 巨大在同一CPU內芯之間的通信的情況下,它可以被認爲是瞬時
    • 〜10 GB/s的之間的通信2個CPU橫跨主板
    • 〜100-1000 MB/s的節點之間的網絡通信,這取決於硬件的

    所有理論速度都應在硬件規格中指定。你也應該做一些基準知道你真的會有什麼。

  3. 對於OpenMP,gdb即使有很多線程也能很好地完成工作。

  4. 我在超級計算機的極端物理模擬工作,這是我們每天的目標:
    • 如作爲線程/進程之間可能的溝通較少使用,它是在並行作業
    • 殺演出通信99%的時間
    • 優化分割任務,機器負載應始終儘可能接近100%
    • 測試,調整,重新測試,重新調整...。並行化根本不是通用的「奇蹟解決方案」,它通常需要一些實際工作才能高效。