ES
Racer comprueba si las reescrituras de núcleos de GPU conservan su función
Racer: Hunting GPU Kernel Bugs with Symbolic Equivalence Checking · arXiv:2610.28429
En palabras sencillas
Los núcleos de GPU son programas pequeños que hacen cálculos en un procesador gráfico. Cuando los desarrolladores reescriben uno para que sea más rápido, las pruebas habituales comparan las salidas para algunas entradas elegidas.
Por eso pueden pasar por alto casos inusuales, valores ocultos en la memoria o respuestas erróneas que quedan dentro del margen de tolerancia. El artículo presenta Racer, que compara dos núcleos mediante expresiones que representan entradas posibles, en vez de probar solo algunos ejemplos.
En un estudio de 2,408 núcleos de producción, los autores encontraron 82 errores; Racer expuso automáticamente 76, mientras que los seis restantes requirieron inspección manual.
La investigación
Cuando los desarrolladores reescriben núcleos de GPU para que sean más rápidos, ¿cómo pueden comprobar que el nuevo código sigue calculando lo mismo?
Las pruebas con muestras comparan las salidas solo para algunas entradas y pueden pasar por alto casos poco frecuentes, estados ocultos de la memoria, escrituras adicionales o errores lógicos lo bastante pequeños como para quedar dentro de una tolerancia.
Racer compara simbólicamente núcleos de GPU con sus referencias para comprobar si calculan la misma función con todas las entradas posibles.
Para comprobar que una reescritura de un núcleo de GPU conserva su función, los autores presentan Racer, un motor que compara simbólicamente un núcleo con una referencia.
Compara expresiones de salida para entradas posibles y registra las escrituras en memoria, lo que aborda puntos ciegos de las pruebas que usan muestras de entrada y comparan las salidas declaradas dentro de una tolerancia.
En un estudio de 2,408 núcleos de producción, los autores encontraron 82 errores distintos.
Racer expuso automáticamente 76 mediante diagnósticos o refutaciones basadas en las salidas, lo que aporta evidencia de que el método puede encontrar defectos reales en esta colección, incluidos los que las pruebas convencionales pasaron por alto.
El estudio abarca los núcleos recopilados y las configuraciones de lanzamiento probadas. Racer rechazó la ejecución de 499 de los 2,408 núcleos, y una prueba solo se aplica a las salidas y asignaciones de índices comprobadas con esa configuración.
Qué muestran las pruebas
- Por qué las pruebas con muestras pasan por alto errores
Las reescrituras de núcleos de GPU deben conservar la función del código al que reemplazan. Las pruebas diferenciales habituales ejecutan el nuevo núcleo y una referencia de confianza con entradas seleccionadas, y luego comparan las salidas declaradas dentro de una tolerancia numérica.
El estudio de los autores sobre errores en bibliotecas desplegadas identifica por qué esas pruebas pueden pasar por alto defectos: pueden no incluir valores poco frecuentes, dejar sin variar el estado implícito de la memoria, ignorar escrituras fuera de las salidas declaradas o aceptar un resultado incorrecto si queda dentro de la tolerancia.
- Comparar las funciones directamente
Racer comprueba si los núcleos de GPU son equivalentes. Ejecuta simbólicamente un núcleo y su referencia con las mismas entradas simbólicas, convierte sus salidas en expresiones y comprueba si coinciden las celdas correspondientes.
También registra las direcciones de memoria para detectar escrituras fuera de las salidas declaradas. El método pregunta si ambos núcleos calculan la misma función para todas las entradas posibles, en vez de comprobar si sus salidas coinciden en algunas muestras.
- Modelar la ejecución con límites
La comprobación simbólica analiza PTX, el conjunto de instrucciones virtuales de NVIDIA documentado públicamente. Para reducir el trabajo repetido de demostración, Racer reutiliza la demostración de una celda de salida representativa solo después de validar que las expresiones de las demás celdas coinciden al renombrar las entradas.
Coordina los hilos de GPU en torno a puntos de sincronización incluidos en el modelo y registra los accesos a memoria. Si no puede representar fielmente una ejecución, la rechaza; si no logra resolver una demostración, puede emitir el veredicto «Desconocido».
- Encontrar defectos en código de producción
En un estudio de 2,408 núcleos de producción procedentes de 41 fuentes, los autores encontraron 82 errores distintos en 23 bibliotecas. Racer expuso automáticamente 76 mediante diagnósticos o refutaciones basadas en las salidas; los otros seis se identificaron al inspeccionar manualmente los casos no resueltos.
Los resultados muestran que el motor puede exponer defectos reales en esta colección, incluidos errores que las pruebas convencionales pasaron por alto. De los 76 errores previamente desconocidos notificados a los responsables de los proyectos, 41 fueron confirmados.
- Interpretar las comparaciones con cautela
Con el mismo conjunto de 82 errores, los autores evaluaron que un comprobador diferencial con oráculo podría detectar 47 al revisar cada entrada posible de tensor, con una configuración de lanzamiento que activara el error, frente a una referencia independiente y con comparación basada en tolerancias.
Fue una evaluación caso por caso, no una campaña de pruebas. Las ejecuciones registradas detectaron 18 errores con compute-sanitizer y nueve con Volta.
Por otra parte, se rechazó la ejecución de 499 de los 2,408 núcleos, así que los resultados de cobertura no establecen que se hayan comprobado todos los núcleos o configuraciones.
Detalles
- Autores del paper original
- Tuan Truong Vu, Cheng Tan
- Enviado a arXiv
- Licencia
- CC BY 4.0