Rust SIMD na GPU

Desenvolvedores de Rust estão experimentando trazer as abstrações de portable SIMD do Rust para GPUs, com o objetivo de executar bibliotecas orientadas a CPU existentes de forma eficiente em hardware gráfico sem reescrevê-las em CUDA ou frameworks especializados de ML. Os comentaristas analisam como a IR proposta, baseada em traits e tipos, se relaciona com o modelo de execução da GPU (warps, shuffles, barriers) e quais benefícios e limitações isso traz em comparação com a programação SIMT tradicional e com intrínsecos específicos de arquitetura. A discussão também aborda questões mais amplas, como a maturidade do ecossistema SIMD do Rust, os desafios de um SIMD “verdadeiramente portátil” entre CPUs e GPUs, e como uma startup poderia open-source seu stack de compilador enquanto constrói produtos comerciais em cima dele.

Objetivos e design do projeto

  • O trabalho visa permitir que bibliotecas CPU existentes e não modificadas (incluindo código que usa core::simd) executem em GPUs.
  • Usa uma IR fortemente tipada com traits parametrizados por operações (reductions, scans, shuffles, strip mining).
  • A “shape” de execução é codificada nos tipos; combinações inválidas (por exemplo, executor de warp com barrier de dispositivo) tornam-se erros em tempo de compilação.
  • O design usa constantes em nível de tipo para padrões de shuffle e parâmetros de strip-mining; supostamente isso captura muitos padrões de uso incorreto de GPU em tempo de compilação.
  • A intenção é reutilizar abstrações semelhantes em CPU e GPU, e não “substituir” CPUs.

Compilador, disponibilidade e modelo de negócios

  • A implementação atualmente depende de um fork customizado do compilador; ainda não é pública.
  • O plano declarado: tornar open source partes do compilador e da standard library após o lançamento do produto; o negócio se baseia em produtos construídos em cima disso, não na venda do compilador.
  • Alguns comentaristas expressam frustração por não poderem testar agora nem fazer benchmarks.

Casos de uso vs stacks de ML existentes

  • Ceticismo: se você precisa usar uma DSL de programação de arrays (scan/gather/etc.), por que não usar simplesmente Torch/TF/JAX/MLIR?
  • Resposta: isso acrescenta pouco para workloads de ML escritos à mão; o valor está em bibliotecas gerais de CPU ganharem aceleração em GPU de forma transparente.

Discussão GPU vs CPU e SIMD/SIMT

  • Várias explicações de como os “cores” da GPU se mapeiam para lanes de SIMD, warps/waves, grandes files de registradores e ocultação de latência por meio de muitas threads residentes.
  • Contraste: CPUs otimizam para baixa latência e cache/speculation complexos; GPUs para throughput e alta largura de banda.
  • Debate sobre terminologia: GPUs como SIMD vs SIMT; alguns enfatizam que elas são ISAs vetoriais sob um modelo de programação de “threads”.

Portable SIMD, Rust nightly e ecossistema

  • O portable SIMD do Rust é apenas nightly; alguns usuários mudaram para alternativas (por exemplo, fearless_simd) para builds estáveis.
  • Visões mistas sobre o longo tempo em nightly: alguns veem isso como amadurecimento cauteloso; outros ficam frustrados porque utilitários “básicos” e métodos de slice/pointer permanecem instáveis por anos.
  • Debate sobre portable SIMD:
    • Crítica: a maioria dos exemplos escolhe uma largura fixa de vetor, prejudicando a verdadeira portabilidade e a portabilidade de desempenho.
    • Contraponto: genéricos agnósticos à largura são possíveis; portable SIMD é um meio-termo útil quando a auto-vectorização é insuficiente, mas tuning específico para ISA não é necessário.
    • Reconhecimento de que larguras ideais diferem por arquitetura e, às vezes, por condições de runtime; estratégias de seleção via cfg, multi-variants ou JIT são discutidas.
    • Alguns argumentam que as ISAs SIMD diferem o suficiente para que apenas um subconjunto de casos de uso possa ser verdadeiramente portátil; outros observam que matemática vetorial/matricial “trivial” já cobre a maioria dos usos práticos.

Miscelânea

  • Há curiosidade sobre domínios de aplicação alvo, especialmente além de LLMs; a tese mencionada foi que a maioria dos dispositivos vem com GPUs subutilizadas.
  • Pedido por benchmarks concretos e competitivos (por exemplo, radix sort); nenhum foi fornecido na thread (o impacto de desempenho permanece incerto).
  • Threads meta menores sobre possíveis comentários de bots e sobre o toggle de “pedantic mode” do blog para detalhes técnicos extras.