El bloqueo global del intérprete (GIL) parece ser a menudo citado como una de las principales razones por las que el enhebrado y cosas similares son un poco difíciles en Python, lo que plantea la pregunta "¿Por qué se hizo eso en primer lugar?"
Al no ser un programador, no tengo idea de por qué podría ser eso: ¿cuál era la lógica detrás de poner el GIL?
python
multithreading
Fomite
fuente
fuente
Respuestas:
Hay varias implementaciones de Python, por ejemplo, CPython, IronPython, RPython, etc.
Algunos de ellos tienen un GIL, otros no. Por ejemplo, CPython tiene el GIL:
De http://en.wikipedia.org/wiki/Global_Interpreter_Lock
Las aplicaciones escritas en lenguajes de programación con un GIL pueden diseñarse para usar procesos separados para lograr un paralelismo completo, ya que cada proceso tiene su propio intérprete y, a su vez, tiene su propio GIL.
Beneficios de la GIL
Por qué Python (CPython y otros) usa el GIL
En CPython, el bloqueo global del intérprete, o GIL, es un mutex que evita que múltiples hilos nativos ejecuten códigos de bytes Python a la vez. Este bloqueo es necesario principalmente porque la administración de memoria de CPython no es segura para subprocesos.
El GIL es controvertido porque evita que los programas multiproceso de CPython aprovechen al máximo los sistemas multiprocesador en ciertas situaciones. Tenga en cuenta que las operaciones potencialmente bloqueadoras o de larga duración, como E / S, procesamiento de imágenes y procesamiento de números NumPy, ocurren fuera de GIL. Por lo tanto, solo en programas multiproceso que pasan mucho tiempo dentro del GIL, interpretando el código de bytes de CPython, el GIL se convierte en un cuello de botella.
Python tiene un GIL en oposición al bloqueo de grano fino por varias razones:
Es más rápido en el caso de un solo subproceso.
Es más rápido en el caso de subprocesos múltiples para programas vinculados de E / S.
Es más rápido en el caso de subprocesos múltiples para programas vinculados a la CPU que realizan su trabajo intensivo en cómputo en bibliotecas C.
Hace que las extensiones en C sean más fáciles de escribir: no habrá cambio de subprocesos de Python excepto donde permita que ocurra (es decir, entre las macros Py_BEGIN_ALLOW_THREADS y Py_END_ALLOW_THREADS).
Facilita el ajuste de las bibliotecas C No tiene que preocuparse por la seguridad del hilo. Si la biblioteca no es segura para subprocesos, simplemente mantenga el GIL bloqueado mientras lo llama.
El GIL puede ser lanzado por extensiones C. La biblioteca estándar de Python libera el GIL alrededor de cada llamada de bloqueo de E / S. Por lo tanto, el GIL no tiene consecuencias para el rendimiento de los servidores vinculados de E / S. Por lo tanto, puede crear servidores de red en Python utilizando procesos (fork), subprocesos o E / S asíncronas, y el GIL no se interpondrá en su camino.
Las bibliotecas numéricas en C o Fortran se pueden llamar de manera similar con el GIL lanzado. Mientras su extensión C está esperando que se complete un FFT, el intérprete ejecutará otros hilos de Python. Un GIL es, por lo tanto, más fácil y rápido que el bloqueo de grano fino en este caso también. Esto constituye la mayor parte del trabajo numérico. La extensión NumPy libera el GIL siempre que sea posible.
Los hilos suelen ser una mala forma de escribir la mayoría de los programas de servidor. Si la carga es baja, la bifurcación es más fácil. Si la carga es alta, la E / S asíncrona y la programación controlada por eventos (por ejemplo, utilizando el marco Twisted de Python) es mejor. La única excusa para usar hilos es la falta de os.fork en Windows.
El GIL es un problema si, y solo si, está haciendo un trabajo intensivo de CPU en Python puro. Aquí puede obtener un diseño más limpio utilizando procesos y transmisión de mensajes (por ejemplo, mpi4py). También hay un módulo de 'procesamiento' en la tienda de queso Python, que brinda a los procesos la misma interfaz que los subprocesos (es decir, reemplace threading.Thread con Processing.Process).
Los subprocesos se pueden usar para mantener la capacidad de respuesta de una GUI independientemente de la GIL. Si el GIL perjudica su rendimiento (vea la discusión anterior), puede dejar que su hilo genere un proceso y esperar a que termine.
fuente
s/RPython/PyPy/g. @MichaelBorgwardt Dando razones pro GIL es el punto de la pregunta, ¿no? Aunque estaría de acuerdo en que algunos de los contenidos de esta respuesta (es decir, la discusión de alternativas) no viene al caso. Y para bien o para mal, ahora es casi imposible deshacerse del recuento: está profundamente arraigado en toda la API y la base de código; Es casi imposible deshacerse de él sin reescribir la mitad del código y romper todo el código externo.multiprocessingbiblioteca, estándar desde 2.6. Sus grupos de trabajadores son una abstracción súper hábil para algunos tipos simples de paralelismo.En primer lugar: Python no tiene un GIL. Python es un lenguaje de programación. Un lenguaje de programación es un conjunto de reglas y restricciones matemáticas abstractas. No hay nada en la especificación del lenguaje Python que diga que debe haber un GIL.
Hay muchas implementaciones diferentes de Python. Algunos tienen un GIL, otros no.
Una explicación simple para tener un GIL es que escribir código concurrente es difícil. Al colocar un candado gigante alrededor de su código, lo obliga a ejecutarse siempre en serie. ¡Problema resuelto!
En CPython, en particular, un objetivo importante es facilitar la extensión del intérprete con complementos escritos en C. Una vez más, escribir código concurrente es difícil, por lo que al garantizar que no habrá concurrencia, es más fácil escribir extensiones para el interprete. Además, muchas de esas extensiones son solo envoltorios delgados alrededor de las bibliotecas existentes que pueden no haberse escrito teniendo en cuenta la concurrencia.
fuente
¿Cuál es el propósito de un GIL?
La documentación de CAPI tiene esto que decir sobre el tema:
En otras palabras, el GIL previene la corrupción del estado. Los programas de Python nunca deberían producir una falla de segmentación, porque solo se permiten operaciones seguras de memoria. El GIL extiende esta garantía a programas multiproceso.
Cuales son las alternativas?
Si el propósito de la GIL es proteger al estado de la corrupción, entonces una alternativa obvia es asegurar un grano mucho más fino; quizás en un nivel por objeto. El problema con esto es que, aunque se ha demostrado que aumenta el rendimiento de los programas de subprocesos múltiples, como resultado tiene más gastos generales y los programas de subprocesos únicos sufren.
fuente