Python 3.14 foi lançado. Quanto ele ficou mais rápido?

 (blog.miguelgrinberg.com)
3 pontos por GN⁺ 2025-10-10 | 1 comentários | Compartilhar no WhatsApp
  • O Python 3.14 lançado agora apresenta o melhor desempenho entre todas as versões do CPython até hoje
  • Em thread única, o 3.14 mostrou cerca de 27% de melhora em relação ao 3.13; o ganho de desempenho do JIT é pequeno, e o interpretador Free-threading é ligeiramente mais lento em thread única
  • Em multithread, o interpretador FT mostrou aceleração de 3,1x no Fibonacci e 2x no bubble sort graças à remoção do GIL, sendo eficaz para multithread com carga intensiva de CPU
  • Em resumo, o 3.14 é o CPython mais rápido até agora, recomenda-se usar 3.11 ou superior, o Pypy continua muito rápido e o JIT ainda precisa amadurecer

Premissas e limitações do benchmark

  • Logo após o lançamento oficial do Python 3.14, foram compartilhados resultados de benchmarks de desempenho entre várias versões do Python e outras linguagens
  • Este teste foi feito com funções simples de recursão (Fibonacci) e iteração (bubble sort) escritas apenas em código Python puro
  • No desenvolvimento real, é comum misturar com código nativo em C/C++/Rust, então estes resultados não correspondem 1:1 a cenários reais

Matriz de testes

  • Ambiente de teste
    • Inclui 6 versões do Python (3.9~3.14), Pypy, Node.js e Rust
    • Interpretadores Python: padrão (Standard), JIT, Free-threading (cada um disponível a partir do 3.13)
    • Scripts de teste: Fibonacci (fibo.py), bubble sort (bubble.py)
    • Modo de threads: thread única, 4 threads
    • Máquinas de teste: Linux (Framework i5), macOS (M2)
  • As versões de Node.js e Rust também foram comparadas como referência

Scripts de teste

  • Fibonacci (fibo.py): usa estrutura recursiva e executa fibo(40) em cada ambiente
  • Bubble sort (bubble.py): ordena 10.000 números aleatórios
  • Cada teste foi repetido 3 vezes para calcular a média
  • O código de teste está disponível no repositório no GitHub

Benchmark #1: Fibonacci (thread única)

  • O Python 3.14 registrou velocidade cerca de 27% superior à do 3.13 (6,59 s vs 8,26 s)
  • A partir da versão 3.11, passou de “muito lento” para “um pouco menos lento”
  • O Pypy é cerca de 5 vezes mais rápido que o 3.14, fica no nível do Node.js, e o Rust é disparado o mais rápido
  • O Free-threading ainda é mais lento que a versão padrão em thread única, mas com o 3.14 a diferença caiu (cerca de 91% do desempenho)

JIT, interpretador Free-threading

  • O JIT não trouxe ganho perceptível de desempenho nessa estrutura de função recursiva
  • O Free-threading, em thread única, teve resultado ligeiramente pior
  • O limite do ganho com JIT pode variar conforme a estrutura da função

Benchmark #2: bubble sort (thread única)

  • O Python 3.14 é só um pouco mais rápido que o 3.11, mas a diferença é menor do que no Fibonacci (3.14: 2,18 s, 3.11: 2,48 s)
  • O Pypy é cerca de 18 vezes mais rápido que o 3.14
  • O JIT chega a ser ligeiramente mais rápido no Linux, mas no macOS a diferença é quase inexistente

Benchmark #3: Fibonacci (multithread)

  • No interpretador padrão, por causa do GIL (Global Interpreter Lock), aumentar o número de threads não traz o ganho esperado
  • O interpretador Free-threading (3.14) ficou 3,1x mais rápido que o padrão
  • Quase não foi possível observar impacto do JIT
  • Só os resultados do Pypy foram medidos; Node.js/Rust não foram comparados neste teste

Benchmark #4: bubble sort (multithread)

  • O Free-threading (3.14 FT) foi 2x mais rápido que o padrão (3.14), destacando sua vantagem especialmente em tarefas intensivas de CPU
  • O JIT não mostrou vantagem clara de desempenho
  • O desempenho do Free-threading no Mac chama atenção

Conclusão

  • O CPython 3.14 apresenta o melhor desempenho entre os CPythons atuais
  • Se for difícil fazer upgrade, recomenda-se usar a versão 3.11 ou superior
  • O interpretador JIT teve ganho de velocidade pequeno na prática
  • O interpretador Free-threading mostra vantagem clara em cenários multithread com carga intensiva de CPU
  • O Pypy é extremamente rápido e vale bastante exploração adicional

Outros

  • Como os resultados podem variar conforme diversos fatores de ambiente, recomenda-se fazer benchmark e validar diretamente
  • Mais detalhes e o código podem ser consultados no repositório do GitHub

Leituras relacionadas

1 comentários

 
GN⁺ 2025-10-10
Opiniões no Hacker News

  • Quero falar sobre uma pessoa que mudou a minha vida. Criei meu primeiro site com o Flask mega tutorial e, logo antes do lançamento, fiquei travado numa parte importante do Flask que lidava com arquivos corrompidos. Fiz uma pergunta, resolvi com uma resposta no Stack Overflow e apliquei no site na mesma hora. Depois disso, o site se espalhou enormemente. Deixo o link da resposta como referência: stackoverflow link

    • Não tem relação com Flask, mas realmente não gosto do novo logo do Flask. O logo antigo tinha uma cara vintage e artesanal, enquanto o novo parece algo que um estudante do ensino médio fez brincando no WordArt. Logo antigo, novo logo

    • Queria perguntar se o site que você criou era o yout.com. Fico curioso para saber se ele ainda usa Flask

    • Seria muito bom se algum dia você voltasse a fazer vibe coding e trouxesse de volta o site microphonetest.com

  • Ao montar benchmarks, recomendo não medir o tempo dentro do loop e ir somando. É melhor medir o tempo de execução do loop inteiro e depois dividir pelo número de iterações. O jitter introduzido pela própria medição de tempo pode distorcer o resultado

  • Fico preocupado que o Python congele na versão 3.14 como o TeX link do Reddit

    • Ao ver a opinião de que se espera que ele não “pare”, achei interessante a parte de que Donald Knuth valoriza mais um sistema que produza consistentemente o mesmo resultado do que mudanças. Num mundo em que tudo fica obsoleto em poucos anos, essa compulsão de achar que é preciso trocar só porque saiu algo novo parece uma doença. Não há motivo para não podermos escrever código que dure 100 anos. Código, no fim, é matemática. Assim como ninguém é visto como antiquado por usar polinômios inventados há milhares de anos, acho que também é preciso saber permanecer no que já foi comprovado. Não é necessário ficar obcecado o tempo todo com nova versão e nova ferramenta. Acho que quem escreve código que não precisa mudar é quem realmente contribui

    • Um comentário dizendo que a situação combina surpreendentemente bem com a piada de πthon

  • Sempre que sai notícia sobre Python, acho uma pena que, em 2025, o PyPy ainda siga como uma linha separada. Fico curioso se um Python sem GIL algum dia também vai permitir C FFI sem GIL. Acho que isso ajudaria muito o Python

    • O C FFI já permitia liberar manualmente o GIL há muito tempo, então fico curioso sobre o que isso significa exatamente

    • Acho saudável um ecossistema em que, partindo de C, diferentes implementações de compilador geram vários dialetos. Isso incentiva experimentação e evolução. Também considero pequena a diferença entre PyPy e CPython, e a compatibilidade é alta guia de compatibilidade do pypy

    • freethreading é justamente para isso. Pelo que sei, ainda não dá para usar freethreading como padrão porque várias bibliotecas de C FFI ainda não foram adaptadas para funcionar sem GIL

    • O Python deu um passo a mais na direção do PyPy ao adicionar um JIT experimental. Não sei se no futuro vão criar um novo JIT do zero ou incorporar o PyPy, mas acredito que aprenderam muita coisa com o PyPy

    • Gostaria de perguntar se você acha que esse tipo de problema (unificar sistemas de implementação separados) pode mudar. Um cenário em que o Python introduza por acaso outra breaking change que prejudique desempenho seria ruim para uma grande faixa de usuários. Será que a organização do Python realmente quer isso?

  • É interessante que o PyPy seja mais rápido que o CPython free-threaded até em código multithread

  • Chamou atenção como a transição para non-GIL foi extremamente suave. Em comparação com a passagem do 2→3, essa transição foi realmente impressionante. Também anima ver que ele chegou rápido ao desempenho padrão, e espero que os elementos incompatíveis desapareçam em breve

  • Se quiser fazer um benchmark rápido por conta própria, recomendo o repositório fast_langton_ant. Dá para executar com algo como python3 server.py -s 10000000 -n

  • Fico curioso se o recurso de comentários recolhidos (fold comment) é aplicado de acordo com karma ou outras opções. Achei marcante que o episódio em que Miguel ajudou tenha sido o post mais popular, mas foi a primeira vez que percebi que não existe um recurso de recolher quando quero ver apenas o que está relacionado ao texto principal

  • Acho difícil avaliar o uso realista de Python com benchmarks que usam apenas laços simples e operações com inteiros. Processamento de hashmap ou strings se aproxima mais de código real. Muitos usuários de Python deixam operações numéricas para bibliotecas externas

    • Todo benchmark acaba sendo projetado para medir segundo algum critério específico. Como a pessoa explicou o objetivo no texto, recomendo consultar se você tiver curiosidade

    • Eu gostaria que fosse uma análise mais minuciosa, mas, ainda assim, esse tipo de benchmark combina melhor com o meu uso real. No meu caso, eu geralmente crio simulações de Monte Carlo ou cálculos científicos simples repetidamente para vários problemas. Para simulações pontuais, não faço questão de usar algoritmos rápidos ou bibliotecas com as quais não tenho familiaridade. Às vezes, não me importo que leve 10 minutos (embora eu use principalmente scipy e numpy). Como mudo as hipóteses com frequência, tento manter a abordagem o mais simples possível. Legibilidade e código improvisado são importantes, e não ligo se a otimização não for boa (por exemplo, Fibonacci, bubble sort, loops for aninhados). Se eu realmente precisar de desempenho, implemento o conteúdo diretamente com cpp/zmp/pybind/numba

    • Incluir no benchmark exemplos populares como chamadas a endpoints FastAPI ou cálculos com numpy seria mais próximo do uso real de Python. Essas partes talvez não sejam código Python puro, mas, na prática, muita gente usa Python assim

  • Questiono o quanto é realista fazer benchmark só com tight loops e operações com int

  • Fico curioso se o novo interpretador experimental de tail call (opção --with-tail-call-interp) foi incluído no benchmark documentação oficial do tail-call-interp. Como não foi mencionado nos resultados do teste, suponho que não tenha sido incluído. Gostaria de comparar o quanto o tail call interpreter difere das outras implementações existentes

    • O build de Python usado estava com o recurso de tail call ativado (opção --with-tail-call-interp). Não tenho certeza se a otimização também foi aplicada a tail call recursiva, mas, se foi, deveríamos ter visto melhora de desempenho no teste de Fibonacci