Proyecto para eliminar el GIL y hacer CPython más rápido

• El Python Steering Council expresó su disposición a aceptar PEP 703, con lo que la eliminación del GIL en CPython entra en un largo proceso gradual: desde builds experimentales hasta un eventual cambio del modo predeterminado
• Quitar el GIL puede abrir el rendimiento multihilo, pero también puede generar costos en el rendimiento de un solo hilo, que domina la mayor parte del ecosistema actual, además de afectar la compatibilidad con extensiones en C
• El equipo de Faster CPython considera que el intérprete adaptativo especializado basado en PEP 659 depende del GIL, por lo que en un entorno sin GIL habrá que recalcular tanto la estrategia de optimización como la carga de mantenimiento
• Meta dijo que, si se acepta PEP 703, invertirá 3 engineer-years hasta finales de 2025, y Anaconda prometió apoyar el trabajo de empaquetado en pip, cibuildwheel y conda-forge
• La transición busca evitar una ruptura como la de Python 2→3, y si se concluye que el caos de no-GIL supera sus beneficios, todavía podría revertirse antes de declararlo como modo predeterminado

---

Se reactiva en serio el debate sobre eliminar el GIL de Python

• El Global Interpreter Lock (GIL) de Python serializa el acceso a la máquina virtual del intérprete para que solo un hilo pueda ejecutar código Python a la vez
• El GIL, que ha impedido aprovechar mejoras de rendimiento con varios hilos, ha sido señalado desde hace tiempo como una debilidad histórica de Python
• En octubre de 2021, Sam Gross presentó una versión de prueba de concepto de Python sin GIL, y tras el interés inicial hubo avances limitados durante más de un año
• Después, el Python Steering Council anunció su disposición a aceptar la funcionalidad no-GIL
  • Aún tomará tiempo que llegue a una versión de lanzamiento real
  • Sigue existiendo la posibilidad de que el trabajo se revierta en algún punto futuro
  • El apoyo de varias empresas aumenta las probabilidades de éxito

La tensión entre Faster CPython y el rendimiento de un solo hilo

• En el Python Language Summit de 2022, Gross presentó el fork no-GIL con la intención de obtener un acuerdo implícito para avanzar, pero no se llegó a consenso porque los efectos detallados no se conocían lo suficiente
• Al mismo tiempo, el proyecto Faster CPython estaba enfocado en mejorar el rendimiento del intérprete en un solo hilo
• Mark Shannon escribió PEP 659, “Specialized Adaptive Interpreter”, y parte de esos cambios llegaron a Python 3.10 y 3.11
• En PyCon, Brandt Bucher, del equipo de Faster CPython, presentó las instrucciones adaptativas, mientras que Shannon expuso mejoras en el layout de memoria y otras técnicas de optimización
• Como la gran mayoría de los programas existentes de Python están escritos para un solo hilo debido al GIL, mejorar el rendimiento de un solo hilo impacta directamente el rendimiento percibido en todo el ecosistema Python

La propuesta PEP 703 y las preocupaciones iniciales

• Łukasz Langa publicó en enero de 2023 la primera versión de PEP 703, escrita por Gross: “Making the Global Interpreter Lock Optional in CPython”
• Junto con la expectativa por no-GIL, surgió como preocupación principal el estado de los módulos de extensión de Python escritos en C
  • El GIL ha servido para evitar varios problemas de concurrencia en código de extensiones en C
  • Quitar el GIL puede introducir nuevos bugs en ese código
• Había consenso en que debía evitarse una transición tipo flag day como la que ocurrió de Python 2 a 3
  • La transición para eliminar el GIL debe funcionar de manera fluida incluso con código que aún no esté listo
• Shannon preguntó qué nivel de degradación de rendimiento sería aceptable en código de un solo hilo; su estimación directa estaba en el rango de 15~20%, y pensaba que podría ser mayor según el impacto sobre PEP 659
• Eric Snow, desde su trabajo en PEP 684 “Per-Interpreter GIL” y PEP 683 “Immortal Objects”, publicó un análisis extenso y consideró que no-GIL y el enfoque de subintérpretes no necesariamente están en conflicto

Costos y beneficios para las extensiones en C

• Gross respondió que el impacto sobre las extensiones en C no sería completamente negativo
• El PEP incluye citas sobre la complejidad que enfrentan los mantenedores de extensiones basadas en la API de C ampliamente usada al intentar esquivar las limitaciones del GIL
• Zachary DeVito, desarrollador principal de PyTorch, comentó que en los últimos meses pasó tres veces más tiempo —por un orden de magnitud— entendiendo cómo rodear las limitaciones del GIL que resolviendo el problema real
• no-GIL puede crear nuevos problemas de concurrencia para quienes mantienen módulos de extensión, pero al mismo tiempo también puede reducir la complejidad necesaria para evitar el GIL

PEP actualizado y debate sobre rendimiento

• A inicios de mayo de 2023, Gross publicó una implementación de PEP 703 basada en una versión de desarrollo de Python 3.12, junto con un PEP actualizado
• El 12 de mayo pidió al Steering Council una decisión sobre el PEP, pero siguieron más discusiones antes de que llegara esa decisión
• El 2 de junio, Shannon evaluó el impacto en rendimiento del PEP y planteó un rango de 11~30%, cifra que desató debate
• Shannon considera que el intérprete adaptativo con especialización depende del GIL, así que si se acepta no-GIL habrá que rediseñar la estrategia de optimización
  • El esfuerzo invertido en rediseño e implementación no podrá dedicarse a trabajo real de optimización
• Langa publicó cifras de benchmark con un impacto mucho menor al estimado por Shannon, y resultados adicionales quedaron más cerca de lo reportado por Gross en el PEP

Lecciones de la transición de Python 2→3

• Guido van Rossum opinó que habría ayudado en la transición si el código de Python 2 y 3 hubiera podido coexistir en el mismo intérprete
• Subrayó que, si se avanza con no-GIL, incluso los módulos de extensión que requieren GIL deberían poder importarse en un intérprete no-GIL sin trabajo adicional
  • El código de aplicación no debería necesitar cambios
  • Los módulos de extensión tampoco deberían requerir modificaciones
• Gregory P. Smith, del Steering Council, dijo que el alcance del impacto de PEP 703 es tan grande que no estaban listos para decidir de inmediato
• Smith reconoció que existe demanda, pero sostuvo que hay que pensar en todo el ecosistema y encontrar una forma de transición que no rompa el mundo
• Gross respondió que posponer la decisión sin criterios claros de aceptación ni calendario en la práctica funciona como un “no”

Las tres opciones que ve el equipo de Faster CPython

• En la discusión “A fast, free threading Python”, Shannon resumió tres caminos posibles hacia adelante
  • Seguir con el plan actual de un intérprete rápido de un solo hilo
  • Apostar por un intérprete free-threading sin GIL con un impacto no conocido, pero no nulo, en el rendimiento de un solo hilo
  • Intentar ambas cosas al mismo tiempo
• Shannon considera que hay que decidir qué limitar entre rendimiento, paralelismo y mutabilidad
  • Lo expresó como algo más cercano a “Performance, parallelism, mutability: pick one to restrict” que a “pick two”
• Advirtió que hacer que Python sea rápido en un entorno free-threading requerirá investigación original, con mayor costo y riesgo
• Su opción preferida era la tercera, pero considera que no se debe elegir solo no-GIL esperando que “alguien” resuelva después los problemas de rendimiento
• van Rossum también opinó que lo mejor sería lograr a la vez free threading y buen rendimiento por hilo, aunque enfatizó que harán falta más recursos

Apoyo empresarial y opinión de los desarrolladores core

• van Rossum dijo que Microsoft seguirá apoyando al equipo de Faster CPython y que su rol no se limita al trabajo de rendimiento de un solo hilo
• Planteó como meta ajustar el trabajo de especialización y optimización al mundo no-GIL para que, al final, no-GIL se convierta en el único modo de build sin degradar el rendimiento de un solo hilo
• Carl Meyer, de Meta, dijo que si se acepta PEP 703, Meta invertirá 3 engineer-years hasta finales de 2025
  • Ingenieros con experiencia interna en CPython colaborarán con el equipo de core devs
  • Integrarán de forma fluida la implementación de PEP 703 en CPython
  • Seguirán mejorando la compatibilidad y el rendimiento de CPython sin GIL
• Stan Seibert, de Anaconda, dijo que apoyará los problemas de empaquetado derivados de la adopción de PEP 703
  • Incluyendo trabajo relacionado con pip, cibuildwheel y conda-forge
  • Incluyendo el trabajo necesario para llevar paquetes compatibles con no-GIL a la comunidad Python
• En una encuesta entre core developers, 87% de 46 personas respondió que Python con free threading debe impulsarse activamente, y 63% de 38 personas dijo estar dispuesto a contribuir al soporte y mantenimiento de Python sin GIL basado en PEP 703

Decisión del Steering Council y transición gradual

• El 28 de julio, Thomas Wouters anunció que el Steering Council decidió aceptar PEP 703, aunque los detalles de esa aceptación todavía estaban en elaboración
• La idea es introducir primero un intérprete no-GIL, detectar qué falta y completar el trabajo necesario antes de que no-GIL pase a ser el valor predeterminado y, finalmente, la única versión
• Se estima que el período de transición será de unos 5 años
• El Council no quiere repetir una situación como la de Python 3 y considera que cualquier cambio en código de terceros necesario para adaptarse al build no-GIL también debe seguir funcionando en builds con GIL
• A corto plazo, se plantea un build experimental sin GIL, posiblemente en Python 3.13
  • Python 3.13 está previsto para octubre de 2024
  • Será un build para que los core developers y otras personas puedan experimentar
• A mediano plazo, no-GIL se convertirá en una opción soportada, pero no predeterminada
  • El momento dependerá en gran medida de qué tan rápido la comunidad adopte y dé soporte al build no-GIL
• A largo plazo, no-GIL se convertirá en el build predeterminado y el GIL se eliminará por completo
  • Debe hacerse de forma que no rompa innecesariamente la compatibilidad hacia atrás

El trabajo aún no termina

• Wouters considera que eliminar el GIL es un esfuerzo mucho mayor que simplemente aceptar un PEP
• Los core developers tendrán que ganar experiencia práctica con Python sin GIL y, a partir de eso, guiar al resto de la comunidad
• En el proceso de ordenar la seguridad de hilos del código existente, podrían necesitarse nuevas API de C y API de Python
• Durante todo el proceso habrá que reevaluar periódicamente el progreso y el calendario
  • No debe convertirse en otra batalla de compatibilidad de 10 años
  • Si PEP 703 parece problemático, debe poder detenerse y buscar otra solución
• Aún queda mucho trabajo de investigación, código, pruebas, experimentación y documentación antes de llegar a un Python solo-no-GIL, y se menciona como ejemplo octubre de 2028, cuando podría llegar Python 3.17

[GN⁺]

Opiniones de Hacker News

• El artículo está bien escrito y resume bien todo el proceso, pero tiende a darle más peso al lado opuesto a eliminar el GIL y a la posibilidad de fracaso
  También hace falta enfatizar suficientemente la otra postura. La calidad del trabajo de Sam Gross es muy alta, y también incorporó mejoras de rendimiento no directamente relacionadas con no-GIL para reducir la pérdida de rendimiento. También se movió muy bien al estilo open source, y mostró paciencia pese a que la respuesta fue lenta al punto de que, si no hubiera habido presión de la comunidad, el comité directivo lo habría dejado guardado por más tiempo. Los subintérpretes todavía casi no han demostrado utilidad en Python, especialmente con métricas serias, y esto se acerca al primer intento bien definido y medido. La reacción de la comunidad también mostró mucho interés en este proyecto, y el comité directivo concluyó que “tiene intención de aceptar la PEP 703 y está ajustando las condiciones detalladas de aceptación”. No soy un partidario ferviente de no-GIL, me parece bien si al final no se elimina y creo que primero habría que probar los subintérpretes, pero hay que verlo con justicia

  • Del lado de los subintérpretes también hay mucho trabajo en curso, y el GIL por intérprete entró en Python 3.12
    Los resultados también son bastante impresionantes: https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. Parece haber salido tan bien como se podía esperar. El trabajo en subintérpretes probablemente avance en paralelo con el trabajo de free-threading, y ambos tienen casos de uso distintos
  • Lo que personalmente más me molesta en Python es PEP 582, “Python local packages directory”: https://peps.python.org/pep-0582/
    Tengo entendido que PDM todavía lo soporta. No me gusta usar virtualenv para build y distribución, y me gustaría que Python pudiera comportarse como JavaScript. Ya quedó demostrado que es posible. El hilo de discusión está en https://discuss.python.org/t/pep-582-python-local-packages-d.... También es frustrante que “exactamente una forma correcta” se use como motivo de rechazo, porque nunca sentí que eso fuera cierto en Python
  • Quisiera ver solo los parches de rendimiento, sin la parte de no-GIL
  • Me da curiosidad por qué la gente se opone a eliminar el GIL

• Es un excelente artículo de LWN y valió mucho la pena leerlo. Cuando se publicó por primera vez NoGIL de Sam Gross me entusiasmé, pero después de leer el artículo y repasar mi experiencia personal empecé a cambiar de opinión
  He construido sistemas backend en varios lenguajes y, en general, solo eran de dos tipos. Uno abre endpoints de red, recibe solicitudes, hace cálculos y otras solicitudes de red, y luego responde; el otro lee mensajes de una cola, una base de datos, el polling de otra API, etc., hace cálculos y llamadas de red, y luego los envía a otra cola. En el primer caso importa la latencia, y en el segundo el throughput. En el primer tipo, NoGIL es útil porque quieres lanzar hilos según la solicitud, que un endpoint con cálculo pesado no bloquee otras solicitudes y compartir el pool de conexiones a la base de datos. En el segundo tipo, incluso en lenguajes sin GIL casi no recuerdo haber usado paralelismo o concurrencia dentro del proceso con recursos compartidos, porque se vuelve demasiado difícil de entender. La optimización normalmente era batching inteligente, y el paralelismo consistía en levantar varios procesos independientes en varias máquinas. Si por NoGIL se comprometiera la calidad de los sistemas del segundo tipo, me decepcionaría bastante, y de hecho ahora la mayor parte de mi energía mental está puesta en mejorar ese segundo tipo

  • En el caso de mi aplicación Captain’s Log, no-GIL también es interesante en una aplicación GUI
    Actualmente implemento JournalParser con QThread; este parser lee continuamente eventos del juego desde los archivos de diario del jugador generados por Elite: Dangerous y Odyssey, y por cada evento emite una QSignal personalizada para que la procese el slot que escucha esa señal. En otras partes de la aplicación, no tener GIL también podría ser bastante útil. https://captainslog.scarygliders.net/captains-log-2/
  • Como alguien que usa Python por hobby, no creo que vaya a usar concurrencia directamente, pero con el tiempo es muy probable que la biblioteca estándar y las bibliotecas externas populares la aprovechen
    Entonces el código de todos podría mejorar
  • No hace falta usar paralelismo directamente para obtener los beneficios de NoGIL. Por ejemplo, un servidor web o un ejecutor de tareas asíncronas podría compartir contexto entre hilos de manera más eficiente
  • El GIL se vuelve un cuello de botella en aplicaciones ligadas a CPU, como machine learning, así que es natural que NoGIL no resulte tan interesante para quienes escriben aplicaciones de servidor
    Claro que también se podría decir que, para empezar, no deberías escribir programas centrados en CPU en Python, pero esa es otra discusión
  • Estoy construyendo justamente un sistema así ahora, y tuve que abandonar la estrategia multiproceso porque hay un gran recurso compartido
    Si el recurso compartido es de solo lectura, no veo muy bien por qué sería confuso

• Me resulta dudosa la afirmación del hilo enlazado de que “es muy poco probable que eliminar el GIL rompa bases de código escritas solo en Python”
  Parte del código Python multihilo puede esperar que ciertas operaciones sean implícitamente thread-safe gracias al GIL. Por ejemplo, si dos hilos agregan elementos a la misma lista y la lista no se corrompe, es porque el GIL impide que ambos hilos ejecuten esa operación en paralelo. Si se elimina el GIL, este tipo de código podría empezar a ser castigado de golpe, como cuando se modifica un std::vector simultáneamente en C++. No estoy seguro, pero esa frase me parece sospechosa. https://discuss.python.org/t/pep-703-making-the-global-inter...

  • Correcto. Esa es un área que el GIL protegía de manera trivial. En Go hay un caso similar: modificar el mismo map simultáneamente provoca un panic
    La sección de seguridad de hilos en contenedores de PEP 703 trata este problema. Propone poner un bloqueo ligero por objeto en cada list, dictionary y set; todas las operaciones que modifican el objeto deben tomar ese bloqueo, y la mayoría de las operaciones de lectura también deberían tomarlo. Hay más detalles en https://peps.python.org/pep-0703/#container-thread-safety
  • En efecto, y no parece haber muchas soluciones claras aparte de proteger todas las operaciones de las estructuras de datos incorporadas con mutex, como las estructuras de datos iniciales de Java, Hashtable y Vector
    Aunque entonces queda la pregunta de qué hacer cuando se necesita un [] no sincronizado
  • Probablemente el append de listas quede protegido con un bloqueo por instancia. Al menos así está en parte del código conceptual de nogil
  • Como solución ingenua, quizá bastaría con tener un flag que active el GIL por defecto y que, al desactivarlo, muestre una advertencia

• Es difícil imaginar una prueba más dura que esta en open source
  La decisión en sí es razonable. Avanzar en modo de prueba, tratar los múltiples intérpretes como un experimento intermedio, pero fijar como objetivo un Python capaz de ejecución concurrente. Aun así, la restricción de ejecutar código existente y código nuevo en la misma máquina virtual es enorme. Sorprende que el resumen de LWN casi no haya tratado las pruebas: todavía son un tema bastante sin resolver y podrían derivar en releases con bugs desconocidos pero graves. Microsoft, Facebook/Meta y Conda están aportando recursos, y una mayoría abrumadora de los contribuidores principales quiere avanzar, pero no está claro qué pasará cuando el trabajo se vuelva más difícil y se necesite más gente. Al mismo tiempo, enormes proyectos de la academia y la industria, desde sitios web hasta big data e IA, dependen de Python, y el costo trasladado a los desarrolladores de Python podría medirse como proporción del PIB. Ni siquiera parece que los problemas estén identificados todavía, así que convendría concentrarse en el enfoque de Faster CPython, con mejoras predecibles durante los próximos 3 años o más, mientras los defensores de un Python concurrente van más allá de un prototipo simple y analizan qué problemas pueden surgir, cómo detectarlos y qué se puede hacer. Sería más justo que personas con experiencia en demostrar garantías de concurrencia lo revisen, que al menos se identifiquen las incógnitas, y recién entonces se eleven las preguntas al comité directivo. En open source no ha habido muchas decisiones con escala de gestión de programas; ha habido muchas decisiones relativamente simples que empujan la dirección del mercado, como Apache, Eclipse o Linux, pero esta vez hay verdaderas incógnitas técnicas. Al mismo tiempo, siento que también habría que abordar la ABI entre lenguajes. El gran problema es alinearse con el modelo de ejecución que espera C; la interfaz de funciones externas y memoria de Java lleva años en incubación, y Swift también está mejorando el wrapping de C y C++, pero las FFI son notoriamente difíciles, y probablemente de manera innecesaria

  • Si el costo trasladado a los desarrolladores de Python puede medirse como proporción del PIB, los beneficios también

• Personalmente, creo que eliminar el GIL es un error. No hay muchas aplicaciones que se vayan a beneficiar mucho, y la mayoría recibirá una penalización de rendimiento
  Este trabajo consumirá años de atención y esfuerzo que, creo, podrían haberse usado de forma más inteligente. Python parece tener ansiedad o complejo de inferioridad respecto del GIL. Me parece mejor aceptar por completo un modelo de un solo hilo, como JavaScript. Algunas aplicaciones seguirán siendo difíciles o imposibles, pero no creo que Python sea una buena opción para apps que necesitan alto rendimiento o gran escalabilidad. Estar algo especializado y no cubrir todos los casos de uso no es necesariamente malo

  • Ya es demasiado tarde para limitar artificialmente el alcance de Python de esa manera. Ya se usa mucho en ciencia de datos y machine learning
    La gente necesita rendimiento en trabajos que ya está haciendo hoy con Python. No podemos volver a la época en que eso no era cierto. Ahora es uno de los casos de uso más comunes de Python, y la gente está apostando su carrera a esto
  • La PEP aborda en detalle la motivación y los límites del modelo de un solo hilo: https://peps.python.org/pep-0703/#motivation
    La gente ya está intentando hacer trabajo paralelo con Python. Forzarla a usar otros lenguajes no ayuda mucho
  • En una época en la que los multiprocesadores son comunes desde hace más de 10 años, ya es hora de aceptarlo. Más aún si, gracias a excelentes ingenieros de intérpretes, el costo es casi nulo o bajo; personalmente, lo celebro
  • Hubiera sido bueno tener soporte para Unicode desde el principio, pero ya no hay nada que hacer. Me alegra que se encarguen de esto
  • Siempre pensé que un JIT potente, compatible con Cython y con grandes proyectos de extensiones en C como numpy y scipy, sería un esfuerzo más valioso
    Muchas tareas intensivas en datos pueden ejecutarse fácilmente desde Python en procesos paralelos, así que no tengo claro que eliminar el GIL aporte un beneficio tan grande

• El rendimiento de un solo hilo debería tener más prioridad porque es mucho más difícil mejorarlo metiéndole más dinero
  El rendimiento multihilo puede compensar la sobrecarga de la paralelización basada en procesos agregando un núcleo más. Creo que la dicotomía GIL vs. no-GIL en sí está mal planteada. El mayor problema de multiprocessing es que no se puede compartir memoria. Por lo tanto, bastaría con agregar procesos virtuales con un mecanismo explícito de memoria compartida. Así los objetos permanecen en un solo hilo, y se pueden mantener optimizaciones de un solo hilo como el conteo de referencias sin barreras.

  • El error aquí está en asumir que esto es un trade-off inevitable
    Se puede lograr buen rendimiento de un solo hilo incluso sin GIL. Rust tiene el concepto de abstracciones sin costo y también maneja bien los hilos. Java también funciona bien en tareas de un solo hilo. Hay muchos otros lenguajes; no es ciencia ficción. Los locks pueden desaparecer mediante optimización, también se puede elegir código directamente sin locks, y es posible la concurrencia fina o estructurada. Qué cosas son thread-safe es, básicamente, un contrato de API. También existe el locking optimista. No hay una buena razón para que Python no pueda hacer algo similar, pero primero hay que eliminar el GIL. La pérdida de rendimiento de Python sin GIL se parece en gran medida a deuda técnica no resuelta y puede corregirse con el tiempo. Meter muchos locks es un parche y lo vuelve más lento, pero la solución correcta probablemente sea repensar el funcionamiento interno o contar con contratos de API que documenten si algo es thread-safe. Un runtime y un compilador de Python más rápidos también podrían permitir reimplementar en Python muchas cosas que hoy dependen de bibliotecas nativas. La interacción con código nativo es precisamente donde más se necesitan locks, y si no se cambia esa forma de trabajar seguirá siendo un problema. La clave de eliminar el GIL está en encontrar y corregir sistemáticamente estas cosas, y mejorará con el tiempo.
  • Estoy de acuerdo. Si hoy necesitas concurrencia, probablemente ya migraste a multiprocessing, así que el multithreading no-GIL sirve de poco
    El único problema de Python/multiprocessing es que a veces se necesita estado mutable compartido, no una cola. La forma actual de poner objetos de Python en memoria compartida es compleja, limitada e ineficiente. Eso es lo que habría que corregir, y Python necesita mejor soporte para ubicar instancias nativas en memoria compartida.

• Ante la pregunta de “cuánta pérdida de rendimiento en código de un solo hilo sería aceptable”, Shannon estimó alrededor de 15–20%, pero la pregunta en general quedó sin respuesta
  O sea, ¿algunas de las personas del proyecto que está haciendo “CPython más rápido” consideran aceptable volver 15–20% más lento, de la noche a la mañana, a la mayoría del código Python existente? Creo que el límite sería como mucho 5%. Y aun eso solo si eliminar el GIL ayuda a otras optimizaciones futuras. Pero, según dicen, ese cambio más bien complica y retrasa otras optimizaciones. Por otro lado, en 2020 Shannon hizo una propuesta personal de financiamiento para acelerar CPython 5 veces, y ahora todo un equipo con mucho más respaldo corporativo está trabajando en hacer más rápido CPython, pero el objetivo parece mucho más pequeño.

  • Quizás para alrededor del 99% del código Python actual, el alto rendimiento del código Python puro no sea la preocupación principal
    Cuando el rendimiento realmente importa, obtener una mejora de unas 20 veces sin tener que reescribir en otro lenguaje sí es significativo.
  • Algunas mejoras recientes de rendimiento vinieron del bando no-GIL, que quería mostrar que aún hay mucho margen de mejora incluso eliminando el GIL
    Si otras optimizaciones no se detienen, sino que solo tardan un poco más, podría ser aceptable.
  • Creo que el proyecto Faster CPython está demasiado inflado
    Si comparas código real con operaciones numéricas y de strings, sin acceso a red ni disco, la beta de 3.12 solo tarda alrededor de 20–25% menos que 3.8. Eso está al nivel de 2.7. Parece que figuras centrales de larga data están buscando desesperadamente funciones tipo bullet point para mostrarles a los patrocinadores corporativos en el próximo release. Por eso usan el trabajo de Sam Gross, pero con el tiempo probablemente se irán apropiando del mérito poco a poco.

• Excelente resumen, muy al estilo de LWN
  Me gusta la comunidad de Python. Es un caso líder de software open source y muestra lo que pueden lograr la transparencia y la buena gobernanza. Se agradecen las horas de ingeniería que aportan Meta, Microsoft y otros, pero siguen siendo demasiado modestas comparadas con el valor que toda la industria tecnológica y ámbitos más amplios, incluida la ciencia de datos, obtienen de Python y del software open source.

  • Cada quien puede cambiar eso dentro de su propia organización
    Hace 8 años, en JPMorgan, convencí al equipo de liderazgo tecnológico de patrocinar PyCon UK, montar un stand de reclutamiento y apoyar la asistencia de desarrolladores junior de JPMorgan de todo el Reino Unido. Dejé JPM hace 5 años, pero todavía son el patrocinador principal de PyCon UK. Comparado con los enormes beneficios obtenidos del ecosistema de Python y open source, era un costo absolutamente insignificante.
  • Creo que solo fingen ser transparentes; las decisiones reales se toman todas a puerta cerrada
    Las listas de correo se censuran, y el círculo interno no puede ser criticado. Los verdaderos contribuidores son explotados por personas que pertenecen a las empresas correctas, hacen poco y aun así ocupan puestos de autoridad administrativa. No hay que dejarse engañar: los artículos de LWN son muy favorables y siempre mencionan bien los nombres de quienes toman las decisiones. Me parece más bien una cobertura selectiva.

• La forma en que Sam Gross lo impulsó es bastante impresionante. Después de recibir una respuesta positiva pero sin compromiso claro del comité directivo, podría haberse quedado sentado esperando avances, pero el hecho de que se opusiera y presionara merece mucho reconocimiento.

• Muy interesante. Que Sam Gross haya dicho “no necesitamos un sí/no ahora mismo, pero sí necesitamos saber cómo se vería una aceptación, y este tema lleva demasiado tiempo abandonado” fue un movimiento muy audaz: https://github.com/python/steering-council/issues/188#issuec...
  Esa interacción podría haber tomado varios rumbos, pero creo que fue exactamente el estímulo que necesitaba el comité directivo. El camino hacia Python sin GIL sigue siendo largo y sinuoso, y probablemente requiera una cantidad de trabajo de dos dígitos en años-ingeniero, pero al menos parece que ya hay una ruta adecuada. La parte más difícil es garantizar la corrección del código base existente. Una cosa es decir que no se quiere repetir el paso de Python 2 a 3, y otra muy distinta es que, aunque se afirme que no habrá cambios incompatibles, en la práctica la gente evite actualizar por miedo a los bugs. Incluso dejar GIL/no-GIL solo como un switch en tiempo de compilación sin duda aumentará el costo de mantenimiento. Aun así, creo que a largo plazo este esfuerzo valdrá la pena. El GIL es una especie de pararrayos para las críticas a Python, como se ve en cualquier hilo de HN sobre Python y el paralelismo. Probablemente porque es algo que la gente puede señalar directamente y decir “esta es la razón por la que Python no puede ser más rápido”, sin entender décadas de contexto. En ese sentido, es casi como el jefe final de la valla de Chesterton

  • No lo veo tan optimista. La decisión del comité directivo parece indecisa
    Incluso bajo las nuevas directrices, sigue existiendo la posibilidad de que el esfuerzo de varios años para eliminar el GIL termine siendo rechazado