Почему код CUDA работает быстрее в NVIDIA Visual Profiler? - программирование
Подтвердить что ты не робот

Почему код CUDA работает быстрее в NVIDIA Visual Profiler?

Часть кода, которая занимает хорошо в течение 1 минуты в командной строке, была выполнена в течение секунд в Visual Profiler NVIDIA (работает с тем же .exe). Так почему же возникает естественный вопрос? Что-то не так с командной строкой, или Visual Profiler делает что-то другое и не выполняет все как в командной строке?

Я использую CUBLAS, Thrust и cuRAND.

Кстати, заметное замедление скомпилированного кода на моей машине совсем недавно, даже старый код, который раньше выполнялся быстро, поэтому я становлюсь подозрительным.

Update:

  • Я проверил, что рассчитанный вывод в командной строке и Visual Profiler идентичен - то есть весь требуемый код был запущен в обоих случаях.
  • GPU-shark указала, что мое состояние производительности не изменилось на P0, когда я переключился с командной строки на Visual Profiler.
  • Тем не менее, использование графического процессора сообщалось при 0.0% при запуске с Visual Profiler, но превышало 98% при запуске командной строки.
  • Кроме того, в Visual Profiler используется меньше памяти. При запуске командной строки диспетчер задач указывает использование 650-700 МБ памяти (шипы при первом вызове cudaFree(0)). В Visual Profiler этот показатель уменьшается до ~ 100 МБ.
4b9b3361

ОТВЕТЫ

Ответ 1

Это старый вопрос, но я только что преследовал ту же проблему (хотя причина может быть не такой).

А именно: мое приложение достигло от 900 до 1100 кадров (синхронных запусков) в секунду при работе под NVVP, но около 100-120 при запуске за пределами профилировщика.

Причиной представляется сообщение о состоянии, которое я печатал на консоли с помощью cout. Я предполагал, что это произойдет примерно раз в 100-200 кадров. Вместо этого он печатал сообщение о состоянии для каждого кадра, а консоль IO стала узким местом.

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

NVVP должен перенаправить stdout в свой собственный внутренний буфер, чтобы захватить вывод приложения (который он показывает на вкладке консоли). Похоже, что механизм NVVP для буферизации или обработки этого вывода имеет значительно меньшие накладные расходы, чем позволяет операционной системе обрабатывать его напрямую. Похоже, что NVVP выполняет буферизацию всего и отображает ее в отдельном потоке или просто сохраняет кучу вывода до тех пор, пока не будет достигнут определенный порог, когда он добавит этот буфер на свою собственную вкладку консоли.

Итак, моим советом было бы отключить любую консоль ввода-вывода и посмотреть, влияет ли это на что-то.

(Это не помогло VS2012 отказаться от профилирования моего приложения CUDA. Было бы неплохо увидеть, что 80% времени выполнения было потрачено на консоль IO.)

Надеюсь, это поможет!

Ответ 2

Этого не должно быть. Я никогда не видел ничего подобного; возможно, что-то в вашей настройке.

Ответ 3

Возможно, что какой-то шаг JIT-компиляции пропущен профилировщиком. Это может объяснить разницу в использовании памяти. Попробуйте создать fat binary?