Experimento com Free-threaded CPython está pronto

• Free-threaded CPython é uma grande mudança que permite executar várias threads em paralelo dentro do mesmo interpretador
• Disponível como recurso experimental no CPython 3.13
• Graças à PEP 703, agora é possível executar com o GIL desativado
• É importante para melhorar o desempenho, especialmente o desempenho em multithread
• Permite usar vários núcleos de CPU de forma eficaz

Legal, mas quais são os problemas?

• Implementar free-threading no próprio CPython exige um grande esforço
• Há dois problemas principais: segurança de threads e compatibilidade de ABI
  • Segurança de threads: código Python puro funciona sem mudanças, mas isso pode não acontecer com código escrito em outras linguagens ou que usa a API C do CPython
  • Compatibilidade de ABI: o interpretador free-threaded tem uma ABI diferente, então cada pacote com módulos de extensão precisa compilar wheels adicionais
• Problemas de segurança de threads são difíceis de entender, melhorar e testar
• Exemplos: falhas intermitentes em numpy#26690, pywavelets#758 etc.

Planos daqui para frente e o trabalho da equipe

• Vai levar alguns anos até que o free-threaded CPython se torne o padrão
• Espera-se que muitos projetos trabalhem na compatibilidade no Python 3.13 e lancem wheels cp313t no PyPI
• A equipe começou há alguns meses a trabalhar a partir da base da stack PyData
• Para cada pacote, é usada uma abordagem semelhante:
  1. Adicionar o primeiro job de CI
  2. Corrigir problemas de segurança de threads e de estado compartilhado/global
  3. Adicionar suporte a free-threaded aos jobs de CI de build de wheels
  4. Fazer testes de estresse localmente e monitorar os jobs de CI
  5. Marcar os módulos de extensão para que possam rodar sem GIL
  6. Passar para o próximo pacote

Resumo do GN⁺

• Free-threaded CPython é uma mudança importante que pode melhorar muito o desempenho em multithread
• Resolver os problemas de segurança de threads e compatibilidade de ABI é o principal desafio
• Espera-se que muitos projetos possam trabalhar na compatibilidade e experimentar isso no Python 3.13
• Pacotes importantes como o PyTorch e muitos pacotes menores precisam adotar essa mudança
• Projetos relacionados incluem PyO3 e PyTorch

[GN⁺]

Comentários no Hacker News

• A remoção do GIL do Python cria uma oportunidade para muitas organizações e projetos melhorarem bastante o desempenho com pouco ou nenhum esforço adicional

  • Se bibliotecas antigas não acompanharem essa mudança a tempo, novos projetos podem ganhar participação de mercado
  • Isso permite evitar a complexidade e os bugs do multiprocessamento e usar threads simples para aproveitar todos os núcleos de máquinas grandes

• Compartilha a experiência de instalar e fazer funcionar o Python sem GIL no macOS

  • Escreveu um script curto explicando o processo de instalação e as diferenças
  • Link

• Um usuário que gosta da facilidade de escrever em Python e da sua lógica espera que a abordagem sem GIL seja parecida com a forma atual de escrever Python

  • Menciona que não se aprofundou em multithreading por ser algo difícil

• Resume o progresso do Python 3

  • [x] Async
  • [x] Tipagem estática opcional
  • [x] Threading
  • [ ] JIT
  • [ ] Gerenciamento eficiente de dependências

• Recorda que por volta de 2007 o processamento paralelo se tornou essencial

  • Menciona que o Rust está à frente em velocidade e processamento paralelo

• Explica, no PEP703, como a operação append de listas continua mantendo segurança entre threads após a remoção do GIL

  • Foi adicionado um bloqueio por lista
  • Observa que uma operação simples de incremento de inteiro atualmente é thread-safe por causa do GIL

• Há expectativa sobre como a remoção do GIL vai mudar a natureza do treinamento e da inferência em ML

  • Pode reduzir a complexidade da passagem de memória e da coordenação entre processos
  • Espera-se que bibliotecas como PyTorch possam ser otimizadas

• Há preocupação de que programadores que nunca lidaram com multithreading de verdade possam introduzir novos bugs sutis

• Levanta a questão de quão grave é a perda de desempenho em thread única

  • Não encontrou benchmarks, e só há garantias genéricas de que está tudo bem

• Expressa curiosidade sobre como isso funcionará com async

  • Existe uma barreira natural entre código bound por I/O e código bound por CPU
  • Gostaria de ver um modelo mais flexível
  • Pergunta se será possível usar JIT ao fazer "gather" em corrotinas bound por CPU
  • Acha que seria incrível um modelo de programação flexível que permitisse alternar rapidamente com uma interface semelhante