Python se mueve para eliminar GIL y aumentar la concurrencia
La eliminación de GIL elimina un obstáculo importante para los subprocesos múltiples, lo que convierte a Python en un lenguaje verdaderamente multinúcleo.
El consejo directivo de Python tiene intención de hacer una propuesta que supondrá la culminación de muchos intentos a lo largo de los años para eliminar Global Interter Lock (GIL). Esto quitará un obstáculo importante para los subprocesos múltiples, lo que convertirá a Python en un lenguaje multinúcleo y mejorará significativamente su rendimiento para las cargas de trabajo que se benefician del paralelismo.
De este modo, el soporte de primera clase para subprocesos múltiples y concurrencia está un paso más cerca de convertirse en realidad.
¿Por qué eliminar GIL?
El sistema de administración de memoria Python realiza un seguimiento del uso de los objetos manteniendo el recuento de la cantidad de referencias a cada objeto. Cuando el recuento cae a cero, el objeto está programado para su eliminación.
Debido a que Python se creó un momento en el que los sistemas multiprocesadores eran una rareza y los procesadores multinúcleo no existían, este mecanismo de conteo de referencias no es seguro para subprocesos. En cambio, Python logra la seguridad de los subprocesos al permitir que solo uno acceda a un objeto a la vez. Este es el propósito de GIL.
Muchos proyectos han intentado eliminar GIL. Permitieron que los programas de subprocesos múltiples se ejecutaran más rápido, pero a costa de degradar el rendimiento de los programas de un solo subproceso. Dado que la gran mayoría de las aplicaciones de Python son de un solo subproceso, esta fue una mala compensación. Aunque los refinamientos de GIL han mejorado su manejo de aplicaciones de subprocesos múltiples, sigue siendo un cuello de botella serio.
Los principales desarrolladores de Python finalmente decidieron eliminar el GIL de CPython, pero solo si se podía hacer sin ralentizar los programas de subproceso único.
Cómo funcionará Python sin GIL
Las propuestas actuales para una edición sin GIL de Python utilizan una combinación de técnicas para hacer que el conteo de referencias sea seguro para subprocesos y dejar intacta la velocidad de los programas de un solo subproceso o afectarla solo mínimamente.
- Recuento de referencias sesgado. Los recuentos de objetos a los que accede un solo subproceso se manejarían de manera diferente (y más rápidamente) que los recuentos de objetos a los que acceden varios subprocesos. Dado que la mayoría de los objetos son accedidos por un solo subproceso, el impacto en los programas de un solo subproceso se minimiza.
- Inmortalización. Algunos objetos, como None, nunca necesitan desasignarse, por lo que no es necesario realizar un seguimiento de sus recuentos de referencia.
- Asignación de memoria segura para subprocesos. Un nuevo sistema de asignación de memoria para objetos CPython facilitará el seguimiento de objetos en el recolector de elementos no utilizados y la asignación de memoria de manera segura para subprocesos.
- Recuento diferido de referencias. Los recuentos de referencias para algunos objetos, como funciones de nivel superior en un módulo, se pueden diferir de forma segura. Esto ahorra tiempo y recursos.
- Un recolector de basura revisado. El recolector de elementos no utilizados de CPython limpia las referencias de objetos cíclicos, donde dos o más objetos contienen referencias entre sí. La compilación sin GIL realiza muchos cambios en el recolector de basura, como eliminar el sistema de "generaciones" para rastrear objetos.
Los mayores desafíos para eliminar GIL
Los mayores desafíos presentes en este plan no son solo técnicos, aunque los desafíos técnicos son abrumadores. Lo que se cierne aún más es cómo hacer que el resto del ecosistema de Python se ajuste a estos cambios y asegurarse de que un Python sin GIL no cree más problemas de los que resuelve.
Según Wouters, "... cualquier cambio en el código de terceros necesario para acomodar compilaciones sin GIL debería funcionar en compilaciones con GIL (aunque aún será necesario abordar la compatibilidad con versiones anteriores de Python)".
El otro gran desafío, como se mencionó anteriormente, es "traer al resto de la comunidad de Python", dijo Wouters, "... y asegurarnos de que los cambios que queremos hacer, y los cambios que queremos que hagan, sean aceptables. .
“Antes de comprometernos a cambiar por completo a la versión sin GIL, necesitamos ver el apoyo de la comunidad”, dijo Wouters. "No podemos simplemente cambiar el valor predeterminado y esperar que la comunidad descubra qué trabajo deben hacer para respaldarlo".
La comunidad de Python experimentó enormes problemas de crecimiento al hacer la transición de Python 2 a Python 3, por lo que cualquier cambio importante, como eliminar el GIL, tendría que ser completamente compatible con versiones anteriores. Como dijo Wouters, "No queremos otra situación de Python 3".
Más allá de los peligros y desafíos se encuentra una gran recompensa: un Python que finalmente soporta el paralelismo que los programadores esperan en el siglo XXI.
