Mejora el rendimiento de kernels CUDA con spilling a la memoria compartida (CUDA 13.0)

TL;DR

• CUDA 13.0 añade una optimización que hace spilling de registros a la memoria compartida en primer lugar, usando memoria local solo si la compartida no es suficiente.
• Cuando hay espacio, la memoria compartida on‑chip reduce la latencia y la presión en la caché L2 frente a spills hacia la memoria local.
• Antes de CUDA 13.0, todos los spilling iban a la memoria local; esto podía provocar evicción de caché y pérdidas de rendimiento en regiones con alta presión de registros.
• Active esta función con un pragma PTX dentro de una función: enable_smem_spilling. El pragma es válido solo dentro del alcance de la función.
• Resultados del mundo real, como en QUDA (lattice QCD), muestran ganancias típicas de ~5–10% en kernels con alta presión de registros.

Contexto y antecedentes

Un kernel CUDA puede requerir más registros de los que están disponibles en un SM. Si esto ocurre, el compilador vierte los registros excedentes hacia la memoria local, que está físicamente en la memoria global fuera del chip. Spillings elevan el tráfico de memoria y la latencia, ya que los datos spillados deben leerse y escribirse desde la memoria local. Antes de CUDA 13.0, todos los spills iban a la memoria local. Aun con caches L1 más grandes, los datos spillados podían faltar y escribirse en la caché L2, lo que podía desplazar líneas de caché útiles y degradar el rendimiento en bucles y rutas de código muy usadas por la presión de registros. En muchos workloads, gran parte de la memoria compartida por bloque quedaba sin utilizar en tiempo de ejecución, especialmente cuando los límites de lanzamiento o la ocupación imponían restricciones o cuando el kernel no aprovechaba al máximo la memoria compartida. El blog de CUDA discute cómo el spilling interactúa con la ocupación y por qué la estimación de los límites de lanzamiento puede influir en el rendimiento del kernel. El ejemplo utiliza un kernel diseñado para forzar la presión de registros y así ilustrar el coste de los spills y la ineficiencia de no usar memoria compartida cuando es posible. La conclusión clave es que mantener spills dentro del chip, cuando es posible, acerca los datos spillados al SM y reduce el tráfico fuera del chip.

Qué hay de nuevo

CUDA 13.0 introduce una optimización PTXAS que permite spilling de registros hacia la memoria compartida on‑chip para kernels CUDA. Cuando se activa, el compilador prioriza spills hacia la memoria compartida disponible. Si no hay suficiente espacio, los spills restantes vuelven a la memoria local, manteniendo la corrección. Este cambio ofrece una ventaja de rendimiento clara al aprovechar la memoria on‑chip de menor latencia para los datos spillados cuando es posible. En comparación con herramientas anteriores, donde los spills residían en la memoria global y podían afectar significativamente el rendimiento, el camino de spilling hacia la memoria compartida reduce la latencia y alivia la presión en la caché L2 en muchos escenarios. La optimización se demostró en kernels derivados de la biblioteca QUDA (utilizada para cálculos de lattice QCD en GPUs). En ese trabajo, activar el spilling hacia la memoria compartida típicamente proporcionó ganancias de rendimiento en el rango del 5–10%, impulsadas por la reducción o eliminación de spills locales. Para activar, los desarrolladores que apunten a CUDA 13.0+ deben insertar un pragma PTX dentro de la función, justo después de la declaración de la función:

// dentro del cuerpo de la función, después de su declaración
.pragma_enable_smem_spilling

En la forma de ensamblador en línea, la directiva se expresa como:

#pragma enable_smem_spilling

La característica es válida únicamente dentro del alcance de una función. No debe usarse si no se especifican límites de lanzamiento; si se desconoce, PTXAS puede suponer el número máximo de hilos por bloque, lo que puede provocar presupuestos de memoria compartida inexactos y reducir la ocupación. Para un comportamiento más predecible y mejor rendimiento, use esta característica solo cuando los límites de lanzamiento estén definidos explícitamente. La característica está disponible desde CUDA 13.0 y no estaba presente en versiones anteriores. Cuando los spills se redirigen a la memoria compartida, el uso de memoria por bloque puede reflejarse, como se ve en el ejemplo que muestra 46080 bytes de memoria compartida asignados.

Por qué es importante (impacto para desarrolladores/empresas)

Para desarrolladores que trabajan en kernels GPU de alto rendimiento, especialmente aquellos con alta presión de registros, esta optimización ofrece una vía práctica para mejorar el rendimiento sin cambiar el algoritmo. Dirigir spills hacia la memoria compartida on‑chip puede reducir la latencia de acceso a datos spillados y disminuir la presión sobre la caché L2, con beneficios reales en bucles apretados y rutas críticas. Sin embargo, los beneficios no son universales. La ganancia depende de contar con límites de lanzamiento bien definidos y de un uso constante de la memoria compartida para aprovechar realmente el camino de spilling hacia la memoria compartida. Si la memoria compartida se dimensiona incorrectamente, la ocupación puede verse afectada y los beneficios podrían verse compensados. Para empresas que ejecutan grandes implementaciones CUDA, la opción ofrece un control adicional para optimizar el rendimiento, especialmente en bibliotecas y aplicaciones donde la presión de registros es alta. Las ganancias observadas en QUDA (5–10%) señalan una mejora tangible en este tipo de workloads, y ganancias similares podrían verse en otros escenarios con características semejantes.

Detalles técnicos o Implementación (cómo funciona)

• La idea central es priorizar spilling hacia la memoria compartida on‑chip por defecto, siempre que haya espacio suficiente por bloque.
• Si el espacio compartido es insuficiente, el spilling cae a la memoria local, manteniendo la corrección del programa.
• La optimización se presentó como una característica PTXAS en CUDA 13.0; activar requiere una instrucción explícita de opt‑in en el scope de la función mediante el pragma PTX enable_smem_spilling.
• Las restricciones incluyen especificar límites de lanzamiento para estimar la memoria; de lo contrario, el compilador puede asumir el mayor número de hilos por bloque, lo que puede afectar la ocupación si los lanzamientos reales son menores.
• El impacto en el rendimiento depende del workload. Las evaluaciones de QUDA reportan ganancias típicas entre 5–10%.
• El mecanismo mantiene la corrección del programa mientras acerca los datos spillados al SM cuando es posible.

Tabla: destinos de spills e implicaciones

| Aspecto | Antes de CUDA 13.0 | Spill a memoria compartida (CUDA 13.0) |---|---|---| | Destino del spill | Memoria local (off‑chip) | Memoria compartida (on‑chip) cuando hay espacio; fallback a memoria local si no hay |Latencia | Mayor debido al acceso off‑chip | Menor cuando los spills permanecen en la memoria compartida |Presión L2/cache | Potencial evicción de líneas útiles | Reducida cuando los spills residen en memoria compartida |Ocupación | No está directamente ligada a spills | Requiere límites de lanzamiento explícitos para evitar pérdidas de ocupación |

Ejemplo de referencia del artículo

El artículo señala un kernel con 46080 bytes de memoria compartida utilizada, ilustrando el uso de spills hacia la memoria compartida en un contexto práctico. Este ejemplo demuestra cómo la optimización se refleja en el footprint de memoria por bloque cuando está activada.

Conclusiones clave

• Spill hacia memoria compartida es una opción de activar en CUDA 13.0 mediante un pragma de función.
• Los spills se dirigen primero a la memoria compartida on‑chip, con fallback a la memoria local si no hay espacio suficiente.
• Las ganancias reales varían por workload; las evaluaciones QUDA señalan típicamente 5–10% de mejora.
• Para evitar pérdidas de ocupación, defina límites de lanzamiento explícitos al usar esta opción.
• Esta optimización mantiene la corrección y añade la posibilidad de mejorar el rendimiento en kernels sometidos a alta presión de registros.

Referencias

• https://developer.nvidia.com/blog/how-to-improve-cuda-kernel-performance-with-shared-memory-register-spilling/