Python 3.15 revive su JIT y promete ser mucho más rápido

Actualizado el 25/03/2026: Mojo, el lenguaje creado por los fundadores de Modular Inc como sucesor de Python para IA, sigue en desarrollo activo pero todavía no cumple su promesa de ser un superset compatible. Analizamos en detalle qué funciona, qué no, y cómo se compara realmente con Python.

El compilador JIT de Python 3.15 volvió a encarrilarse tras la crisis del equipo Faster CPython en 2025. Los benchmarks muestran entre 5% y 20% de mejora en rendimiento según la plataforma, con un frontend de tracing completamente reescrito, asignación básica de registros y soporte para LLVM 21.

CPython JIT es un compilador Just-In-Time integrado en el intérprete estándar de Python que usa la técnica copy-and-patch para generar código máquina nativo en tiempo de ejecución. Fue introducido experimentalmente en Python 3.13 bajo PEP 744 y en la versión 3.15 alcanza un nivel de madurez significativamente mayor.

Qué es el compilador JIT de CPython y por qué importa

Python siempre fue un lenguaje interpretado. Tu código se convierte en bytecode y el intérprete lo ejecuta instrucción por instrucción. Funciona, pero es lento comparado con lenguajes que compilan a código máquina nativo. Ahí entra el JIT.

Un compilador Just-In-Time analiza el código mientras se ejecuta, detecta los caminos calientes (las funciones y loops que más se repiten) y los compila a código máquina nativo sobre la marcha. Es el mismo principio que usan la JVM de Java, el V8 de JavaScript y PyPy desde hace años.

Lo que hace particular al JIT de CPython es la técnica que usa: copy-and-patch, basada en un paper académico de Haas y Rompf de 2021. En lugar de incluir un compilador completo dentro del intérprete, se pre-compilan “stencils” (plantillas de código máquina) en tiempo de build usando LLVM/Clang. En runtime, el JIT toma esas plantillas, les inyecta los valores concretos y las ensambla. El resultado es código máquina nativo sin la complejidad de un compilador tradicional embebido.

El pipeline completo funciona así: bytecode de Python pasa por especialización adaptativa, se convierte en micro-operaciones (uops), el optimizador genera traces optimizados, y finalmente el JIT compila esos traces a código máquina. Cada capa agrega un nivel de optimización. Lo interesante es que este mismo pipeline de uops es el que habilita tanto el JIT como el free-threading (Python sin GIL), lo cual no es casualidad.

La crisis del equipo Faster CPython: pérdida de sponsor y recuperación comunitaria

En 2025 el equipo Faster CPython perdió su sponsor principal. Para un proyecto de esta envergadura, eso fue un golpe serio. El equipo que venía trabajando en el JIT y en las optimizaciones del intérprete se quedó sin respaldo financiero, y el futuro del compilador JIT quedó en duda.

La comunidad respondió. Según el blog de Ken Jin, uno de los core developers que lideró la reescritura del frontend de tracing, el proyecto se reorganizó con contribuciones voluntarias y durante el core sprint de Cambridge el equipo JIT se reunió presencialmente para definir un plan concreto. Los objetivos quedaron claros: 5% más rápido en Python 3.15, 10% en Python 3.16.

El tema es que esos objetivos de 3.15 se alcanzaron antes de lo previsto. Y en algunas plataformas, se superaron por bastante margen. Eso habla bien de la capacidad de la comunidad CPython para sostener un proyecto técnicamente ambicioso sin depender de un único sponsor corporativo. Ahora bien, habrá que ver si ese ritmo se mantiene a largo plazo sin financiamiento estable.

Los nombres clave detrás de la recuperación: Ken Jin (tracing frontend, optimización de refcount, propagación de constantes), Mark Shannon (asignación de registros, soporte Windows, generación de código AArch64), Brandt Bucher (arquitecto original del JIT, generación de código máquina) y Savannah Ostrowski (integración de LLVM 21, propagación de constantes). Ya lo cubrimos antes en las vulnerabilidades que afectan al ecosistema Python.

Nuevo frontend de tracing: cómo el JIT de Python 3.15 rastrea la ejecución real

El cambio técnico más importante de esta versión es la reescritura completa del frontend de tracing. En Python 3.14, el sistema estimaba los caminos de ejecución probables. En 3.15, los registra tal como ocurren. La diferencia es enorme.

Cuando el JIT anterior tenía que decidir qué optimizar, hacía suposiciones. “Este if probablemente va por la rama true”, “esta función probablemente recibe un int”. A veces acertaba, a veces no. El nuevo frontend registra la ejecución real del programa y genera traces basados en lo que efectivamente pasó, no en lo que debería pasar.

¿Qué ganás con eso? Soporte para muchos más bytecodes que antes, incluyendo flujos de control complejos, creación simple de objetos Python, operaciones sobrecargadas y generadores. En 3.14, los generadores eran una barrera: si tu código los usaba mucho, el JIT no podía hacer gran cosa. Ahora el frontend los entiende y puede generar traces que los incluyan.

Ken Jin lideró la implementación principal (referenciada en el issue gh-139109 de CPython), y Mark Shannon sumó el soporte para Windows (gh-141703). El resultado es un JIT que puede optimizar una porción significativamente mayor del código Python real que la gente escribe en producción, no solo microbenchmarks sintéticos.

Benchmarks concretos: cuánto más rápido es Python 3.15 con el compilador JIT

Los números según la documentación oficial de Python 3.15 (marcados como “not yet final”):

Esos 15-20% en Windows con MSVC 18 merecen contexto. Windows históricamente fue la plataforma donde CPython peor rendía en relación a Linux. El nuevo compilador de Microsoft (Visual Studio 2026) habilita el tail-calling interpreter que antes no estaba disponible en ese entorno, y combinado con el JIT la mejora es notable: scripts puros de Python de larga ejecución muestran hasta 40% de speedup.

Un ejemplo concreto: si tenés un script de procesamiento de datos que tarda 100 segundos en x86-64 Linux, con el JIT podés esperar que baje a ~95 segundos en promedio. Para un microservicio que atiende requests, 5-6% menos de CPU por request se traduce directamente en menor costo de infraestructura.

El rango de -15% a +100% dice algo importante: no todo el código se beneficia igual. Hay benchmarks donde el JIT es más lento que el intérprete optimizado. El overhead de compilación JIT tiene un costo, y para código con mucha I/O o muchos llamados a extensiones C, ese costo puede no compensarse.

Novedades técnicas: asignación de registros, LLVM 21 y soporte ampliado de bytecodes

Más allá del frontend de tracing, hay tres mejoras técnicas que vale la pena desglosar.

Asignación básica de registros. Mark Shannon implementó (gh-135379) un allocator de registros en el optimizador JIT. En lugar de que cada operación pase por la pila (push, pop, push, pop), el optimizador detecta valores que pueden vivir en registros del procesador. Menos lecturas y escrituras a memoria significan traces más eficientes. Todavía es una implementación básica comparada con lo que hace un compilador C optimizante, pero es un primer paso concreto.

LLVM 21 para stencils. Savannah Ostrowski migró la generación de stencils a LLVM 21 (gh-140973). LLVM se usa solo en tiempo de build, para generar las plantillas de código máquina que el JIT después parcela y ensambla en runtime. La migración a LLVM 21 trae mejores optimizaciones en los stencils generados, lo que se traduce en código máquina más eficiente sin cambios visibles para el usuario final. Sobre eso hablamos en los frameworks modernos que consolidan Python.

Soporte ampliado de bytecodes. El nuevo frontend no solo rastrea mejor: entiende más instrucciones. Esto significa que funciones con patrones de código que antes el JIT ignoraba ahora pueden compilarse a código nativo. Para proyectos científicos o de análisis de datos que usan generators intensivamente, esto marca una diferencia práctica.

Mojo vs Python: el lenguaje que promete reemplazar a Python para IA (y todavía no puede)

Mientras CPython mejora de a poco con su JIT, existe un proyecto más ambicioso que apunta directamente al mismo problema desde otra dirección: Mojo. Y la comparación Mojo vs Python merece un análisis honesto, porque la brecha entre lo que promete y lo que entrega hoy es considerable.

Mojo fue creado por Chris Lattner y Tim Davis, cofundadores de Modular Inc en 2022. Lattner no es un desconocido: creó LLVM y fue el arquitecto principal de Swift en Apple. Davis viene del mundo de compiladores y HPC. El lanzamiento inicial fue en septiembre de 2022, con acceso público desde 2023. El objetivo declarado: resolver las limitaciones de rendimiento de Python para workloads de inteligencia artificial, sin obligar a los desarrolladores a abandonar la sintaxis que ya conocen.

La propuesta conceptual es sólida. Python domina el ecosistema de ML/AI, pero su velocidad nativa es un problema real. Las soluciones actuales (NumPy, PyTorch, JAX) delegan el trabajo pesado a extensiones C/C++/CUDA. Mojo apunta a que puedas escribir código de alto rendimiento directamente en Python-like syntax, sin esa capa de indirección.

Según Wikipedia, Mojo se define como un lenguaje de programación de propósito general orientado especialmente a sistemas e inteligencia artificial. La página oficial de Modular lo describe como un “superset de Python”. Algunos usuarios en la comunidad lo llaman directamente “Python++”.

El problema es que esa promesa de superset todavía no es realidad.

Qué funciona y qué no: la compatibilidad real de Mojo con código Python

Según un análisis detallado publicado en The Consensus, intentar compilar código Python estándar en Mojo resulta en una serie de errores que van desde molestos hasta bloqueantes. Y esto aplica a código Python perfectamente válido, no a casos extremos.

Los problemas más frecuentes que se documentaron:

• Falta de soporte para argumentos variables en funciones. El patrón *args y **kwargs, que en Python es ubicuo, no compila directamente en Mojo.
• La keyword global no está soportada. Cualquier script que use variables globales mutables falla en compilación.
• Las clases tienen limitaciones importantes. La herencia múltiple y ciertos métodos especiales de Python no están implementados. Mojo tiene su propio sistema basado en struct, que es diferente.
• El sistema de tipos dinámico de Python choca con las expectativas del compilador de Mojo. Código que funciona sin tipos en Python puede generar errores de tipo en Mojo.

Esto no es una crítica destructiva a Mojo. El proyecto está en versión 0.26.1 a principios de 2026 y el equipo es transparente respecto a que la compatibilidad completa es un objetivo futuro, no una característica actual. El punto es que si alguien llega a Mojo esperando que su código Python existente “simplemente funcione”, se va a encontrar con fricciones reales.

La distinción clave está en dos tipos de funciones que Mojo ofrece. def funciona de forma similar a Python, con tipado dinámico. fn es la versión estática, con tipos obligatorios y un borrow checker parecido al de Rust. Para sacar rendimiento real, necesitás usar fn con tipos explícitos, lo que implica reescribir el código, no solo compilarlo.

Características únicas de Mojo que Python no tiene

Donde Mojo sí se diferencia claramente es en su modelo de memoria y su pipeline de compilación. No es Python con tipos: es un lenguaje diferente que comparte sintaxis de superficie.

El sistema de tipos híbrido (fn para código estático, def para dinámico) permite mezclar los dos mundos en el mismo archivo. Podés tener funciones de utilidad en estilo Python y funciones de cómputo intensivo totalmente tipadas, lado a lado. Eso tiene sentido para proyectos de ML donde el 80% del código es glue logic y el 20% es el kernel de cómputo que necesita velocidad máxima.

Los structs de Mojo son análogos a las clases de Python pero con layout de memoria predecible. No tienen overhead de heap allocation por defecto. Para operaciones matriciales o buffers de datos, eso marca una diferencia de rendimiento sustancial. Esto se conecta con lo que analizamos en cómo afecta la seguridad en repositorios compartidos.

El borrow checker es quizás el elemento más novedoso para alguien que viene de Python. Similar al de Rust, permite al compilador razonar sobre la vida útil de los objetos y evitar copias innecesarias. En Python, el GC maneja todo eso de forma automática pero con overhead. En Mojo, podés tener control explícito cuando lo necesitás.

La compilación se hace a través de MLIR (Multi-Level Intermediate Representation), la infraestructura de compilación que también usa TensorFlow XLA y otros proyectos de ML. Eso no es casualidad: Mojo está diseñado desde el día uno para generar código eficiente en GPUs y aceleradores de hardware, no solo en CPUs.

Cómo Mojo llama a código Python existente: PythonObject y CPython runtime

La respuesta de Mojo al problema de compatibilidad es pragmática, aunque no ideal. En lugar de ejecutar código Python directamente, Mojo puede llamar al runtime de CPython 3.x y usar sus módulos a través de un tipo especial llamado PythonObject.

El flujo funciona así: dentro de un archivo .mojo, podés importar módulos Python estándar (NumPy, Pandas, lo que necesites) usando una sintaxis especial. Mojo delega la ejecución de esas llamadas al intérprete de CPython, que corre como un proceso embebido. El resultado llega de vuelta a Mojo como un PythonObject, que podés operar desde código Mojo.

Esto funciona en Jupyter Notebooks, lo que facilita la experimentación interactiva. Para alguien que trabaja con notebooks de análisis de datos, la integración es relativamente fluida. Hay ejemplos documentados de cómo usar objetos Python dentro de Mojo con este mecanismo.

El problema es el overhead. Cruzar la frontera entre Mojo y CPython tiene un costo. Para llamadas frecuentes en loops de cómputo, ese overhead puede anular las ganancias de rendimiento que buscabas. La recomendación del propio equipo de Modular es usar la interop con Python para el setup y configuración, y escribir el código de cómputo crítico directamente en Mojo con tipos estáticos.

Los planes futuros incluyen integración de módulos C/C++ directamente vía Clang, lo que ampliaría significativamente la cantidad de código existente que Mojo podría reutilizar sin pasar por el runtime de CPython. Lo complementamos en agentes de IA construidos enteramente en Python.

Rendimiento de Mojo para IA: los números y lo que significan

Modular ha publicado benchmarks que muestran a Mojo siendo hasta 68.000x más rápido que Python puro en ciertos casos. Ese número es real, pero requiere contexto para no ser engañoso.

Los casos donde se alcanzan esas magnitudes son operaciones numéricas intensivas sobre arrays, con código Mojo completamente tipado, usando structs nativos y SIMD explícito. No es código Python transpilado: es código Mojo escrito desde cero para extraer el máximo rendimiento del hardware. Compararlo directamente con Python puro (sin NumPy, sin Cython) es una comparación un poco tendenciosa.

Una comparación más honesta sería Mojo vs NumPy para operaciones matriciales, o Mojo vs código Cython optimizado. En esos escenarios los números son más modestos pero todavía significativos: mejoras de 2x a 10x sobre NumPy en ciertos kernels son plausibles. Tomalo con pinzas hasta que haya más benchmarks independientes. En las herramientas de IA que demandan más potencia profundizamos sobre esto.

Para el despliegue de modelos de machine learning, el caso de uso más concreto es reemplazar los kernels CUDA escritos en C++ con código Mojo. El objetivo de Modular con su plataforma MAX es justamente ese: que puedas escribir kernels de inferencia en Mojo y deployarlos en cualquier hardware (NVIDIA, AMD, Apple Silicon) sin cambiar de código. Si eso funciona en producción, el impacto sería real para equipos que hoy mantienen código C++ específico por arquitectura.

Mojo vs Python: tabla comparativa

Estado actual y roadmap: qué está confirmado y qué todavía no

Qué significa para equipos en Latinoamérica

Para equipos de data science y ML en Argentina, Uruguay, Chile o México, la pregunta práctica es: ¿vale la pena mirar Mojo ahora?

La respuesta honesta es: todavía no para producción, pero sí para exploración. Si tu equipo trabaja con Python para ML y sentís el techo de rendimiento, Mojo es un proyecto para seguir de cerca. Pero apostar a él hoy para infraestructura crítica sería prematuro. El ecosistema de librerías es pequeño, la compatibilidad con código existente es limitada, y el soporte de la comunidad no se compara con Python todavía.

Donde sí tiene sentido invertir tiempo es en entender el modelo de tipos de Mojo. Si ya usás type hints en Python y tenés experiencia con Rust o C++, la curva de aprendizaje es manejable. Y si trabajás con modelos de inferencia en producción, la plataforma MAX de Modular (que usa Mojo bajo el capó) podría ser relevante en 2026-2027.

Para los equipos que quieran experimentar con Mojo sin montar infraestructura propia, los notebooks en la nube son la entrada más accesible. Si después querés llevar algo a producción, necesitarás un entorno Linux con las dependencias de Modular instaladas. Para ese tipo de proyectos, contar con un hosting confiable y configurable como Donweb facilita bastante el proceso desde Latinoamérica.

Si querés profundizar en garbage collection, podés leer Mojo’s not (yet) Python donde lo analizamos en detalle.

Preguntas frecuentes

¿Qué es Mojo y para qué sirve?

Mojo es un lenguaje de programación creado por Modular Inc, diseñado para combinar la sintaxis familiar de Python con el rendimiento de lenguajes de bajo nivel como C++ o Rust. Su caso de uso principal es el desarrollo de modelos de machine learning y sistemas de IA donde Python resulta demasiado lento. Está especialmente orientado a escribir kernels de cómputo que puedan ejecutarse eficientemente en CPUs, GPUs y otros aceleradores de hardware.

¿Mojo es compatible con Python o es un lenguaje diferente?

Mojo comparte gran parte de la sintaxis de Python y la página oficial de Modular lo describe como un superset de Python, pero en la práctica (versión 0.26.1, 2026) la compatibilidad es parcial. Código Python estándar que usa *args, **kwargs, la keyword global o herencia múltiple no compila directamente en Mojo sin modificaciones. Mojo puede llamar a módulos Python existentes a través del runtime de CPython usando PythonObject, pero eso agrega overhead y no es lo mismo que ejecutar código Python nativo.

¿Mojo es más rápido que Python para IA?

En benchmarks publicados por Modular, Mojo muestra mejoras de hasta 68.000x sobre Python puro en operaciones numéricas intensivas. Esa cifra corresponde a comparaciones contra Python sin librerías optimizadas, con código Mojo completamente tipado y usando instrucciones SIMD explícitas. En comparaciones más equilibradas contra NumPy o Cython, las mejoras son reales pero más modestas (2x-10x en ciertos kernels). Para workloads de inferencia de modelos, la plataforma MAX de Modular promete mejoras concretas, aunque los benchmarks independientes todavía son escasos.

¿Quién creó Mojo y cuáles son sus objetivos?

Mojo fue creado por Chris Lattner (creador de LLVM y Swift, ex-Apple y ex-Google Brain) y Tim Davis, cofundadores de Modular Inc en 2022. El objetivo es proveer una alternativa de alto rendimiento a Python para el ecosistema de IA, eliminando la necesidad de escribir extensiones en C++ o CUDA para las partes críticas del código. Modular también desarrolla la plataforma MAX, un motor de inferencia para modelos de ML que usa Mojo como lenguaje base para sus kernels.

¿Se puede usar Mojo en Jupyter Notebooks como Python?

Sí, Mojo tiene soporte básico para Jupyter Notebooks. El equipo de Modular ofrece un kernel de Jupyter que permite ejecutar código Mojo de forma interactiva, similar a la experiencia con Python. La integración es funcional para prototipado y experimentación, aunque no tiene la madurez ni la cantidad de extensiones disponibles para Python. Para quienes trabajan habitualmente con notebooks de análisis de datos, es la forma más accesible de empezar a explorar Mojo sin configurar un entorno de compilación completo.

Conclusión

Python 3.15 mejora de forma incremental y medible con su JIT: 5-20% dependiendo de la plataforma, con arquitectura técnica sólida y un equipo comunitario que demostró poder sostener el proyecto sin sponsor corporativo. No es un salto dramático, pero es progreso real y confiable.

Mojo es otra historia. La ambición es legítima: Chris Lattner tiene credenciales para encarar algo así, y el problema que intenta resolver (Python lento para IA) es real. Pero hoy, en 2026, Mojo todavía no es el superset de Python que promete ser. La compatibilidad es parcial, el ecosistema es pequeño, y muchos de los números de rendimiento más impresionantes vienen de comparaciones que favorecen a Mojo.

Lo que conviene hacer de acá en adelante: seguir la evolución de Mojo de cerca, especialmente la plataforma MAX para inferencia. Si trabajás con kernels de ML de alto rendimiento, vale la pena tener un ambiente de prueba. Para producción, Python con el JIT de 3.15 sigue siendo la apuesta segura. Y si en 2027 Mojo llega a compatibilidad real con Python 3.x con ecosistema maduro, esa conversación va a ser completamente distinta.

Fuentes

• The Consensus — Mojo’s not (yet) Python: análisis de compatibilidad real
• Wikipedia — Mojo (lenguaje de programación)
• iArtificial Blog — Descubriendo Mojo: características y objetivos
• Andrés Felipe Ocampo (Medium) — PythonObject en Mojo: uso práctico
• Documentación oficial Python 3.15 — What’s New