2016-07-31 184 views
8

此問題最初發佈於Github #3320。如果在那個線程中有更多關於原始問題的細節,並且體積龐大,我不希望在StackOverflow上重新發布,那麼從這裏開始會很好。這個問題的總結是當使用GPU比CPU處理TensorFlow圖時性能更慢。包含CPU/GPU時間軸(調試)用於評估。其中一條評論意見涉及到優化Graph以加快處理速度,並請求討論玩具示例。 「原始解決方案」是我的強化學習代碼,顯示性能下降,併爲社區討論和評估創建了一些已發佈的代碼。TensorFlow:圖形優化(GPU vs CPU性能)

我已經附上測試腳本以及一些原始數據,跟蹤文件& TensorBoard日誌文件,以加快任何審查。 CPUvsGPU testing.zip

由於此主題將使所有Tensorflow用戶受益,因此討論轉移到了StackOverflow。我希望發現的是優化已發佈圖形性能的方法。 GPU與CPU的問題可以分離出來,因爲它可以通過更高效的TensorFlow Graph解決。

我所做的就是拿我的原創解決方案,並剝離出「遊戲環境」。我用隨機數據代替它。在這個遊戲環境中,沒有創建/修改TensorFlow圖形。該結構嚴格遵循/利用nivwusquorum's Github Reinforcement Learning Example

在2016年7月15日我做了一個「git拉」頭來Tensorflow。我在啓用和不啓用GPU的情況下執行Graph並記錄時間(參見附圖)。意想不到的結果是GPU的性能超過了CPU(這是最初的期望沒有得到滿足)。所以這個帶有支持庫的代碼「cpuvsgpu.py」在GPU上表現更好。所以我將注意力轉移到我的原始解決方案與已發佈的代碼之間可能會有所不同。我也更新頭至2016年7月17日。由於CPU & GPU與原始解決方案之間的整體差異比我看到47s CPU vs 71s GPU再次接近一週的時間有所提高。快速瀏覽一下新的Traces vs我的初始跟蹤,好像「摘要」可能已經改變了,但也可能有其他改進。

gtx 950 timing

我試過其他2點的組合,以更好地反映原液如何運作。這些CPU負載很重(約60% - 70%),並且通過並行執行該腳本來模擬這些負載。另一種變化是增加「數據IO」,原始解決方案使用觀察列表來隨機選擇用於訓練的觀察值。該列表具有固定的上限,然後開始刪除列表中的第一個項目,同時追加新的項目。我想可能其中有一個是放慢數據流向GPU。不幸的是,這些版本都沒有使CPU的性能超過GPU。我還運行了一個快速的GPUTESTER應用程序,它可以執行大型矩陣乘法以獲得與任務大小的時間差異,並且如預期的那樣。

我真的很想知道如何改善這個圖表並減少小型OPS的數量。看起來這是大部分表現可能發生的地方。學習任何技巧將較小的操作符合併成較大的操作符而不會影響圖的邏輯(函數)會很好。

+1

針對GPU性能爲7K比較X 7K MATMUL可以是這裏錯誤的度量。 IE中,我看到你最慢的操作需要<1ms,這意味着你的數據量很小,所以你可以在微小的數據大小上對GPU和CPU進行微型基準測試,以瞭解移動到的時候應該有多少收益(或損失) GPU –

+0

我的7K x 7K數據集的主要用途更多的是確保GPU實際工作。所以對於大型任務來說,GPU很好。這對我來說更像是GPU的原始問題比GPU正確安裝並且CUDA編譯的CPU更慢的證明。 – mazecreator

+0

然後網絡運行一批200×189到5層與Dropout()之間的每層。輸出層數爲140,120,100,80和3。 – mazecreator

回答

2

Results感謝您的優秀帖子。

我遇到了類似的問題:GPU/CPU處理比TensorFlow提供的兩個示例需要更多的CPU和處理時間:線性迴歸損失模型和初學者MNIST,而MNIST Deep腳本顯示在使用GPU Profiling GPU and CPU Performance第10頁時CPU和Elapsed的顯着改進開始討論。

這裏是數字:

workload  | win 8.1 win 8.1 win8.1  win 10 win 10 win 10 
workload  | cpu only cpu  gpu  cpu only cpu  gpu  
-------------+----------------------------------------------------------- 
mnist deep | 14053  384.26 328.92  12406  289.28 211.79 
mnist deep | 14044  384.59 328.45  12736  293.71 210.48 
mnist10,000 | 24.10  45.85  7.67  26.56  44.42  7.32 
mnist10,000 | 23.94  44.98  7.56  25.80  44.24  7.32 
mnist50,000 | 95.49  198.12 38.26  109.99  197.82 36.15 
mnist50,000 | 96.07  197.86 37.91  109.46  195.39 39.44 
    lr10,000 | 6.23  15.08  1.78  7.38  16.79  1.91 
    lr10,000 | 6.33  15.23  1.78  7.44  16.59  1.91 
    lr100,000 | 48.31  124.37 17.67  62.14  148.81 19.04 
    lr100,000 | 48.97  123.35 17.63  61.40  147.69 18.72 

(來源:Profiling GPU and CPU Performance,圖64 Results

+1

儘管鏈接可能回答問題,但最好在此包含答案的基本部分,並提供供參考的鏈接。如果鏈接頁面更改,則僅鏈接答案可能會失效。請閱讀此[如何回答](http://stackoverflow.com/help/how-to-answer)以提供高質量的答案。 – thewaywewere

+0

圖18 +圖19 VTUNE性能熱點揭祕。唯一缺少的細節是訪問設備內存類型的實際TimeDOMAIN成本。 SMX架構在數學上「密集」的計算內核上很出色,但**在訪問'__global__'內存時具有巨大的〜350-700 [ns]的延遲**(這對於ML類DataSet的不可避免的必需條件* * ...所以**現實的TimeDOMAIN成本**主要**與Peta-FLOPs狩獵微基準**無法比擬,因此被產品營銷人員和gals所喜愛)。不要驚慌,真正的使用情況會帶來很多驚喜。 – user3666197