cuda - nvprof - nvidia profiler

Tiempo entre el lanzamiento del kernel y la ejecución del kernel

Question

Estoy tratando de optimizar mi programa CUDA utilizando la edición Parallel Nsight 2.1 para VS 2010.

Mi programa se ejecuta en una máquina con Windows 7 (32 bits) con una placa GTX 480. He instalado el kit de herramientas CUDA 4.1 de 32 bits y el controlador 301.32.

Un ciclo en el programa consiste en una copia de los datos del host en el dispositivo, la ejecución de los núcleos y la copia de los resultados del dispositivo al host.

Como puede ver en la imagen de los resultados del generador de perfiles a continuación, los núcleos se ejecutan en cuatro flujos diferentes. El kernel en cada flujo se basa en los datos copiados en el dispositivo en ''Stream 2''. Es por eso que asyncMemcpy se sincroniza con la CPU antes del lanzamiento de Kernels en las diferentes corrientes.

Lo que me irrita en la imagen es la gran brecha entre el final del primer lanzamiento del núcleo (en 10.5778679285) y el comienzo de la ejecución del kernel (en 10.5781500). Se necesitan alrededor de 300 us para lanzar el kernel, que es una gran sobrecarga en un ciclo de procesamiento de menos de 1 ms.

Además, no hay superposición de la ejecución del núcleo y la copia de datos de los resultados al host, lo que aumenta aún más la sobrecarga.

¿Hay alguna razón obvia para este comportamiento?

Answer 1

Hay tres problemas que puedo decir por el rastro.

1. Nsight CUDA Analysis agrega alrededor de 1 μs por llamada API. Tiene tanto el tiempo de ejecución de CUDA como el rastreo de la API de controlador CUDA habilitados. Si tuviera que deshabilitar el rastreo del tiempo de ejecución de CUDA, supongo que reduciría el ancho en 50 μs.

2. Como está en GTX 480 en Windows 7, se está ejecutando en el modelo de controlador WDDM. En WDDM, el controlador debe hacer una llamada al kernel para enviar trabajos que introducen muchos sobrecargas. Para evitar reducir esta sobrecarga, el controlador CUDA almacena temporalmente las solicitudes en una cola interna de SW y envía las solicitudes al controlador cuando la cola está llena y se descarga por una llamada de sincronización. Es posible usar tu cudaEventQuery para obligar al controlador a purgar el trabajo, pero esto puede tener otras implicaciones de rendimiento.

3. Parece que estás enviando tu trabajo a las transmisiones de una manera profunda. En los dispositivos de capacidades de cómputo 2.x y 3.0 obtendrá mejores resultados si envía los flujos de manera amplia. En su caso, puede ver superposición entre sus núcleos.

La captura de pantalla de la línea de tiempo no proporciona suficiente información para que yo pueda determinar por qué las copias de memoria se inician después de completar todos los núcleos. Dado el patrón de llamadas API I, usted debería poder ver las transferencias comenzando después de que cada transmisión complete su lanzamiento.

Si está esperando la finalización de todas las transmisiones, es más probable que realice una sincronización cudaDeviceSynchronize que 4 cudaStreamSynchronize.

La próxima versión de Nsight tendrá características adicionales para ayudar a entender la cola de SW y la presentación de trabajo al motor de cómputo y al motor de copia de memoria.