Python 3.13 obtiene un JIT

Artículo original ↗ Discusión en Hacker News ↗

Python 3.13 incorpora un compilador JIT experimental de “copy-and-patch” que por ahora aporta mejoras modestas de 2–9%, pero se considera una base importante para futuras optimizaciones más grandes. Los comentaristas debaten hasta dónde se puede llevar realmente CPython frente a runtimes con mucho JIT como V8 o PyPy, dada la semántica altamente dinámica de Python, su dependencia de extensiones C y el deseo de preservar la compatibilidad del ecosistema. Muchos siguen viendo valiosas las mejoras incrementales, especialmente si se acumulan a lo largo de varias versiones, mientras que otros cuestionan si finalmente harán falta cambios más profundos o implementaciones alternativas para lograr saltos sustanciales de rendimiento.

Impacto en el rendimiento y expectativas

  • El nuevo JIT de copy-and-patch en CPython 3.13 muestra una mejora de ~2–9% en las pruebas iniciales.
  • Algunos ven esto como ya significativo, especialmente dado que CPython está basado en C y los cambios son mínimos; otros lo encuentran poco impresionante frente a alternativas como PyPy o GraalPython, que afirman mejoras de varias veces.
  • El impacto es limitado al principio: solo las funciones que contienen un salto hacia atrás (es decir, bucles como while/for) se compilan con JIT.
  • Varios comentarios subrayan que esto es trabajo preliminar; muchas pequeñas mejoras a lo largo de varias versiones pueden acumularse de forma importante, aunque ninguna versión por sí sola sea espectacular.

Diseño del JIT y compromisos técnicos

  • El JIT usa un enfoque de “copy-and-patch” / plantilla: las implementaciones en C de los opcodes se compilan en fragmentos de código relocatable, que se ensamblan en tiempo de ejecución para secuencias específicas de bytecode de Python.
  • Esto reutiliza la lógica existente del intérprete, reduce la complejidad nueva y evita incluir LLVM en tiempo de ejecución (las herramientas de LLVM solo se necesitan en tiempo de compilación).
  • Principalmente elimina la sobrecarga de despacho del intérprete; optimizaciones más profundas (por ejemplo, fusión de instrucciones, micro-operaciones, JITs multinivel) se discuten como posibles, pero aún no se han materializado.
  • Algunos dudan de hasta dónde puede llegar un diseño copy-and-patch sin un JIT “completo” de optimización y un análisis más agresivo a nivel de IR.

Comparación con otros runtimes e implementaciones

  • Otros runtimes de Python con JIT o alternativos mencionados: PyPy (media geométrica 4.8x más rápido en sus benchmarks), GraalPython (4.3x más rápido en pyperformance), Jython, IronPython y varias herramientas AOT (Nuitka, mypyc, Shedskin, Numba, Cython).
  • Ninguna de las VMs alternativas ha logrado reemplazar ampliamente a CPython debido a la compatibilidad (especialmente con extensiones C), el comportamiento de calentamiento y el coste de mantenimiento.
  • Se citan motores de JavaScript (V8, JavaScriptCore, SpiderMonkey) como evidencia de que los lenguajes dinámicos pueden hacerse mucho más rápidos, pero tenían menos restricciones de extensiones nativas y una inversión corporativa enorme.

Tipado dinámico, type hints y límites de optimización

  • La dinamicidad de Python (funciones reasignables, monkey-patching, adición de campos en tiempo de ejecución, enteros boxeados) se cita repetidamente como una barrera central para alcanzar rendimiento tipo C.
  • Existen type hints opcionales, pero no son sólidos y en su mayoría los aplican herramientas externas (por ejemplo, mypy); las anotaciones actuales no se consideran lo bastante fiables para grandes optimizaciones de JIT.
  • Algunos sugieren que los JITs deberían basarse en el perfilado en tiempo de ejecución y en guards, como en los motores modernos de JS.

Ecosistema, empaquetado y restricciones de extensiones C

  • Un tema principal: la velocidad de Python para muchas cargas de trabajo ya proviene de extensiones en C/C++/Fortran/Rust (NumPy, PyTorch, BLAS, etc.), con Python actuando sobre todo como “pegamento”.
  • Esta API de C es a la vez una fortaleza y una gran limitación: expone internos de CPython, lo que hace difíciles los cambios radicales de la VM y costosas de adaptar las implementaciones alternativas.
  • Se discuten las frustraciones de empaquetado y despliegue (virtualenvs, Poetry, Docker, falta de herramientas sencillas de cross-compilación/binario único) como problemas serios, a veces vistos como más urgentes que la velocidad bruta del intérprete.

Papel del lenguaje, filosofía y reacciones de la comunidad

  • Muchos sostienen que Python es “lo bastante rápido” para las tareas típicas ligadas a IO e integración; donde el rendimiento realmente importa, la gente recurre a bibliotecas nativas u otros lenguajes.
  • Otros temen que Python se esté quedando demasiado atrás respecto a lenguajes como Rust, Go, Java o incluso JS en velocidad bruta, y esperan que este JIT sea el comienzo de un trabajo de optimización más agresivo.
  • Hay debate sobre la complejidad: el diseño anterior de CPython favorecía la simplicidad por encima de la velocidad, pero el uso a gran escala (especialmente en datos y ML) y la nueva financiación corporativa están impulsando internals más sofisticados.