La eliminación de GIL, Python se convierte en un lenguaje verdaderamente multinúcleo y se elimina una barrera importante para los subprocesos múltiples.
La junta directiva de Python planea presentar una propuesta que será el resultado de numerosos intentos realizados a lo largo de los años para deshacerse del Global Global Interpreter Lock (GIL). Debido a la eliminación de una barrera importante para los subprocesos múltiples, Python se convertirá en un lenguaje multinúcleo y verá un aumento significativo en el rendimiento para cargas de trabajo que se benefician del paralelismo.
Por lo tanto, el soporte de simultaneidad y subprocesos múltiples de primera clase está un paso más cerca de convertirse en realidad.
▶ OpenAI adquiere ‘startup’ Global Illumination
¿Eliminación de GIL, por qué?
Al realizar un seguimiento de cuántas veces se hace referencia a cada objeto, el sistema de administración de memoria de Python monitorea el uso de los objetos. El objeto está configurado para eliminarse cuando el recuento llegue a cero.
Python se desarrolló en una época en la que los sistemas multiprocesador eran poco comunes y los procesadores multinúcleo no existían, por lo que este mecanismo de recuento de referencias no es seguro para subprocesos. En cambio, Python logra la seguridad de los subprocesos al limitar el acceso simultáneo a un objeto a un solo subproceso. Esto es lo que GIL pretende lograr.
Numerosos proyectos han intentado deshacerse de GIL. Sin embargo, se produjeron a expensas del rendimiento de los programas de un solo subproceso, lo que permitió que los programas de múltiples subprocesos se ejecutaran más rápidamente. Esta fue una mala compensación porque las aplicaciones Python de un solo subproceso constituyen la gran mayoría del lenguaje. Aunque GIL se ha mejorado para manejar mejor aplicaciones multiproceso, todavía representa un cuello de botella importante.
Al final, los principales desarrolladores de Python decidieron eliminar el GIL de CPython, pero sólo si se podía hacer sin afectar el rendimiento de los programas de un solo subproceso.
Cómo funcionará Python sin GIL
El recuento de referencias se hace seguro para subprocesos utilizando una combinación de métodos en las propuestas actuales para una versión de Python sin GIL, preservando o apenas afectando la velocidad de los programas de un solo subproceso.
- Recuento de referencias sesgado. El manejo de recuentos de objetos a los que accede un solo subproceso diferiría del manejo (y la velocidad) de recuentos de objetos a los que acceden varios subprocesos. El impacto en los programas de un solo subproceso es mínimo porque un solo subproceso accede a la mayoría de los objetos.
- Inmortalización. Hay algunos objetos, como Ninguno, que nunca necesitan ser desasignados, por lo que no es necesario realizar un seguimiento de sus recuentos de referencias.
- Asignación de memoria que sea segura para subprocesos. Será más sencillo rastrear objetos en el recolector de basura gracias a un nuevo sistema de asignación de memoria para objetos CPython. utilizado y asignación de memoria de forma segura para subprocesos.
- Recuento de referencias a posteriori. Los recuentos de referencias de algunos objetos se pueden retrasar de forma segura, como las funciones del módulo de nivel superior. También conserva los recursos.
- Un nuevo recolector de basura. Las referencias cíclicas a objetos, en las que dos o más objetos contienen referencias entre sí, son eliminadas por la basura de CPython. coleccionista. El recolector de basura sufre numerosas modificaciones con la compilación sin GIL, incluida la eliminación del sistema de «compilaciones» para el seguimiento de objetos.
Los mayores obstáculos para eliminar GIL
Aunque las dificultades técnicas de este plan son formidables, no son los mayores obstáculos. Cómo adaptar el ecosistema Python en su conjunto a estos cambios y asegurarse de que un Python sin GIL no produzca más problemas de los que resuelve se perfila como un desafío aún mayor.
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)».
Traer al resto de la comunidad Python es el otro desafío importante, como se mencionó anteriormente, según Wouters. asegurar que los cambios que queremos hacer y los cambios que queremos que ellos hagan sean apropiados.
- Entrevista a Darío Ferreira, Líder de Ventas para la región Sur de Thermo King
- Pruebas de Penetración y Análisis de Vulnerabilidades: Fortalece la seguridad de tu empresa
- Activo Digital: Guía completa para comprender su significado, tipos y ejemplos
- Que es un DRP: El Plan de Recuperación ante Desastres (DRP)
- Ejemplos de Business Intelligence: Cómo tomar decisiones estratégicas con datos
“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».
Un Python que finalmente respalde el paralelismo que exigen los programadores en el siglo XXI es una gran recompensa que se encuentra más allá de los peligros y dificultades.
