Anuncio del Steering Council sobre el proyecto JIT

• El compilador JIT experimental de CPython se ha desarrollado durante años en la rama main y recientemente mostró mejoras reales de rendimiento, pero para seguir como una funcionalidad compatible necesita una revisión formal mediante un PEP
• PEP 744 abordó el diseño inicial y los criterios para convertirlo en una funcionalidad permanente, pero aún no hay consenso sobre mantenedores a largo plazo, revisión de seguridad, soporte para depuración y herramientas de procesos externos, garantías de ejecución y obligaciones para redistribuidores y empaquetadores downstream
• El Python Steering Council solicitó oficialmente redactar un PEP de Standards Track para convertir el JIT en una funcionalidad no experimental compatible de CPython, y pidió suspender la incorporación a main de nuevas funciones, optimizaciones y trabajo de rendimiento hasta que el PEP sea aceptado
• El nuevo PEP debe abordar el mantenimiento a largo plazo, la compatibilidad con funciones y herramientas existentes de CPython, métricas de éxito medibles y un calendario, la relación con JITs de terceros como CinderX, Numba y PyTorch, y la estabilidad de la arquitectura actual
• Si el PEP no se presenta y resuelve dentro de 6 meses, o no es aceptado, el código JIT se eliminará de la rama main y el desarrollo deberá continuar fuera del repositorio principal de Python

---

Contexto y solicitud oficial

• El compilador Just-In-Time experimental de CPython es un trabajo que varios core developers y colaboradores han venido desarrollando en la rama main durante los últimos años, y las mejoras recientes de rendimiento son resultados reales y alentadores
• Esta medida no es una crítica al trabajo del JIT ni a quienes participan en él; más bien, como el proyecto ha avanzado durante mucho tiempo y ha pasado por varios rediseños, se considera que llegó el momento de reevaluar el estatus informal del JIT dentro del proyecto CPython
• El JIT entró en main como un experimento cuando se fusionó por primera vez, y el PEP relacionado, PEP 744, es un Informational PEP
• PEP 744 trató el diseño inicial y esbozó los criterios para que el JIT pudiera convertirse en una funcionalidad permanente, pero dejó abiertas preguntas como mantenedores a largo plazo, revisión de seguridad, soporte para depuración y herramientas de procesos externos, garantías de ejecución y obligaciones de redistribuidores y empaquetadores downstream
• El Python Steering Council considera que un cambio con este nivel de complejidad y alcance requería un proceso más riguroso, y que esas preguntas pendientes son compromisos que la comunidad debe examinar y acordar mediante el proceso de PEP
• Para convertir el JIT en una funcionalidad no experimental compatible de CPython, se necesita un Standards Track PEP que también cubra garantías, compromisos de mantenimiento e impacto en redistribuidores, además de un proceso formal de aceptación o rechazo por parte del Steering Council tras la discusión de la comunidad
• Hasta que ese PEP sea aceptado, no deberían incorporarse nuevos desarrollos del JIT en la rama main; esto incluye nuevas funciones, optimizaciones y trabajo de rendimiento
• Las correcciones de errores y de seguridad pueden continuar; el alcance de la suspensión se limita a incorporar funciones adicionales del JIT antes de la aceptación del PEP

Temas que debe cubrir el PEP y calendario de 6 meses

• No se busca exigir propuestas competidoras, pero este también es un buen momento para discutir alternativas, y coincide con la postura previa de que no deberían hacerse experimentos en la rama main de CPython sin un PEP
• En lugar de proponer una sola implementación de JIT, podría ser más apropiado un PEP que describa una infraestructura de JIT capaz de soportar múltiples estrategias de implementación
• Como se siguen proponiendo varios enfoques prometedores de JIT tracing, la infraestructura no debería quedar fuertemente acoplada a una sola estrategia, sino permitir experimentar y evaluar con facilidad esos enfoques dentro de CPython
• El PEP debe establecer un plan claro sobre cómo sostener y mantener a largo plazo un subsistema de esta escala y complejidad, y qué impacto tendrá en mantenedores y colaboradores que no contribuyen directamente al JIT
• El PEP debe abordar la compatibilidad con funciones y herramientas existentes de CPython, y tratar de forma amplia y detallada la interacción y las garantías entre el JIT y funciones como free-threading, profiler y debugger
• El PEP debe incluir métricas de éxito claras y medibles, así como un calendario, y cubrir metas y plazos como objetivos de rendimiento, alcance del soporte de plataformas y sobrecosto de memoria
• El PEP debe abordar la relación con otros compiladores JIT y aclarar si se trata de un diseño que provee una infraestructura general sobre la que otros esfuerzos puedan construir, y si prevé compatibilidad o incompatibilidad con JITs de terceros como CinderX, Numba y PyTorch
• El PEP debe tratar si la arquitectura actual del JIT se considera estable o si todavía es probable que cambie más
• Esta lista no es exhaustiva, y pueden añadirse más temas a medida que avance la discusión en la comunidad
• Se establece un plazo de 6 meses para la presentación y resolución del PEP; si dentro de ese periodo el PEP no es aceptado, el código JIT será eliminado de la rama main y el desarrollo deberá continuar fuera del repositorio principal de Python
• Este requisito no significa el fin del proyecto, sino un proceso para dar la claridad necesaria y un compromiso explícito de la comunidad ante un cambio grande en el runtime de CPython

[GN⁺]

Comentarios en Lobste.rs

• No se ve muy agresivo, pero sí un poco incómodo. Si JIT sigue siendo una función experimental, no parece problemático que continúe integrándose
  Si personas como Shannon dicen “voy a traer un PEP, pero por favor eviten conflictos incómodos”, siento que se les puede tener suficiente confianza como para no poner un bloqueo fuerte que impida seguir avanzando. Puede que este anuncio público haya salido después de conversaciones privadas, pero ojalá esto avance bien y sin heridas innecesarias

• La propuesta de una interfaz que permita distintas implementaciones de JIT parece mostrar un gran malentendido sobre lo que necesita un JIT de alto rendimiento. Seguramente la gente que trabaja en JIT tuvo varios problemas, pero uno de los grandes parece haber sido que no pudieron, o no quisieron, cambiar de forma importante las estructuras de datos centrales del runtime
  Claro, Python también tiene el problema de que en la práctica expone toda su implementación como si fuera un API. Aun así, si alguien hace algo indebido, se le puede obligar a reescribir los tipos, pero para eso hace falta una comunidad que realmente le dé mucha importancia al rendimiento. Históricamente, Python ha sobrevivido haciendo que las librerías que necesitan rendimiento no se escriban en Python, y eso influyó en las prioridades. Recuerdo comparaciones antiguas de rendimiento entre lenguajes donde se comparaba una implementación básica del algoritmo con una implementación en Python que en realidad envolvía una versión pulida y de alto rendimiento de una librería en C

  • La propuesta de interfaz para JIT parece inspirada en Ruby, y da la impresión de que ahí funcionó bastante bien. Así que puede que Ruby no tenga un JIT ultrarrápido, pero quizá eso sea suficiente. Creo que mucha gente estaría satisfecha si el JIT de Python funcionara aunque sea al nivel del JIT de Ruby

  • No me queda claro por qué se dice que “la propuesta de una interfaz que permita distintas implementaciones de JIT muestra un gran malentendido sobre lo que necesita un JIT de alto rendimiento”
    Como dices, Python está en una situación donde expone su implementación como si fuera un API, pero por esa misma razón el JIT también está llamando a esos APIs. De hecho, algunas funciones incluso quedaron expuestas al enlazador como símbolos públicos porque el JIT las necesitaba. Personalmente estoy trabajando en un JIT de métodos, no en un JIT de trazado, y he apoyado públicamente la idea de un JIT conectable

• Me pregunto por qué esto se publicó como un anuncio público en lugar de enviarse como una solicitud privada a los desarrolladores principales del JIT

  • Porque Python es un proyecto de código abierto impulsado por la comunidad. Incluso en proyectos privativos se han filtrado anuncios parecidos

• Parece que algún antropólogo debería escribir un libro sobre la burocracia de los proyectos de software de código abierto, y Python y Debian deberían ser casos centrales de estudio
  No lo digo como crítica. Al final, este tipo de burocracia es un proceso de toma de decisiones distribuida y de construcción de consensos, y hacer que funcione bien a esta escala es difícil

  • Gabriella Coleman es una antropóloga que hizo trabajo de campo sobre Debian. El libro que salió de ahí es “Coding Freedom”, y lo recomiendo mucho

• Sinceramente, parece el mismo síndrome que llevó a Python 3, pero con el efecto opuesto. CPython existe sobre todo para el disfrute de quienes lo implementan, y este cambio probablemente les cause una molestia considerable a quienes están acostumbrados a hackearlo de la forma actual
  Quizá la dirección correcta sería apoyar una versión con JIT como una implementación separada, permitirle hacer cambios y que la compatibilidad con el CPython original se busque como mejor esfuerzo

  • No me queda claro qué significa exactamente “el mismo síndrome que llevó a Python 3, pero con el efecto opuesto”
    Y sobre la parte de que “CPython existe sobre todo para el disfrute de quienes lo implementan”, la impresión que me han dejado mis interacciones limitadas con el SC y con desarrolladores principales ha sido más bien la contraria. En general, parecían bastante comprometidos con encontrar un equilibrio razonable entre seguir apoyando a la comunidad existente y al mismo tiempo avanzar hacia adelante