Anúncio do Steering Council sobre o projeto JIT

• O compilador JIT experimental do CPython vem sendo desenvolvido há anos no branch main e recentemente apresentou ganhos reais de desempenho, mas ainda precisa de uma revisão formal por PEP para permanecer como um recurso suportado
• A PEP 744 tratou do design inicial e dos critérios para virar um recurso permanente, mas ainda não há consenso sobre mantenedores de longo prazo, revisão de segurança, suporte a depuração e ferramentas externas de processo, garantias de runtime e obrigações para redistribuidores e empacotadores downstream
• O Python Steering Council solicitou oficialmente a redação de uma Standards Track PEP para tornar o JIT um recurso não experimental suportado do CPython, e pediu a suspensão da incorporação no main de novos recursos, otimizações e trabalhos de desempenho até a aceitação da PEP
• A nova PEP deve tratar de manutenção de longo prazo, compatibilidade com recursos e ferramentas existentes do CPython, métricas de sucesso mensuráveis e cronograma, relação com JITs de terceiros como CinderX·Numba·PyTorch e estabilidade da arquitetura atual
• Se a PEP não for enviada, resolvida ou aceita em até 6 meses, o código do JIT será removido do branch main e o desenvolvimento deverá continuar fora do repositório principal do Python

---

Contexto e pedido oficial

• O compilador Just-In-Time experimental do CPython é um trabalho que vem sendo desenvolvido no branch main ao longo dos últimos anos por vários core developers e contribuidores, e as melhorias recentes de desempenho são resultados reais e animadores
• Essa medida não é uma crítica ao trabalho do JIT nem às pessoas envolvidas; como o projeto já se estende há muito tempo e passou por vários redesenhos, entendeu-se que chegou a hora de reavaliar o status informal do JIT dentro do projeto CPython
• O JIT entrou no main inicialmente como experimento, e a PEP relacionada, a PEP 744, é uma Informational PEP
• A PEP 744 tratou do design inicial e esboçou critérios para que o JIT pudesse se tornar um recurso permanente, mas deixou em aberto questões como mantenedores de longo prazo, revisão de segurança, suporte a depuração e ferramentas externas de processo, garantias de runtime e obrigações de redistribuidores e empacotadores downstream
• O Python Steering Council entendeu que uma mudança com esse nível de complexidade e escopo exigia um processo mais rigoroso, e que essas questões em aberto são compromissos que a comunidade precisa examinar e acordar por meio do processo de PEP
• Para tornar o JIT um recurso não experimental suportado do CPython, é necessária uma Standards Track PEP que trate de garantias, compromissos de manutenção e impacto sobre redistribuidores, além de um processo formal de aceitação ou rejeição pelo Steering Council após discussão com a comunidade
• Até que essa PEP seja aceita, novos desenvolvimentos de JIT não devem ser incorporados ao branch main; novos recursos, otimizações e trabalhos de desempenho entram na suspensão
• Correções de bugs e de segurança podem continuar; o escopo da suspensão está limitado à incorporação de funcionalidades adicionais do JIT antes da aceitação da PEP

Questões que a PEP deve tratar e prazo de 6 meses

• A intenção não é exigir propostas concorrentes, mas este também é um bom momento para discutir alternativas, o que está alinhado com a visão já existente de que não se deve fazer experimentos no branch main do CPython sem uma PEP
• Em vez de propor uma única implementação de JIT, pode ser mais apropriado uma PEP que descreva uma infraestrutura de JIT capaz de suportar várias estratégias de implementação
• Como várias abordagens promissoras de tracing JIT continuam sendo propostas, a infraestrutura deve permitir que essas abordagens sejam facilmente experimentadas e avaliadas dentro do CPython, em vez de ficar fortemente acoplada a uma única estratégia
• A PEP deve estabelecer um plano claro de como sustentar e manter no longo prazo um subsistema desse porte e complexidade, e qual será o impacto sobre mantenedores e contribuidores que não trabalham diretamente no JIT
• A PEP deve tratar da compatibilidade com recursos e ferramentas existentes do CPython, abordando de forma ampla e detalhada a interação e as garantias entre o JIT e recursos como free-threading, profiler e debugger
• A PEP deve incluir métricas de sucesso claras e mensuráveis e um cronograma, tratando de metas e prazos para objetivos como desempenho, escopo de suporte a plataformas e sobrecarga de memória
• A PEP deve tratar da relação com outros compiladores JIT, deixando claro se o design oferece uma infraestrutura geral sobre a qual outros esforços possam se apoiar e se prevê compatibilidade ou incompatibilidade com JITs de terceiros como CinderX, Numba e PyTorch
• A PEP deve tratar se a arquitetura atual do JIT é considerada estável ou se ainda há grande probabilidade de mudanças
• Esta lista não é exaustiva, e outras questões podem ser acrescentadas conforme a discussão da comunidade avançar
• Foi definido um prazo de 6 meses para envio e resolução da PEP; se ela não for aceita dentro desse período, o código do JIT será removido do branch main e o desenvolvimento deverá continuar fora do repositório principal do Python
• Essa exigência não representa o fim do projeto, mas sim um procedimento para dar a clareza necessária e o compromisso explícito da comunidade para uma grande mudança no runtime do CPython

[GN⁺]

Comentários no Lobste.rs

• Não parece muito hostil, mas é um pouco estranho. Se o JIT ainda é um recurso experimental, não parece haver problema em continuar fazendo merge
  Se pessoas como Shannon dizem “vamos trazer uma PEP, mas por favor evitem conflitos estranhos”, parece que dá para confiar nelas o suficiente para não precisar impor um bloqueio rígido que impeça qualquer avanço. Talvez este anúncio público tenha vindo depois de conversas privadas, mas espero que isso siga bem sem feridas desnecessárias

• A proposta de uma interface que permita implementações diferentes de JIT parece mostrar um grande mal-entendido sobre o que é necessário para um JIT de alto desempenho. Os desenvolvedores do JIT devem ter enfrentado vários problemas, mas um dos maiores parece ter sido não poder, ou não querer, mudar de forma significativa as estruturas centrais de dados do runtime
  Claro, o Python também tem o problema de expor praticamente toda a implementação como se fosse uma API. Ainda assim, se alguém faz algo ruim, você pode obrigá-lo a reescrever os tipos, mas para isso é preciso uma comunidade que realmente valorize desempenho. Historicamente, o Python sobreviveu deixando as bibliotecas que precisam de desempenho sem serem escritas em Python, e isso afetou as prioridades. Lembro de comparações antigas de desempenho entre linguagens que colocavam lado a lado implementações básicas de algoritmos e implementações em Python que, na prática, apenas envolviam versões em C bem lapidadas e de alto desempenho

  • A proposta de interface para JIT parece inspirada no Ruby, e dá a impressão de que funcionou bastante bem lá. Então talvez o Ruby não tenha um JIT ultrarrápido, mas isso pode ser bom o suficiente. Acho que muita gente já ficaria satisfeita se o JIT de Python funcionasse tão bem quanto o de Ruby

  • Não entendo muito bem por que se diz que “a proposta de uma interface que permita implementações diferentes de JIT mostra um grande mal-entendido sobre o que é necessário para um JIT de alto desempenho”
    Como você disse, existe essa situação em que o Python expõe a implementação como API, mas pelo mesmo motivo o JIT também está chamando essas APIs. Na prática, algumas funções chegaram a ser expostas ao linker como símbolos públicos porque o JIT precisava delas. Pessoalmente, estou trabalhando em um JIT de métodos, e não em um JIT de tracing, e tenho apoiado publicamente a ideia de um JIT plugável

• Fico me perguntando por que isso foi publicado como um anúncio público em vez de ser enviado como uma solicitação privada aos desenvolvedores centrais do JIT

  • Porque o Python é um projeto de código aberto guiado pela comunidade. Mesmo em projetos proprietários, anúncios parecidos já vazaram

• Parece que algum antropólogo deveria escrever um livro sobre a burocracia em projetos de software de código aberto, e Python e Debian deveriam ser objetos centrais de estudo
  Não é uma crítica. Esse tipo de burocracia é, no fim, um processo de tomada de decisão distribuída e de formação de consenso, e é difícil fazer isso funcionar bem nessa escala

  • Gabriella Coleman é uma antropóloga que fez trabalho de campo no Debian. O livro que saiu disso é “Coding Freedom”, e recomendo muito

• Sinceramente, isso parece a mesma síndrome que levou ao Python 3, mas com o efeito oposto. O CPython existe principalmente para a diversão de quem o implementa, e essa mudança parece que vai trazer um incômodo considerável para as pessoas acostumadas a fazer hacking do jeito atual
  Provavelmente a direção correta seria apoiar a versão com JIT como uma implementação separada, permitir mudanças nela e buscar compatibilidade com o CPython original em regime de melhor esforço

  • Não entendo exatamente o que significa “a mesma síndrome que levou ao Python 3, mas com o efeito oposto”
    Quanto à parte de que “o CPython existe principalmente para a diversão de quem o implementa”, minha impressão, a partir de interações limitadas com o SC e com os desenvolvedores centrais, foi na verdade o contrário. Em geral, eles pareciam bastante comprometidos em encontrar um equilíbrio razoável entre continuar dando suporte à comunidade existente e, ao mesmo tempo, seguir em frente