Rust SIMD en la GPU

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores de Rust están experimentando con llevar las abstracciones SIMD portátiles de Rust a las GPUs, con la idea de ejecutar bibliotecas existentes orientadas a CPU de forma eficiente en hardware gráfico sin reescribirlas en CUDA o en frameworks de ML especializados. Los comentaristas analizan cómo el IR propuesto, basado en traits y tipos, se mapea a los modelos de ejecución de GPU (warps, shuffles, barreras) y qué beneficios y limitaciones tiene frente a la programación SIMT tradicional y a los intrínsecos específicos de arquitectura. El hilo también aborda cuestiones más amplias como la madurez del ecosistema SIMD de Rust, los desafíos de un SIMD “realmente portátil” entre CPU y GPU, y cómo una startup podría abrir su stack de compilación mientras construye productos comerciales encima.

Objetivos y diseño del proyecto

  • El trabajo busca permitir que bibliotecas de CPU existentes y sin modificar (incluido código que usa core::simd) se ejecuten en GPUs.
  • Utiliza un IR fuertemente tipado con traits parametrizados por operaciones (reducciones, scans, shuffles, strip mining).
  • La “forma” de ejecución se codifica en los tipos; combinaciones inválidas (por ejemplo, un ejecutor de warp con una barrera de dispositivo) se convierten en errores de compilación.
  • El diseño usa constantes a nivel de tipo para patrones de shuffle y parámetros de strip-mining; se supone que detecta muchos patrones de uso incorrecto de GPU en tiempo de compilación.
  • La intención es reutilizar abstracciones similares en CPU y GPU, no “reemplazar” las CPU.

Compilador, disponibilidad y modelo de negocio

  • La implementación actualmente depende de un fork personalizado del compilador; todavía no es pública.
  • El plan declarado: abrir el código del compilador y partes de la biblioteca estándar después del lanzamiento del producto; el negocio se apoya en productos construidos encima, no en la venta del compilador.
  • Algunos comentaristas expresan frustración porque no se puede probar ahora ni hacer benchmarks.

Casos de uso frente a las pilas de ML existentes

  • Escepticismo: si hay que usar un DSL de programación de arreglos (scan/gather/etc.), ¿por qué no usar simplemente Torch/TF/JAX/MLIR?
  • Respuesta: esto aporta poco para cargas de trabajo de ML escritas a mano; el valor está en que bibliotecas generales de CPU obtengan aceleración GPU de forma transparente.

Discusión sobre GPU vs CPU y SIMD/SIMT

  • Varias explicaciones de cómo los “núcleos” de GPU se mapean a lanes SIMD, warps/waves, grandes ficheros de registros y ocultación de latencia mediante muchos hilos residentes.
  • Contraste: las CPU optimizan para baja latencia y caché/especulación complejas; las GPU para rendimiento y alto ancho de banda.
  • Debate sobre la terminología: GPUs como SIMD vs SIMT; algunos enfatizan que son ISAs vectoriales bajo un modelo de programación de “hilos”.

Portable SIMD, Rust nightly y ecosistema

  • El SIMD portátil de Rust es solo para nightly; algunos usuarios cambiaron a alternativas (por ejemplo, fearless_simd) para compilaciones estables.
  • Opiniones divididas sobre el tiempo prolongado en nightly: algunos lo ven como una maduración prudente; otros se frustran de que utilidades “básicas” y métodos de slices/punteros sigan inestables durante años.
  • Debate sobre portable SIMD:
    • Crítica: la mayoría de los ejemplos eligen un ancho de vector fijo, lo que perjudica la verdadera portabilidad y la portabilidad del rendimiento.
    • Contraargumento: es posible usar genéricos agnósticos al ancho; portable SIMD es un punto medio útil cuando la auto-vectorización no basta pero no hace falta afinado específico de ISA.
    • Se reconoce que los anchos óptimos difieren por arquitectura y a veces por condiciones de ejecución; se discuten estrategias de selección mediante cfg, multi-variantes o JIT.
    • Algunos sostienen que las ISAs SIMD difieren lo suficiente como para que solo un subconjunto de casos de uso pueda ser verdaderamente portátil; otros señalan que las matemáticas vectoriales/de matrices “triviales” ya cubren la mayoría de las necesidades prácticas.

Miscelánea

  • Hay curiosidad sobre los dominios de aplicación objetivo, especialmente más allá de los LLMs; la tesis mencionada era que la mayoría de los dispositivos se envían con GPUs infrautilizadas.
  • Se pide un benchmark concreto y competitivo (por ejemplo, radix sort); no se proporciona ninguno en el hilo (el impacto en rendimiento sigue sin estar claro).
  • Hilos menores de meta sobre posibles comentarios de bots y sobre el interruptor de “pedantic mode” del blog para obtener más detalle técnico.