Python 3.13 Ganha um JIT

Artigo original ↗ Discussão no Hacker News ↗

O Python 3.13 está ganhando um compilador JIT experimental “copy-and-patch” que atualmente traz ganhos modestos de 2–9%, mas é visto como uma base importante para otimizações maiores no futuro. Os comentaristas debatem até onde o CPython pode realisticamente ser levado em comparação com runtimes fortemente baseados em JIT como V8 ou PyPy, dadas as semânticas altamente dinâmicas do Python, a dependência de extensões C e o desejo de preservar a compatibilidade do ecossistema. Muitos ainda veem ganhos incrementais como valiosos — especialmente quando acumulados ao longo de várias versões — enquanto outros questionam se mudanças mais profundas ou implementações alternativas são, em última análise, necessárias para saltos substanciais de desempenho.

Impacto no desempenho e expectativas

  • O novo JIT copy-and-patch no CPython 3.13 mostra um ganho de velocidade de ~2–9% nos benchmarks iniciais.
  • Alguns veem isso como já significativo, especialmente considerando que o CPython é baseado em C e que as mudanças são mínimas; outros acham pouco impressionante em comparação com alternativas como PyPy ou GraalPython, que afirmam melhorias de múltiplos x.
  • O impacto é limitado no início: apenas funções que contêm um salto para trás (isto é, loops como while/for) são compiladas pelo JIT.
  • Vários comentários destacam que isso é trabalho de base; muitos pequenos ganhos ao longo de versões podem se acumular de forma significativa, mesmo que nenhuma release isolada seja dramática.

Design do JIT e trade-offs técnicos

  • O JIT usa uma abordagem “copy-and-patch” / baseada em templates: implementações em C de opcodes são compiladas em fragmentos de código relocáveis, que são costurados em runtime para sequências específicas de bytecode Python.
  • Isso reaproveita a lógica existente do interpretador, reduz nova complexidade e evita distribuir LLVM em runtime (as ferramentas do LLVM são necessárias apenas em tempo de compilação).
  • Ele remove principalmente o overhead de dispatch do interpretador; otimizações mais profundas (por exemplo, fusão de instruções, micro-ops, JITs de múltiplos níveis) são discutidas como possíveis, mas ainda não realizadas.
  • Alguns duvidam até onde um design copy-and-patch pode chegar sem um JIT otimizador “completo” e uma análise de nível IR mais agressiva.

Comparação com outros runtimes e implementações

  • Outros runtimes Python com JIT ou alternativos mencionados: PyPy (média geométrica 4,8x mais rápido em seus benchmarks), GraalPython (4,3x mais rápido em pyperformance), Jython, IronPython e várias ferramentas AOT (Nuitka, mypyc, Shedskin, Numba, Cython).
  • Nenhuma das VMs alternativas conseguiu substituir amplamente o CPython devido à compatibilidade (especialmente extensões C), comportamento de warmup e custo de manutenção.
  • Motores JavaScript (V8, JavaScriptCore, SpiderMonkey) são citados como evidência de que linguagens dinâmicas podem ficar muito mais rápidas, mas eles tinham menos restrições de extensões nativas e um enorme investimento corporativo.

Tipagem dinâmica, type hints e limites de otimização

  • A dinamicidade do Python (funções reassinaláveis, monkey-patching, adição de campos em runtime, inteiros boxed) é repetidamente citada como uma barreira central para desempenho próximo ao de C.
  • Type hints opcionais existem, mas são não-sound e em sua maioria verificados por ferramentas externas (por exemplo, mypy); as anotações atuais não são consideradas confiáveis o bastante para grandes otimizações de JIT.
  • Alguns sugerem que JITs deveriam, em vez disso, depender de profiling em runtime e guards, como nos motores JS modernos.

Ecossistema, empacotamento e restrições de extensões C

  • Um tema importante: a velocidade do Python para muitas cargas de trabalho já vem de extensões em C/C++/Fortran/Rust (NumPy, PyTorch, BLAS, etc.), com o Python atuando principalmente como “cola”.
  • Essa API C é ao mesmo tempo um ponto forte e uma grande restrição: ela expõe internos do CPython, tornando mudanças radicais na VM difíceis e implementações alternativas caras de tornar compatíveis.
  • Frustrações com empacotamento e implantação (virtualenvs, Poetry, Docker, falta de ferramentas fáceis de cross-compilation/arquivo único) são discutidas como pontos de dor sérios, às vezes vistos como mais urgentes do que a velocidade bruta do interpretador.

Papel da linguagem, filosofia e reações da comunidade

  • Muitos argumentam que Python é “rápido o suficiente” para tarefas típicas de IO-bound e integração; quando o desempenho realmente importa, as pessoas recorrem a bibliotecas nativas ou a outras linguagens.
  • Outros se preocupam que Python esteja ficando muito para trás em relação a linguagens como Rust, Go, Java ou até JS em velocidade bruta, e esperam que este JIT seja o início de um trabalho de otimização mais agressivo.
  • Há debate sobre complexidade: o design anterior do CPython favorecia simplicidade em vez de velocidade, mas o uso em larga escala (especialmente em dados e ML) e o novo financiamento corporativo estão empurrando para internos mais sofisticados.