What Irregularity Costs: CUDA C++, Rust, and Triton on a Hash-Blocked GPU Workload

O Palco e os Jogadores

Imagine que você está tentando construir um modelo 3D de uma sala usando uma câmera que tira milhares de fotos. Para que isso aconteça, seu computador precisa organizar uma quantidade massiva de dados sobre cada minúsculo pedaço de espaço naquela sala. Este é o mundo da programação de GPU, onde as "GPUs" são os chips gráficos super-rápidos dentro dos computadores que também são brilhantes em realizar milhões de cálculos matemáticos de uma só vez.

Normalmente, quando as pessoas comparam diferentes linguagens de programação para esses chips, elas as testam em tarefas muito limpas e previsíveis, como multiplicar grades gigantes de números. É como testar um carro de corrida em uma rodovia perfeitamente reta e vazia. Cada faixa é igual, e cada motorista sabe exatamente quanto tempo a corrida levará. Mas o mundo real é bagunçado. Em aplicações como realidade virtual ou navegação de robôs, o computador tem que lidar com dados caóticos e imprevisíveis. É como enviar esse mesmo carro de corrida para uma rua movimentada e sinuosa de uma cidade, onde congestionamentos acontecem aleatoriamente e os motoristas têm que parar e arrancar constantemente. Este artigo faz uma pergunta simples, mas crucial: Quando a estrada fica bagunçada, todas as linguagens de programação performam da mesma forma, ou algumas ficam presas no trânsito enquanto outras passam voando?

O Grande Duelo das Linguagens de GPU

Neste estudo, pesquisadores pegaram três formas populares de falar com esses super-chips — CUDA C++ (o padrão clássico, escrito à mão), Rust (uma linguagem moderna conhecida por sua segurança) e Triton (uma ferramenta mais nova projetada para facilitar a codificação) — e as colocaram para trabalhar em um trabalho muito específico e caótico: construir um mapa 3D de uma sala usando uma "tabela de dispersão" (hash table).

Pense em uma tabela de dispersão como um vestiário gigante e caótico. Você tem milhares de pessoas (pontos de dados) tentando encontrar um armário (um lugar na memória) para guardar suas coisas. Às vezes, o armário que elas querem está vazio, então elas o ocupam. Mas, frequentemente, o armário já está ocupado, então elas têm que verificar o próximo, e o próximo, até encontrarem um espaço aberto. Em um mundo perfeito, todos encontram um armário instantaneamente. Neste trabalho "irregular", algumas pessoas encontram armários imediatamente, enquanto outras precisam procurar por muito tempo, e todos estão brigando pelos mesmos poucos armários ao mesmo tempo.

Os pesquisadores executaram exatamente o mesmo trabalho em todas as três linguagens e mediram o quão rápido elas terminaram. Os resultados foram um choque: as linguagens se comportaram de forma completamente diferente dependendo do tipo de trabalho.

A Parte "Regular": Um Empate Técnico

Primeiro, eles testaram a parte "regular" do trabalho, que é como caminhar por um corredor e pintar cada parede que você vê. Esta parte é previsível. Nesta tarefa, as três linguagens foram quase idênticas. Quer você usasse o veterano CUDA, o moderno Rust ou o fácil de usar Triton, eles terminaram em aproximadamente o mesmo tempo. Se você olhasse apenas para esses testes limpos e previsíveis (que é o que a maioria dos outros estudos faz), pensaria que não importa qual linguagem você escolha.

A Parte "Irregular": A Grande Divisão

Depois, eles testaram a parte "irregular": a busca caótica no vestiário. É aqui que a história muda dramaticamente.

• Rust vs. CUDA C++: A linguagem Rust performou quase tão bem quanto o hand-written CUDA C++. Foi apenas um pouquinho mais lenta (cerca de 1% a 3% em alguns casos), o que é praticamente um empate. O Rust provou que consegue lidar com o tráfego bagunçado e imprevisível tão bem quanto o veterano.
• A Luta do Triton: O Triton, no entanto, bateu de frente com um muro enorme. Na tarefa de busca caótica, ele foi mais de 10 vezes mais lento que as outras duas linguagens. Em alguns testes do mundo real com escaneamentos de salas reais, ele foi quase 30 vezes mais lento.

Por Que o Triton Ficou Preso?

Os pesquisadores não disseram apenas "o Triton é lento"; eles descobriram exatamente por que ele estava preso, e não foi porque o código foi mal escrito. Foi devido à forma como a linguagem é construída.

Imagine que o Triton é um professor rigoroso que insiste que cada aluno em uma classe deve permanecer em seu assento por um tempo fixo, mesmo que terminem seu trabalho cedo. No vestiário caótico, algumas threads (alunos) encontram um armário em um segundo, enquanto outras levam dez segundos.

• O Problema: O Triton força as threads rápidas a esperar em um loop até que a thread mais lenta termine, mesmo que elas não tenham mais nada para fazer. É como uma corrida onde o vencedor tem que ficar parado e esperar a última pessoa cruzar a linha de chegada antes que qualquer um possa deixar a pista.
• A Questão da "Máscara": Além disso, o Triton carece de uma ferramenta específica (chamada de "máscara") que permite que as threads rápidas parem de trabalhar inteiramente. Em vez disso, elas têm que continuar executando uma tarefa fictícia, desperdiçando energia e congestionando o sistema. Os pesquisadores descobriram que essa escolha de design forçou o computador a fazer uma quantidade massiva de trabalho inútil, atrasando tudo em um fator de 10 a 30.
• Um Perigo Oculto: Houve também um problema de segurança. Como o Triton impõe um limite de tempo fixo para a busca, se o vestiário ficar muito lotado, a busca pode desistir e parar de procurar. Isso significa que o computador joga fora silenciosamente partes do modelo 3D, criando buracos invisíveis no modelo final. Os pesquisadores descobriram que, em certos níveis de aglomeração, o Triton perderia partes inteiras da superfície, enquanto as outras linguagens as encontrariam perfeitamente.

Por Que o Rust Foi um Pouco Mais Lento (A Armadilha Invisível)

O Rust estava muito perto de vencer, mas não foi tão rápido quanto o código CUDA escrito à mão. Os pesquisadores passaram muito tempo tentando descobrir o porquê, verificando o número de instruções e a memória utilizada. Eles descobriram que o Rust estava, na verdade, fazendo menos trabalho do que o CUDA, mas ainda assim era mais lento.

O culpado foi uma armadilha oculta na forma como o Rust lida com a segurança. O Rust possui um recurso que torna a leitura de dados compartilhados "segura", garantindo que todos vejam a mesma versão. No entanto, nesses chips específicos, a maneira "segura" de ler dados força o computador a pular seu cache de memória mais rápido e ir para um mais lento. É como um segurança que insiste em verificar cada pacote na porta da frente, mesmo que os pacotes já sejam conhecidos como seguros. Esse passo extra atrasou o Rust em cerca de 20-30%, mas foi um preço pequeno a pagar comparado ao enorme atraso do Triton.

A Conclusão

A principal lição deste artigo é que você não pode julgar uma linguagem de programação apenas pelo seu desempenho em tarefas limpas e previsíveis.

Se você testar apenas na "rodovia regular", Rust, CUDA e Triton parecem todos campeões. Mas, assim que você os joga no "trânsito urbano irregular" do mapeamento 3D do mundo real, os resultados se dividem drasticamente.

• Rust é um forte concorrente, mantendo-se quase tão rápido quanto o melhor código escrito à mão.
• Triton, embora ótimo para tarefas organizadas, luta intensamente com trabalhos caóticos e imprevisíveis, tornando-se dezenas de vezes mais lento e potencialmente perdendo dados sem que ninguém perceba.

Os pesquisadores concluem que, para tarefas envolvendo dados bagunçados do mundo real, escolher a linguagem errada não é apenas um pequeno inconveniente; pode tornar seu programa inutilizavelmente lento ou fazer com que ele falhe silenciosamente. Eles também descobriram que muitos estudos anteriores perderam isso porque testaram apenas as partes "regulares", deixando as partes perigosas e bagunçadas sem exploração.