gh-116167: Permitir deshabilitar el GIL

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

El trabajo sobre PEP 703 para hacer opcional el Global Interpreter Lock (GIL) de Python avanza, con una compilación experimental de CPython que puede construirse para ejecutarse sin el GIL en programas sin hilos. Los comentaristas destacan el potencial de un paralelismo real en varios núcleos y un Python de alto rendimiento más sencillo —especialmente para cargas de trabajo que hoy se ven obligadas a usar multiprocessing o C/C++—, pero señalan roturas actuales (en particular en asyncio y en código con hilos) y una ralentización del 5–15% en el rendimiento de un solo hilo. El cambio se plantea como un cambio incremental a largo plazo que requerirá actualizaciones de extensiones nativas y herramientas, al tiempo que reaviva las comparaciones con alternativas como Go, Rust y Julia para el desarrollo backend tipado y concurrente.

Alcance del cambio / estado actual

  • El cambio proviene del trabajo para hacer que el GIL sea opcional (PEP 703).
  • El PR actual requiere compilar CPython con una bandera especial y luego deshabilitar el GIL mediante un interruptor en tiempo de ejecución.
  • Esto se presenta explícitamente como un paso temprano, en fase de investigación: se espera que funcione de forma fiable solo para programas sin hilos.
  • Las pruebas de asyncio fallan con el GIL deshabilitado; algunos programas simples con hilos “parecen” funcionar, pero no se garantiza que sean seguros.

Rendimiento en un solo hilo vs. múltiples hilos

  • Eliminar el GIL permite un paralelismo real en varios núcleos para Python multihilo, útil para cargas de trabajo con muchos hilos (p. ej., ML, investigación).
  • Para código de un solo hilo, varios comentaristas señalan una penalización de rendimiento por el bloqueo adicional; PEP 703 cita una ralentización del 5–15%.
  • Algunos esperan que más optimizaciones puedan reducir con el tiempo la sobrecarga de las compilaciones nogil para un solo hilo.

Asyncio, hilos y compatibilidad

  • Varios comentarios aclaran: la E/S asíncrona y los hilos del sistema operativo son distintos; las roturas actuales están sobre todo en pruebas de asyncio que mezclan hilos y corrutinas.
  • Hay confusión en el hilo sobre si “cualquier código con hilos” se rompe; el consenso es: muchos patrones de hilos existentes, especialmente los que implican objetos compartidos, no son seguros en esta versión.

Alternativas a los hilos hoy

  • multiprocessing se cita ampliamente como una solución de contorno para tareas limitadas por CPU, pero:
    • En Windows y macOS, la falta de fork / el uso de spawn lo hace lento e incómodo.
    • Grandes huellas de memoria y estructuras de datos compartidas complejas hacen que el paralelismo basado en procesos sea doloroso.
  • Bibliotecas como Ray ayudan con múltiples procesos y memoria compartida, pero tienen sus propias limitaciones (por ejemplo, objetos inmutables centrados en arrays).

Impacto en el ecosistema y las extensiones C

  • La mayoría de las extensiones nativas (C/C++) dependen implícitamente del GIL para la seguridad en hilos (globales, mutaciones no sincronizadas de listas, etc.).
  • El plan es: si una extensión depende del GIL, lo seguirá manteniendo habilitado; a largo plazo, las extensiones deberán actualizarse para ser seguras sin GIL o usar explícitamente el GIL.

Python frente a otros lenguajes y tipado

  • Varios comentaristas sostienen que, si hoy quieres “Python + tipos + concurrencia”, Go, Rust, C#, Kotlin, Julia, Nim o lenguajes BEAM pueden ser mejores opciones.
  • Otros replican que el ecosistema de Python (NumPy, PyTorch, herramientas de ML/DS) domina, y que nogil junto con comprobadores de tipos modernos (p. ej., mypy, pyright) hacen a Python competitivo para muchos casos de uso.
  • Continúa el debate sobre la velocidad de Python y su modelo de tipado frente a lenguajes “modernos”, con el reconocimiento de que Python seguirá siendo más lento, pero aun así puede mejorar de forma significativa.