Медленность первого cudaMalloc (K40 vs K20), даже после cudaSetDevice

Question

Я понимаю, что CUDA выполнит инициализацию во время первого вызова API, но затраченное время слишком велико. Даже после того, как отдельный cudaSetDevice

Программа испытаний:

та же программа построена с: CUDA 7.0 (compute_35) + Visual Studio 2012 + Nsight 4,5, а затем был бежать в 2 отдельных машинах (не по восстановлению)

До 1 cudaMalloc, я назвал «cudaSetDevice»

на моем компьютере: Win7 + Tesla K20, первый cudaMalloc принимает 150MS

на моем сервере: Win2012 + Tesla K40, требуется 1100 мс!

Для обеих машин последующий cudaMalloc намного быстрее.

Мои вопросы:

1, Почему K40 занимает гораздо больше времени (1100ms против 150мс) для 1-го cudaMalloc? Поскольку K40 должен быть лучше K20

2, я думал, что «cudaSetDevice» может захватить время Init? например This Answer from talonmies

3, Если инициализация неизбежна, может обрабатывать A поддерживать свой статус (или контекст) в графическом процессоре, когда процесс B работает на одном GPU? Я понимаю, что лучше запустить GPU в «эксклюзивном» режиме, но может обрабатывать «приостановку», так что позже не нужно снова инициализировать GPU?

Заранее спасибо

Answer 1

1 Почему K40 занимает гораздо больше времени (1100ms против 150мс) для 1-го cudaMalloc? Поскольку K40 должен быть лучше K20

Детали процесса инициализации не указаны, однако при наблюдении объем системной памяти влияет на время инициализации. Инициатива CUDA обычно включает установление UVM, что предполагает согласование карт памяти устройства и хоста. Если на вашем сервере больше системной памяти, чем на вашем ПК, это одно из возможных объяснений несоответствия времени инициализации. ОС также может иметь эффект, и, наконец, размер памяти графического процессора может иметь эффект.

2, я думал, что «cudaSetDevice» может захватить время Init? например Этот ответ от talonmies

Процесс инициализации CUDA является «ленивой» инициализацией. Это означает, что достаточно всего процесса инициализации будет завершена, чтобы поддержать запрошенную операцию. Если запрошенная операция равна cudaSetDevice, для этого может потребоваться меньше завершения инициализации (что означает, что требуемое время может быть короче), чем если запрошенная операция равна cudaMalloc. Это означает, что некоторые из служебных данных инициализации могут быть поглощены операцией cudaSetDevice, в то время как некоторые дополнительные служебные данные инициализации могут быть поглощены в последующую операцию cudaMalloc.

3, Если инициализация неизбежна, может обрабатывать A поддерживать свой статус (или контекст) в графическом процессоре, когда процесс B работает на одном GPU? Я понимаю, что лучше запустить GPU в «эксклюзивном» режиме, но может обрабатывать «приостановку», так что позже не нужно снова инициализировать GPU?

Независимые процессы хоста, как правило, создаются независимо CUDA contexts. Контекст CUDA имеет связанное с ним требование инициализации, поэтому тот факт, что другой, отдельный контекст cuda может быть уже инициализирован на устройстве, не принесет большой пользы, если новый CUDA-контекст должен быть инициализирован (возможно, из отдельного хост-процесса). Как правило, сохранение активного процесса связано с тем, что приложение работает в этом процессе. Приложения имеют различные механизмы «спать» или приостанавливать поведение. Пока приложение не завершено, любой контекст, установленный этим приложением, не должен требовать повторной инициализации (за исключением, возможно, если вызывается cudaDeviceReset).

В целом, некоторые преимущества могут быть получены в системах, которые позволяют графическим процессорам перейти в режим глубокого холостого хода, установив режим сохранения GPU (используя nvidia-smi). Однако это не будет актуально для графических процессоров GeForce, и это будет несовместимо с системой Windows.

Кроме того, при использовании нескольких GPU-систем, если для приложения не требуется несколько графических процессоров, обычно можно избежать некоторого времени инициализации, используя CUDA_VISIBLE_DEVICESenvironment variable, чтобы ограничить время выполнения CUDA только использованием необходимых устройств.

Answer 2

В зависимости от целевой архитектуры, скомпилированной для кода и архитектуры, в которой выполняется код, компиляция JIT может использовать первый вызов cudaMalloc (или любой другой). «Если двоичный код не найден, но доступен PTX, тогда драйвер компилирует код PTX». Некоторые подробности:

http://devblogs.nvidia.com/parallelforall/cuda-pro-tip-understand-fat-binaries-jit-caching/