медлительность первого cudaMalloc (K40 против K20), даже после cudaSetDevice
Я понимаю, что CUDA выполнит инициализацию во время первого вызова API, но затраченное время слишком много. Даже после отдельного cudaSetDevice
Тестовая программа:
Та же самая программа, созданная с помощью: CUDA 7.0 (compute_35) + Visual Studio 2012 + NSight 4.5, затем была запущена на 2 отдельных машинах (без перестройки)
До 1-го cudaMalloc я называлась «cudaSetDevice»
на моем ПК: Win7 + Tesla K20, 1-й cudaMalloc занимает 150 мс
на моем сервере: Win2012 + Tesla K40, это занимает 1100мс!
Для обеих машин последующие cudaMalloc выполняются намного быстрее.
Мои вопросы:
1, почему K40 занимает гораздо больше времени (1100мс против 150мс) для первого cudaMalloc? Поскольку К40 должен быть лучше, чем К20
2, я думал, что «cudaSetDevice» может захватить время инициализации? например Этот ответ от talonmies
3. Если инициализация неизбежна, может ли процесс A поддерживать свой статус (или контекст) в графическом процессоре, пока процесс B работает в том же графическом процессоре? Я понимаю, что лучше запускать GPU в «эксклюзивном» режиме, но могу ли обработать «приостановку», чтобы позже не нужно было инициализировать GPU?
заранее спасибо
Решение
1, почему K40 занимает гораздо больше времени (1100мс против 150мс) для первого cudaMalloc? Поскольку К40 должен быть лучше, чем К20
Детали процесса инициализации не уточняются, однако, наблюдая, как объем системной памяти влияет на время инициализации. Инициализация CUDA обычно включает создание УВМ, который включает в себя согласование карт памяти устройства и хоста. Если на вашем сервере больше системной памяти, чем на вашем ПК, это одно из возможных объяснений несоответствия времени инициализации. Операционная система также может оказать влияние, наконец, может повлиять размер памяти графического процессора.
2, я думал, что «cudaSetDevice» может захватить время инициализации? например Этот ответ от talonmies
Процесс инициализации CUDA — это «ленивая» инициализация. Это означает, что достаточно для завершения процесса инициализации, чтобы поддержать запрошенную операцию. Если запрошенная операция cudaSetDeviceдля этого может потребоваться меньше инициализации (что означает, что требуемое время может быть короче), чем если запрошенная операция cudaMalloc, Это означает, что некоторые из издержек инициализации могут быть поглощены cudaSetDevice операции, в то время как некоторые дополнительные издержки инициализации могут быть поглощены в последующем cudaMalloc операция.
3. Если инициализация неизбежна, может ли процесс A поддерживать свой статус (или контекст) в графическом процессоре, пока процесс B работает в том же графическом процессоре? Я понимаю, что лучше запускать GPU в «эксклюзивном» режиме, но могу ли обработать «приостановку», чтобы позже не нужно было инициализировать GPU?
Независимые хост-процессы, как правило, порождают независимые Контексты CUDA. С контекстом CUDA связано требование инициализации, поэтому тот факт, что другой, отдельный контекст cuda может быть уже инициализирован на устройстве, не даст большого преимущества, если необходимо инициализировать новый контекст CUDA (возможно, из отдельного хост-процесса). Как правило, поддержание активного процесса включает в себя поддержание приложения в этом процессе. Приложения имеют различные механизмы для «сна» или приостановки поведения. Пока приложение не завершено, любой контекст, установленный этим приложением, не должен требовать повторной инициализации (за исключением, возможно, если cudaDeviceReset называется).
В общем, некоторая выгода может быть получена в системах, которые позволяют графическим процессорам переходить в режим глубокого простоя, устанавливая режим сохранения графического процессора (используя nvidia-smi). Однако это не будет актуально для графических процессоров GeForce и не будет в целом актуально для системы Windows.
Кроме того, в системах с несколькими графическими процессорами, если приложению не требуется несколько графических процессоров, обычно можно избежать некоторого времени инициализации с помощью CUDA_VISIBLE_DEVICES переменная окружения, ограничить время выполнения CUDA, чтобы использовать только необходимые устройства.
Другие решения
В зависимости от целевой архитектуры, для которой компилируется код, и архитектуры, в которой выполняется код, JIT-компиляция может вступить в действие с первым вызовом cudaMalloc (или любым другим). «Если двоичный код не найден, но PTX доступен, драйвер компилирует код PTX». Еще несколько деталей:
http://devblogs.nvidia.com/parallelforall/cuda-pro-tip-understand-fat-binaries-jit-caching/