Listo el experimento de CPython sin GIL

• CPython sin GIL es un gran cambio que permite ejecutar varios hilos en paralelo dentro del mismo intérprete
• Se ofrece como una función experimental en CPython 3.13
• Gracias a PEP 703, ahora puede ejecutarse con el GIL desactivado
• Es importante para mejorar el rendimiento, especialmente el rendimiento multihilo
• Permite aprovechar eficazmente varios núcleos de CPU

Suena genial, pero ¿cuáles son los problemas?

• Implementar el modo sin GIL en el propio CPython requiere un gran esfuerzo
• Hay dos problemas principales: seguridad de hilos y compatibilidad ABI
  • Seguridad de hilos: el código Python puro funciona sin cambios, pero el código escrito en otros lenguajes o que usa la API C de CPython puede no hacerlo
  • Compatibilidad ABI: el intérprete sin GIL tiene una ABI distinta, por lo que cada paquete con módulos de extensión debe compilar ruedas adicionales
• Los problemas de seguridad de hilos son difíciles de entender, mejorar y probar
• Ejemplos: fallas intermitentes en numpy#26690, pywavelets#758, etc.

Planes a futuro y trabajo del equipo

• Harán falta varios años para que CPython sin GIL se convierta en la opción predeterminada
• Se espera que en Python 3.13 muchos proyectos trabajen en la compatibilidad y publiquen ruedas cp313t en PyPI
• El equipo comenzó hace meses a trabajar desde la base del stack PyData
• Para cada paquete usan un enfoque similar:
  1. Agregar el primer trabajo de CI
  2. Corregir problemas de seguridad de hilos y de estado compartido/global
  3. Agregar soporte para el modo sin GIL a los trabajos de CI de compilación de ruedas
  4. Hacer pruebas de estrés localmente y monitorear los trabajos de CI
  5. Marcar los módulos de extensión para que puedan ejecutarse sin GIL
  6. Pasar al siguiente paquete

Resumen de GN⁺

• CPython sin GIL es un cambio importante que puede mejorar mucho el rendimiento multihilo
• Resolver los problemas de seguridad de hilos y compatibilidad ABI es el desafío principal
• Se espera que en Python 3.13 muchos proyectos puedan trabajar en la compatibilidad y experimentar
• Paquetes importantes como PyTorch y muchos paquetes pequeños tendrán que adoptar este cambio
• Entre los proyectos relacionados están PyO3 y PyTorch

[GN⁺]

Opiniones en Hacker News

• La eliminación del GIL de Python crea una oportunidad para que muchas organizaciones y proyectos mejoren mucho el rendimiento casi sin esfuerzo adicional

  • Si las bibliotecas antiguas no reflejan este cambio a tiempo, es posible que proyectos nuevos ganen cuota de mercado
  • Se podrá evitar la complejidad y los bugs del multiprocesamiento y usar hilos simples para aprovechar todos los núcleos de máquinas grandes

• Comparte su experiencia instalando y haciendo funcionar Python sin GIL en macOS

  • Escribió un script corto que explica el proceso de instalación y las diferencias
  • Enlace

• Un usuario al que le gusta lo fácil que es escribir en Python y su lógica espera que el enfoque sin GIL sea similar a la forma actual de escribir Python

  • Menciona que no profundizó en multithreading porque es difícil

• Resume el progreso de Python 3

  • [x] Async
  • [x] Tipado estático opcional
  • [x] Threading
  • [ ] JIT
  • [ ] Gestión eficiente de dependencias

• Recuerda que alrededor de 2007 el procesamiento en paralelo se volvió indispensable

  • Menciona que Rust está sacando ventaja en velocidad y procesamiento en paralelo

• En PEP703 se explica cómo la operación append de las listas mantiene la seguridad de hilos después de eliminar el GIL

  • Se agregó un bloqueo por lista
  • Menciona que una operación simple de incremento de enteros actualmente es thread-safe gracias al GIL

• Espera con interés cómo la eliminación del GIL cambiará la naturaleza del entrenamiento y la inferencia de ML

  • Puede reducir la complejidad de pasar memoria y coordinar procesos
  • Espera que bibliotecas como PyTorch puedan optimizarse

• Le preocupa que programadores que nunca han trabajado con multithreading real introduzcan nuevos bugs sutiles

• Plantea la pregunta de si la caída de rendimiento en un solo hilo es grave

  • No pudo encontrar benchmarks y solo se ofrecen mensajes tranquilizadores generales

• Expresa curiosidad sobre cómo funcionará con async

  • Existe una barrera natural entre el código I/O-bound y CPU-bound
  • Quiere ver un modelo más flexible
  • Se pregunta si será posible hacer "gather" en corutinas CPU-bound con JIT
  • Cree que sería genial un modelo de programación flexible que permita cambiar rápido con una interfaz similar