2017-09-17 168 views
1

我有一些使用PGI編譯器編譯的OpenACC加速C++代碼。事情似乎有效,所以現在我想用分析信息來發揮效率。解釋PGI_ACC_TIME輸出

我通過設置產生一些定時信息:

export PGI_ACC_TIME=1 

,然後運行該程序。

的輸出結果如下:

-bash-4.2$ ./a.out 
libcupti.so not found 

Accelerator Kernel Timing data 
    PGI_ACC_SYNCHRONOUS was set, disabling async() clauses 
/home/myuser/myprogram.cpp 
    _MyProgram NVIDIA devicenum=1 
    time(us): 97,667 
    75: data region reached 2 times 
     75: data copyin transfers: 3 
      device time(us): total=101 max=82 min=9 avg=33 
    76: compute region reached 1000 times 
     76: kernel launched 1000 times 
      grid: [1938] block: [128] 
      elapsed time(us): total=680,216 max=1,043 min=654 avg=680 
    95: compute region reached 1000 times 
     95: kernel launched 1000 times 
      grid: [1938] block: [128] 
      elapsed time(us): total=487,365 max=801 min=476 avg=487 
    110: data region reached 2000 times 
     110: data copyin transfers: 1000 
      device time(us): total=6,783 max=140 min=3 avg=6 
     125: data copyout transfers: 1000 
      device time(us): total=7,445 max=190 min=6 avg=7 

real 0m3.864s 
user 0m3.499s 
sys  0m0.348s 

它提出了一些問題:

  1. 我看到time(us): 97,667在頂部。這個好像是總共的時間,但是在底部,我看到了real 0m3.864s。爲什麼會有這樣的差異?

  2. 如果總數爲time(us): 97,667,爲什麼它比下降的值小很多,如elapsed time(us): total=680,216

  3. 該內核包括行(elapsed time(us): total=680,216 max=1,043 min=654 avg=680)運行1000次。是基於內核的每次運行值的最大值,最小值和平均值?

  4. 由於[grid][block]值可能會有所不同,經過的總值仍然是熱點的一個很好的指標?

  5. 對於數據區域(device time(us): total=6,783)是測量轉移時間還是花在處理數據(準備轉移,收貨後操作)上的全部時間?

  6. 行編號很奇怪。例如,我的程序中的第76行顯然是一個for循環,第95行是一個大括號,而第110行是一個變量定義。行號應該被解釋爲「最接近指定行號的循環」,或以其他方式?

  7. 76處的內核包含95處的內核。計算的時間是76,包括在95中花費的時間嗎?如果是這樣,有沒有一種方便的方法來查找在覈心中花費的時間減去所有子核心的時間?

(其中的一些問題是有點肛門固,但我還沒有找到這個文件,所以我想我是徹底的。)這裏的問題的

回答

1

部分原因是運行時無法找到CUDA分析庫(libcupti.so),因此您只能看到PGI CPU側分析而不是設備分析。 PGI使用編譯器($ PGI/[linux86-64 | linuxpower]/2017/cuda/[7.5 | 8.0]/lib64)下載了libcupti.so庫,但這是可選的安裝,因此您可能沒有安裝它你在跑步。 CUPTI還附帶了CUDA SDK,因此如果系統安裝了CUDA,則可以嘗試設置您的LD_LIBRARY_PATH。在我的系統上,它安裝在「/opt/cuda-8.0/extras/CUPTI/lib64/」中。

缺失的CUPTI庫就是爲什麼你看到文件時間不好的時候,97,667。另外,由於你錯過了CUPTI,你看到的時間是從主機測量的。通過CUPTI,除了時間流逝之外,您還可以看到每個內核的設備時間。經過時間和設備時間之間的差異是每個內核的啓動開銷。

最大值,最小值和平均值是基於內核的每次運行值嗎?

是的。

4.由於[網格]和[塊]值可能會有所不同,經過的總值仍然是一個很好的熱點指標?

我傾向於先看看平均時間,因爲通常有更多的機會來調整這些循環。如果你改變每次核心迭代的工作量(即網格大小的變化),那麼它可能不是有用的,但是一個好的起點。

現在,如果您的平均值較低但調用次數較多,則耗用時間可能會受內核啓動開銷的影響。在這種情況下,我會考慮是否可以合併循環或將更多工作推送到每個循環中。

5.對於數據區域(設備時間(美國):總= 6783)是測量傳輸時間或者整個時間花費處理數據 (準備傳送,接收後操作)?

只是數據傳輸時間。對於開銷,您需要使用PGPROF/NVPROF。

6.行編號很奇怪。例如,我的程序中的第76行顯然是一個for循環,第95行是一個大括號,第110行是一個 變量定義。行號應該被解釋爲「最接近指定行號的循環 」,或者其他一些其他的 方式?

這是因爲代碼已經過優化,所以行號可能有點偏離,但它應該與編譯器反饋消息(-Minfo = accel)的行號相對應。所以「循環最緊密......」選項應該是正確的。

+0

謝謝!我追蹤了'libcupti.so',事實上,現在時機更加明智了。我還在上面添加了第7個問題:「76處的內核包含95的內核。是否計算了包含95個時間在內的76個時間?如果是這樣,是否有一種方便的方法來查找在內核中花費的時間減去所有子核的時間?「 – Richard

+0

問題7我不清楚。這兩個內核是獨立的計算區域,所以76不能包含95.你的意思是在76內核中有一個設備子程序調用嗎?如果是這樣,最接近你可以使用PGPROF源代碼反彙編視圖(http://www.pgroup.com/resources/docs/17.7/x86/profiler-users-guide/index.htm#source-assembly-視圖),它使用採樣來獲取行級別信息。務必使用「-Muda = lineinfo」進行編譯,以確保編譯器保留行信息。此外,抽樣可能會侵入,所以時間可能會更長。 –