Python 3.14 ya fue lanzado. ¿Qué tanto más rápido es?

• La recién publicada Python 3.14 muestra el mejor rendimiento entre todas las versiones de CPython hasta ahora
• En un solo hilo, 3.14 mostró una mejora de alrededor del 27% frente a 3.13; la mejora de rendimiento del JIT es mínima, y el intérprete Free-threading es ligeramente más lento en un solo hilo
• En multihilo, el intérprete FT muestra aceleración gracias a la eliminación del GIL: 3.1 veces en Fibonacci y 2 veces en bubble sort, por lo que resulta útil para multihilo intensivo en CPU
• En conclusión, 3.14 es el CPython más rápido, se recomienda usar 3.11 o superior, Pypy sigue siendo muy rápido y el JIT todavía necesita madurar

---

Supuestos y límites del benchmark

• Justo después del lanzamiento oficial de Python 3.14, se compartieron resultados de benchmarks de rendimiento entre varias versiones de Python y otros lenguajes
• Esta prueba se realizó con funciones simples de recursión (Fibonacci) e iteración (bubble sort) escritas únicamente en Python puro
• En entornos reales de desarrollo suele mezclarse con código nativo en C/C++/Rust, por lo que estos resultados no se corresponden 1:1 con situaciones reales

Matriz de pruebas

• Entorno de pruebas
  • 6 versiones de Python (3.9~3.14), además de Pypy, Node.js y Rust
  • Intérpretes de Python: estándar (Standard), JIT, Free-threading (cada uno disponible desde 3.13)
  • Scripts de prueba: Fibonacci (fibo.py), bubble sort (bubble.py)
  • Modo de hilos: un solo hilo, 4 hilos
  • Máquinas de prueba: Linux (Framework i5), macOS (M2)
• También se compararon como referencia las versiones de Node.js y Rust

Scripts de prueba

• Fibonacci (fibo.py): usa una estructura recursiva y ejecuta fibo(40) en cada entorno
• Bubble sort (bubble.py): ordena 10,000 números aleatorios
• Cada prueba se repitió 3 veces para obtener un promedio
• El código de prueba está publicado en el repositorio de GitHub

Benchmark #1: Fibonacci (un solo hilo)

• Python 3.14 registró una velocidad aproximadamente 27% superior a la de 3.13 (6.59 s vs 8.26 s)
• Desde la versión 3.11 pasó de “muy lento” a “algo menos lento”
• Pypy es unas 5 veces más rápido que 3.14, está al nivel de Node.js, y Rust es por mucho el más rápido
• Free-threading sigue siendo más lento que la versión estándar en un solo hilo, pero al llegar 3.14 la diferencia de velocidad se redujo (hasta un 91%)

JIT, intérprete Free-threading

• El JIT no muestra una mejora perceptible de rendimiento con esta estructura de función recursiva
• Free-threading dio como resultado un rendimiento ligeramente peor en un solo hilo
• El límite en la mejora del JIT puede variar según la estructura de la función

Benchmark #2: Bubble sort (un solo hilo)

• Python 3.14 es apenas un poco más rápido que 3.11, pero la diferencia es menor que en Fibonacci (3.14: 2.18 s, 3.11: 2.48 s)
• Pypy es aproximadamente 18 veces más rápido que 3.14
• El JIT puede ser ligeramente más rápido en Linux, mientras que en macOS casi no hay diferencia

Benchmark #3: Fibonacci (multihilo)

• En el intérprete estándar, debido al GIL (Global Interpreter Lock), aumentar la cantidad de hilos no acelera tanto como se esperaría
• El intérprete Free-threading (3.14) es 3.1 veces más rápido que el estándar
• Casi no se observa impacto del JIT
• Solo se midieron resultados de Pypy; Node.js y Rust no se compararon en esta prueba

Benchmark #4: Bubble sort (multihilo)

• Free-threading (3.14 FT) fue 2 veces más rápido que la versión estándar (3.14), especialmente destacando en tareas intensivas en CPU
• El JIT no muestra una ventaja clara de rendimiento
• El rendimiento de Free-threading en Mac llama la atención

Conclusión

• CPython 3.14 ofrece el mejor rendimiento entre los CPython existentes hoy
• Si actualizar es difícil, se recomienda usar la versión 3.11 o superior
• El intérprete JIT mostró aumentos de velocidad mínimos en la práctica
• El intérprete Free-threading tiene ventajas claras en escenarios multihilo intensivos en CPU
• Pypy es abrumadoramente rápido y vale la pena explorarlo más

Otros

• Como los resultados pueden variar según muchas variables del entorno, se recomienda hacer benchmarks y comprobarlos directamente
• Para más detalles y el código, se puede consultar el repositorio de GitHub

[GN⁺]

Opiniones de Hacker News

• Quiero hablar de alguien que me cambió la vida. Hice mi primer sitio web con el Flask mega tutorial, y justo antes del lanzamiento me quedé atorado en una parte importante para manejar archivos rotos en Flask. Hice una pregunta, la resolví con una respuesta en Stack Overflow y la apliqué al sitio de inmediato. Después de eso, el sitio se difundió muchísimo. Dejo el enlace de la respuesta como referencia stackoverflow link

  • No tiene nada que ver con Flask, pero la verdad no me gusta nada el nuevo logo de Flask. El logo anterior tenía una vibra vintage y artesanal, pero el nuevo parece como si un estudiante de preparatoria hubiera jugado con WordArt por diversión. Logo anterior, logo nuevo

  • Quisiera preguntar si el sitio que hiciste es yout.com. También me da curiosidad si todavía usas Flask

  • Estaría buenísimo que algún día volvieran a hacer vibe coding y reviviera el sitio microphonetest.com

• Recomiendo no escribir benchmarks midiendo el tiempo dentro del loop y luego sumándolo. Es mejor medir el tiempo de ejecución del loop completo y después dividir entre el número de iteraciones. El jitter del propio proceso de medición puede distorsionar los resultados

  • Recomiendo timeit de la biblioteca estándar timeit docs

• Me preocupa que Python se quede congelado en la versión 3.14 como TeX enlace de Reddit

  • Al ver la opinión de que esperan que no se "detenga", me pareció refrescante esa parte de Donald Knuth en la que valora más un sistema que produce resultados consistentemente iguales que uno que cambia. En un mundo donde todo se vuelve obsoleto en pocos años, esa compulsión de sentir que hay que cambiar algo solo porque salió una nueva OOO me parece una enfermedad. No hay razón por la que no podamos escribir código que dure 100 años. Al final, el código es matemáticas. Igual que nadie te considera anticuado por usar polinomios inventados hace miles de años, también hace falta saber quedarse con lo que ya está probado. No hace falta obsesionarse siempre con la nueva versión o la nueva herramienta. Creo que quienes escriben código que no necesita cambiar son quienes realmente están contribuyendo

  • Un comentario diciendo que la situación encaja sorprendentemente bien con el chiste de πthon

• Cada vez que sale una noticia sobre Python, me da pena que en 2025 PyPy siga yendo por una ruta separada. Me pregunto si algún día Python sin GIL también permitirá C FFI sin GIL. Creo que eso ayudaría muchísimo a Python

  • Desde hace tiempo el C FFI podía liberar manualmente el GIL, así que me pregunto exactamente qué quiere decir eso

  • Creo que es sano para el ecosistema que, partiendo de C, aparezcan varios dialectos mediante distintas implementaciones de compiladores. Eso fomenta la experimentación y el progreso. Tampoco considero que la diferencia entre PyPy y CPython sea tan grande, y la compatibilidad es alta guía de compatibilidad de pypy

  • Para eso es justamente freethreading. Tengo entendido que todavía hay varias bibliotecas de C FFI que no se han adaptado para funcionar sin GIL, por eso no se puede usar freethreading como opción predeterminada

  • Python, al agregar un JIT experimental, dio un paso más hacia PyPy. No sé si en el futuro harán un JIT nuevo por su cuenta o si integrarán PyPy, pero creo que aprendieron mucho de PyPy

  • Quisiera preguntar si creen que este problema (unificar sistemas de implementación separados) puede cambiar. Un escenario donde Python introduzca accidentalmente otro breaking change que perjudique el rendimiento sería dañino para un rango amplio de usuarios. Me pregunto si la organización de Python realmente querría eso

• Es interesante que PyPy sea más rápido que CPython free threaded incluso en código multihilo

• Llama la atención lo fluida que ha sido la transición hacia non-GIL. Comparada con la transición de la versión 2 a la 3, esta de verdad es impresionante. También entusiasma que haya alcanzado la velocidad estándar tan rápido, y espero que los elementos incompatibles desaparezcan pronto

• Si quieres hacer una prueba rápida del benchmark por tu cuenta, recomiendo el repo fast_langton_ant. Puedes ejecutarlo con algo como python3 server.py -s 10000000 -n

• Me pregunto si la función de plegar comentarios (fold comment) se aplica según el karma u otras opciones. Me impresionó que la historia sobre la ayuda de Miguel fuera la publicación más popular, pero cuando quise ver solo lo relacionado con el texto principal me di cuenta por primera vez de que no había función para plegar

• Creo que es difícil evaluar el uso realista de Python con benchmarks que solo usan loops simples y operaciones con enteros. El manejo de hash maps o strings se parece más al código real. Muchos usuarios de Python dejan las operaciones numéricas a bibliotecas externas

  • Todos los benchmarks se diseñan para medir según algún criterio específico. Como la persona explicó su objetivo en el texto, recomiendo revisarlo si te da curiosidad

  • Ojalá hubiera sido un análisis más exhaustivo, pero aun así este tipo de benchmark encaja mejor con mi uso real. En mi caso, la mayoría del tiempo hago simulaciones Monte Carlo o cálculos científicos simples para distintos problemas una y otra vez. Para simulaciones de una sola ocasión no me complico usando algoritmos rápidos o bibliotecas con las que no estoy familiarizado. A veces no importa si tarda 10 minutos (aunque sí uso principalmente scipy y numpy). Como cambio mucho las suposiciones de una iteración a otra, trato de mantenerlo lo más simple posible. La legibilidad y el código improvisado importan, y no me preocupa si la optimización no es buena (por ejemplo: Fibonacci, bubble sort, loops for anidados). Si de verdad necesito rendimiento, entonces implemento yo mismo el contenido con cpp/zmp/pybind/numba

  • Incluir ejemplos populares en el benchmark, como llamadas a endpoints de FastAPI o cálculos con numpy, sería más cercano al uso real de Python. Puede que esas partes no sean código puro de Python, pero en la práctica mucha gente usa Python así

• Me pregunto qué tan realista es hacer benchmarks solo con tight loops y operaciones con enteros

• Me pregunto si el nuevo intérprete experimental de tail call (opción --with-tail-call-interp) se incluyó en el benchmark documentación oficial de tail-call-interp. Como no se menciona en los resultados, supongo que probablemente no se incluyó. Me gustaría comparar cuánto difiere este intérprete de tail call respecto a otras implementaciones existentes

  • La build de Python que usé sí tenía activada la función de tail call (opción --with-tail-call-interp). No estoy seguro de si la optimización también se aplicó a las llamadas recursivas tail call, pero si se aplicó, debería haberse visto una mejora de rendimiento en la prueba de Fibonacci