Hace mucho tiempo que no uso py, así que presta atención~~
"GIL en Python ya no existirá, lo cual es una gran victoria en el campo del ecosistema de inteligencia artificial", dijo con emoción el responsable principal de PyTorch, Dmytro Dzhulgakov.
¿Qué es el GIL? El nombre completo de GIL es Global Interpreter Lock (bloqueo de intérprete global), que no es exclusivo de Python, sino un concepto introducido al implementar CPython (intérprete de Python). Podemos entender a GIL como un mutex, que se usa para proteger objetos en Python y evitar que varios subprocesos ejecuten el código de bytes de Python al mismo tiempo, lo que garantiza la seguridad de los subprocesos. 
Sin embargo, GIL tiene una desventaja, es decir, solo un subproceso puede ejecutarse en una CPU a la vez, y varios subprocesos no se pueden asignar a varias CPU, por lo que Python no puede lograr una verdadera concurrencia de subprocesos múltiples, lo que reduce la eficiencia de ejecución.
Ahora, el equipo de Python ha aceptado oficialmente la propuesta de eliminar el GIL y convertirlo en un modo opcional , lo cual es bueno para los desarrolladores.
Esta contribución la hizo un ingeniero de software en Meta llamado Sam Gross, y le tomó más de cuatro años completar el proyecto.
Después de escuchar la noticia, todos aplaudieron. Yann LeCun, uno de los tres gigantes del aprendizaje profundo, envió un mensaje de felicitación: sin GIL, el código Python ahora puede ejecutar libremente subprocesos múltiples.
"¡Finalmente no más GIL en Python!"
"Esta es una decisión histórica que la comunidad de programación ha esperado ansiosamente".
Para los detalles, veamos a continuación. ¿Qué software es? http://143ai.com
El desarrollador principal de CPython, Thomas Wouters, escribió un artículo que describe los detalles de GIL-free en Python y espera futuros desarrollos.
Muchas gracias por los comentarios de todos sobre la propuesta de no-GIL, el apoyo positivo en general. El Comité Directivo tiene la intención de aceptar la propuesta de no-GIL y compartirá con usted los detalles específicos a continuación.
Nuestras premisas básicas son:
-
A largo plazo (aproximadamente más de 5 años), las compilaciones sin GIL deberían ser las únicas compilaciones;
-
Queremos tener mucho cuidado con la compatibilidad con versiones anteriores. No queremos otra situación de Python 3 en la que los cambios de código de terceros necesarios para adaptarse a las compilaciones sin GIL solo se apliquen a las compilaciones con GIL (aunque aún deben abordarse los problemas de compatibilidad con versiones anteriores de Python). Esto no funciona con Python 4. Todavía estamos considerando los requisitos para la compatibilidad con ABI y otros detalles de estas dos compilaciones, y el impacto en la compatibilidad con versiones anteriores;
-
Necesitamos ver el apoyo de la comunidad antes de comprometernos con un cambio completo a no-GIL. No podemos simplemente cambiar el valor predeterminado, queremos que la comunidad descubra qué deben hacer para admitirlo. Nuestro equipo central de desarrollo necesita adquirir experiencia con el nuevo modo de compilación y todo lo relacionado. Estamos limpiando la seguridad de subprocesos en el código existente, por lo que debemos descubrir la nueva API de C y la API de Python. También debemos transmitir estos conocimientos a otros en la comunidad de Python y asegurarnos de que los cambios que queremos hacer y los cambios que queremos que hagan sean deseables;
-
En cualquier momento antes de nuestra configuración predeterminada sin GIL, nos gustaría poder cambiar de opinión si resulta ser demasiado perjudicial para muy poco beneficio. Esto también significa que revertimos todo nuestro trabajo, por lo que el código específico sin GIL debería ser algo identificable hasta que decidamos hacer que no sea GIL como predeterminado.
Actualmente, vemos el camino por delante en tres fases:
-
A corto plazo, tendremos compilaciones sin GIL como un modo de compilación experimental, probablemente en 3.13 (posiblemente retrasado hasta 3.14). Es experimental porque nuestro equipo central de desarrollo, si bien es compatible con este modo de compilación, no espera que toda la comunidad lo sea. Necesitamos tiempo para decidir qué queremos hacer, al menos en términos de diseño, empaque y distribución de API, para que podamos obtener el apoyo de la comunidad. También desaconsejamos a los distribuidores que lancen compilaciones experimentales sin GIL como intérprete predeterminado.
-
En el mediano plazo, después de que estemos seguros de que tenemos suficiente apoyo de la comunidad para hacer factible el uso de producción sin GIL, admitiremos compilaciones sin GIL, pero no de forma predeterminada, sino en una determinada fecha objetivo o en una determinada versión de Python. usarlo se convierte en la forma predeterminada. El momento exacto dependerá de muchos factores, como qué tan compatibles terminen siendo los cambios de la API, cuánto trabajo cree la comunidad que aún deben hacer, etc. Esperamos que esto tome al menos uno o dos años. Una vez que anunciemos el soporte, espere que algunos distribuidores comiencen a enviar sin GIL de forma predeterminada.
-
A largo plazo, queremos que no-GIL sea el valor predeterminado y eliminar todos los rastros de GIL (pero sin romper innecesariamente la compatibilidad con versiones anteriores). No queremos esperar demasiado, después de todo, la existencia de dos modos de compilación de uso común al mismo tiempo causará una gran carga en la comunidad (como la necesidad de duplicar los recursos de prueba y escenarios de depuración). Pero no podemos precipitarnos demasiado. Creemos que este proceso tomará cinco años.
Por supuesto, durante todo el proceso, todo nuestro equipo de desarrollo deberá evaluar el progreso en tiempo real y hacer ajustes en el cronograma.
Amigos en el área de comentarios, ¿qué opinan de que GIL se vuelva opcional?
Link de referencia:
https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-opcional-en-cpython/30474
https://twitter.com/dzhulgakov/status/1685667015800066048