Re: [問題] MPI Non-blocking Communication

看板C_and_CPP (C/C++)作者justdemon (人生的轉捩點)時間16年前 (2009/11/24 01:08)推噓0(0推 0噓 5→)

留言5則, 1人參與討論串4/5 (看更多)

首先再次感謝T大和N大花時間解決我的問題 ^^ 我知道資料的傳輸多少會使用CPU 也不期望邊傳輸邊運算可以蓋住全部傳輸的時間我並不清楚Irecv會造成block? 這似乎和我的理解有所出入不過即便是如此我也試著寫Pthread的程式除了他有沒事做的一顆CPU讓我使用外的確會完整的蓋住傳輸時間不過這意味我非得空著一顆CPU專作傳輸非常的浪費在使用MPI同時Run兩個Job的情況下就如同我所說的在barrier之後一點都沒省下時間你們的意思是這是因為load balence的問題不過在我的sample code裡所有的node做的事情是一模一樣會造成快慢的差異應該只是單純的因為多個thread搶CPU資源造成的我的sample code的確什麼事情都沒做因為我只是想單純的簡化傳輸與運算是否可以並行的問題我試著讓Isend Irecv在傳輸時使用sleep讓CPU Idle 期望可以在CPU Idle時能全力進行資料的傳輸可是實測下我分別對sleep和waitall兩個函式計時 sleep就是五秒而wait的時間卻一丁點都沒少維持原樣意思是在只有傳輸的情況下花了4.7秒加上了sleep 他剛好就是9.7秒這意味著 Isene Irecv 並沒有在背後進行資料的傳輸直到 wait時才開始傳輸資料我也試著用繁雜無意義的運算取代 sleep 不論運算花多少時間 1~100秒的範圍都試過結果依然沒省下時間總時間就是運算加上傳輸運算時間如果再長一點運算的時間誤差就跟傳輸時間差不多義義似乎不太大再者wait的時間就剛好是原來的傳輸時間實在很難讓人相信他在背後有傳輸我知道平行運算load balance是很重要的一環 overhead主要就是資料交換與程式內不能平行運算的部分不瞞您說我也是試著在處理我的模擬平行化的load balance的問題我只是想最佳化程式的效率卻注意到Isend和Irecv並沒有省到時間的問題才寫出這個只有傳輸和無意義運算的簡化的code 我的原始問題當然不是長這個樣子我現在想要了解的是到底要如何才可以讓Isend Irecv在背後傳輸替我省下一點傳輸的時間謝謝 ^^ ※ 引述《neutronstars (I'm...)》之銘言： : ※ 引述《justdemon (人生的轉捩點)》之銘言： : 以你的程式來看， : 即使你用的是nonblocking send， : 但是node本身接收資料就是得耗費時間，也就是在recv時， : 是blocking的狀況，所以，當然是沒辦法同時運算， : 除非你有另一個thread另外在處理計算的問題， : 否則那個recv所在的thread就是會被blocking。 : 有些node較快、有些較慢，這是牽涉到load balance的問題， : 這問題甚至可以當個研究方向了， : 不過在你的sample code看起來是沒有處理這種問題，所以會發生這種現象應屬正常。 : 如果你是研究生，可以用此關鍵字查查paper，會找到很多相關的paper。 : : 謝謝T大的推文 : : 可是在我測試的環境相當的簡單盡量讓每個process做相同的事情 : : 我最原始的測試的code如下 : : http://nopaste.csie.org/b2860 : : 經過測試之後發現那個sleep(5) 就真的五秒都在那裡睡背後並沒有繼續傳輸 : : 我也試過用其他運算取代sleep 結果一樣 : : 全部的時間就是剛好等於傳輸時間+運算時間 : : 他的行為就像是 Isend只是標示出來有個東西要傳直到wait的時候才開始傳輸 : : 我也試過用MPI_Init_thread取代MPI_Init 結果也一樣 : : 不知道有沒有板友方便幫我測試一下這個簡單的程式呢? : : 謝謝 ^^ : 一般來說，平行計算第一個要考慮的問題就是「如何切割job？」， : 最簡單的作法，是先把整份工作切成相等於你的運算node數量， : （這裡假設有4個node，所以就是切成四份job） : 每個node就處理自己的那一份，理想上，可以獲取4倍效能提昇， : 但是為了要把這些「工作資訊」傳遞給其他node，或是node彼此之間的小溝通， : 所以會有「communication overhead」存在，所以一般來說效能提昇只會<= 4， : 不過這個也是有例外的，這邊就不多提。 : 因為從你的文中不太清楚你想要做的處理是什麼， : sample code裡面似乎也沒有做計算處理的部份， : 而且你的code似乎是寫成每個node都拿到整分資料， : 所以你的「傳輸成本」應該會很高才是。 : 希望有解答你的問題。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 219.71.218.214