Интерпретация вывода PGI_ACC_TIME

Question

Интерпретация вывода PGI_ACC_TIME

У меня есть некоторый ускоренный OpenACC код C ++, который я скомпилировал с помощью компилятора PGI. Вещи, кажется, работают, так что теперь я хочу поиграть в эффективность с профилированием информации.

Я генерирую некоторую информацию о времени, устанавливая:

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

Это поднимает некоторые вопросы:

я вижу time(us): 97,667 на вершине. это кажется как общее время, но в нижней части я вижу real 0m3.864s, Почему такая разница?
Если time(us): 97,667 итого, почему оно намного меньше значений ниже, таких как elapsed time(us): total=680,216?
Это ядро включая строчку (elapsed time(us): total=680,216 max=1,043 min=654 avg=680) был запущен 1000 раз. Значения max, min и avg основаны на значениях ядра для каждого прогона?
Так как [grid] а также [block] значения могут отличаться. Являются ли прошедшие общие значения хорошим индикатором горячих точек?
Для областей данных (device time(us): total=6,783) время передачи измерений или все время, потраченное на обработку данных (подготовка к передаче, операции после получения)?
Нумерация строк странная. Например, строка 76 в моей программе явно for цикл, строка 95 in — это закрывающая скобка, а строка 110 — определение переменной. Должны ли номера строк интерпретироваться как «цикл, наиболее точно следующий за указанным номером строки», или как-то иначе?
Ядро в 76 содержит ядро в 95. Рассчитано ли время для 76 включительно времени, проведенного в 95? Если это так, есть ли удобный способ найти время, проведенное в ядре, за вычетом времени всех подядер?

(Некоторые из этих вопросов немного анальные, но я не нашел документации для этого, поэтому я подумал, что я буду тщательным.)

1

c++openacc pgi

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Частично проблема заключается в том, что среда выполнения не может найти библиотеку CUDA Profiling (libcupti.so), поэтому вы видите только профилирование на стороне PGI, а не профилирование устройства. PGI поставляется с библиотекой libcupti.so с компиляторами (в каталоге $ PGI / [linux86-64 | linuxpower] / 2017 / cuda / [7.5 | 8.0] / lib64), но это необязательная установка, поэтому ее установка в системе может быть невозможна. ты бежишь. CUPTI также поставляется с CUDA SDK, поэтому, если в системе установлена CUDA, вы можете вместо этого попробовать установить там LD_LIBRARY_PATH. В моей системе это установлено в «/opt/cuda-8.0/extras/CUPTI/lib64/».

Отсутствующая библиотека CUPTI — вот почему вы видите плохое время, 97 667, для времени файла. Кроме того, поскольку вы пропускаете CUPTI, время, которое вы видите, измеряется с хоста. С CUPTI, помимо истекшего времени, вы увидите время устройства для каждого ядра. Разница между истекшим временем и временем устройства — это издержки запуска на ядро.

Значения max, min и avg основаны на значениях ядра для каждого прогона?

Да.

4. Поскольку значения [grid] и [block] могут различаться, все ли прошедшие общие значения все еще являются хорошим индикатором горячих точек?

Я склонен сначала смотреть на среднее время, так как обычно есть больше возможностей для настройки этих циклов. Если вы изменяете объем работы для каждой итерации ядра (т. Е. Изменяется размер сетки), то это может быть не столь полезным, но хорошей отправной точкой.

Теперь, если у вас было низкое среднее значение, но много вызовов, то в затраченном времени могут преобладать накладные расходы на запуск ядра. В этом случае я хотел бы посмотреть, сможете ли вы объединить циклы или добавить больше работы в каждый цикл.

5.Для областей данных (время устройства (нас): всего = 6 783) — время передачи измерения или все время, потраченное на обработку данных.
(подготовка к переводу, операции после получения)?

Просто время передачи данных. Для накладных расходов вам потребуется использовать PGPROF / NVPROF.

6. Нумерация строк странная. Например, строка 76 в моей программе явно является циклом for, строка 95 — закрытой скобкой, а строка 110 —
определение переменной. Должны ли номера строк интерпретироваться как «цикл
наиболее близко следующий за указанным номером строки «, или в некоторых других
путь?

Это потому, что код был оптимизирован, поэтому номер строки может быть немного не соответствующим, хотя он должен соответствовать номерам строк в сообщениях обратной связи компилятора (-Minfo = accel). Таким образом, опция «цикл наиболее близко …» должна быть правильной.

1