NVIDIA finalmente adiciona suporte nativo a Python ao CUDA

• Depois de anos centrado em C/C++, o toolkit CUDA da NVIDIA passou a oferecer oficialmente suporte nativo a Python na GTC 2024
• Agora é possível executar operações de alta velocidade focadas em algoritmos diretamente na GPU usando apenas Python
• O arquiteto de CUDA Stephen Jones explicou que “Python CUDA não é simplesmente código C reescrito com sintaxe Python,
  mas algo redesenhado do zero de uma forma natural para desenvolvedores Python”

Novas possibilidades abertas pelo suporte nativo a Python

• Antes, usuários de CUDA precisavam conhecer C++ ou Fortran, mas agora já é possível fazer computação de alto desempenho em GPU usando apenas Python
• Segundo a pesquisa de código aberto do GitHub de 2024, Python ultrapassou JavaScript e se tornou a linguagem mais popular
• O número de usuários de CUDA cresceu de 2 milhões em 2020 para 4 milhões em 2023,
  enquanto os desenvolvedores Python somam dezenas de milhões, o que é especialmente positivo para desenvolvedores de países emergentes como Índia e Brasil
• Com isso, também se espera um impacto positivo na expansão da infraestrutura global de GPU

Como o CUDA Pythonic é estruturado

• O CUDA é composto por bibliotecas, SDK, compilador, runtime, ferramentas e algoritmos
• A integração com Python não consiste apenas em oferecer kernels, mas em estruturar toda a stack de forma amigável para Python
• Abordagem principal: baseada em compilação JIT (Just-In-Time), minimizando a dependência de compiladores

Principais componentes

• cuPyNumeric: biblioteca Python que oferece a mesma API do NumPy com aceleração por GPU
• CUDA Core: sistema baseado em fluxo de execução que redesenha o runtime do CUDA em estilo Python
• NVMath Python: fornece uma interface unificada para chamar bibliotecas de host/device
• API Python estruturada para integração direta com bibliotecas C++ de alto desempenho
• Ferramentas de profiling e análise de código também são oferecidas

> “Como há conexão direta com o código C++ de alto desempenho existente, a perda de desempenho é quase inexistente” — Stephen Jones

Novo modelo de programação: CuTile

• Modelo de alto nível centrado em arrays projetado para desenvolvedores Python
• Enquanto o CUDA tradicional exigia controle detalhado baseado em threads, o CuTile oferece uma estrutura mais concisa e fácil de entender por meio de abstração em nível de tiles
• O CuTile mapeia arrays em unidades de tiles da GPU, o que facilita depuração e otimização mantendo o desempenho
• No futuro, também deverá ser expandido para o CUDA em C++

> “Como o compilador entende melhor a estrutura da GPU, a otimização de desempenho também é feita automaticamente com mais eficiência”

Resumo

• A integração nativa de Python ao CUDA representa uma mudança que reduz drasticamente a barreira de entrada para programação em GPU
• Mesmo sem conhecimento de linguagens mais complexas, agora é possível fazer computação de IA e científica em GPU usando apenas Python
• Trata-se de um ponto de virada decisivo que abre uma nova era para a expansão do ecossistema de IA centrado em Python e para o uso de GPUs da NVIDIA

[aer0700]

Será que vai ser mais rápido do que wrappers de CUDA já existentes, como CuPy e PyTorch? A vantagem do CuPy e do torch é que a API é quase igual à do NumPy, então dava para migrar o código de teste escrito em NumPy sem muito esforço; quanto a este, acho que vou ter que usar para ver como é.

[GN⁺]

Comentários do Hacker News

• Não sou programador de GPU, mas parece algo que até gente como eu conseguiria usar com facilidade. Fiz uma demo simples usando GPU e CPU. Os resultados foram os seguintes

  • Gerar 100 matrizes aleatórias de tamanho 5000x5000 na CPU
  • Somar matrizes na CPU
  • Tempo para concluir a soma de matrizes na CPU: 0,6541 s
  • Tamanho da matriz resultado na CPU: (5000, 5000)
  • Gerar 100 matrizes aleatórias de tamanho 5000x5000 na GPU
  • Somar matrizes na GPU
  • Tempo para concluir a soma de matrizes na GPU: 0,1480 s
  • Tamanho da matriz resultado na GPU: (5000, 5000)
  • A API é realmente simples, então vale a pena explorar mais a fundo. Programar em CUDA parece um grande esforço sem algo de alto nível assim

• Fico me perguntando por que Python vira alvo dessas coisas. Já vi muitos projetos adicionando suporte a Python. Será que codebases em Python podem ser compiladas para vários alvos com mais facilidade do que outras?

• Ainda bem que Pytorch ganhou grande tração antes disso surgir. Agora temos um verdadeiro quase-padrão independente de plataforma para computação paralela. Não fica limitado à NVIDIA

  • A parte do Pytorch relacionada ao backend da NVIDIA agora pode ser implementada diretamente em Python
  • O importante é que isso não importa, ou não deveria importar, para o usuário final/desenvolvedor
  • Talvez essa nova plataforma possa expandir todo o conceito de computação em GPU para mais domínios, como jogos, via Python
  • Imagine rodar jogos em Rust principalmente na GPU por meio de Python

• CuTile parece, em muitos aspectos, um sucessor do Triton da OpenAI. Além de primitivas no nível de tile/bloco e do TileIR, também estamos ganhando um modelo de programação SIMT adequado no CuPy. Parece que muita gente nem percebeu isso na GTC deste ano. É algo muito legal

  • Apesar disso, quase não houve anúncios ou palestras relacionados a CPU. A Grace CPU foi anunciada há um bom tempo, mas não parece que veremos tão cedo uma abstração generalizada que funcione bem entre CPUs e GPUs da Nvidia
  • Para quem trabalha com algoritmos paralelos todos os dias, isso é um problema. Depurar com NSight e CUDA-GDB ainda não é como usar GDB puro, e é muito mais fácil primeiro projetar o algoritmo na CPU e depois portar para a GPU
  • De todas as equipes na área de compiladores, a Modular é uma das poucas que não foi completamente engolida pela febre dos LLMs e continua construindo ativamente abstrações e linguagens que abrangem várias plataformas. Isso se torna cada vez mais valioso neste ambiente. Espero que mais gente experimente Mojo. Talvez isso finalmente consiga preencher a lacuna entre CPU e GPU que enfrentamos todos os dias

• Estou muito curioso para saber como isso se compara ao JAX

  • O JAX permite escrever código Python que roda em GPUs de outras marcas, não apenas da Nvidia (com níveis variados de suporte). Da mesma forma, ele tem substitutos drop-in para funções do NumPy
  • Isto só dá suporte à Nvidia. Mas será que faz coisas que o JAX não consegue? É mais fácil de usar? Menos orientado a arrays de tamanho fixo? Vale a pena se prender a uma marca de GPU?

• Isso é enorme. Quem estava considerando AMD + ROCm como alternativa à NVIDIA na área de IA provavelmente não vai mais considerar

  • Sou uma dessas pessoas que não conseguiu aprender C++ a ponto de escrever código de forma eficaz para execução em GPU (e nem vai aprender). Mas ter um pipeline direto para a GPU via Python? Impressionante
  • As implicações para eficiência são enormes. Não apenas para bibliotecas Python como PyTorch, mas para qualquer coisa que rode em GPUs da NVIDIA
  • Gosto de ver melhorias de eficiência. Ouvimos o tempo todo sobre quantas usinas nucleares OpenAI e Google vão precisar para alimentar todas as GPUs

• Suporte a Rust é o próximo passo? Hoje eu serializo e desserializo manualmente minhas estruturas de dados como arrays de bytes para os kernels e a partir deles. Seria bom ter estruturas de dados realmente compartilhadas, como o CUDA oferece em C++

• Python está realmente se consolidando como a lingua franca das linguagens de programação. Sua adoção está disparando no renascimento do FOSS, e acho que é a ferramenta de uso geral mais próxima que temos

  • O modelo PEP é um bom mecanismo para autoaperfeiçoamento e padronização. Graças a projetos como uv e BeeWare, empacotamento e distribuição em breve serão problemas resolvidos. Tenho certeza de que as melhorias de desempenho continuarão ano após ano

• Isso provavelmente vai levar ainda mais na direção daquilo que Python em geral já tem impulsionado: experimentar mais coisas mais rapidamente e deixar o que importa em linguagens mais rápidas. No geral, isso é um excelente movimento. Com certeza estou ansioso para brincar com isso

• CUDA nasceu em C e C++. Eu gostaria que, em vez de estender C++ e chamar isso de CUDA C, eles de fato tivessem implementado uma variante em C do CUDA

[iwi19]

A velocidade do primeiro é mesmo real? Está muito lento...