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

Question

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

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

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

Update:

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Надеется, что это помогает!