GIL en Python 3.1

Question

¿Alguien sabe el destino de Global Interpreter Lock en Python 3.1 contra la integración de subprocesos múltiples de C ++

Answer 1

GIL todavía está allí en CPython 3.1; los objetivos del proyecto Unladen Swallow (entre muchos otros aumentos de rendimiento) para eliminarlo, pero todavía está lejos de sus objetivos, y está trabajando en 2.6 primero con la intención de eventualmente portar a 3.x para lo que sea que x esté vigente para cuando se considere que la versión 2.y está hecha. Por ahora, el multiprocesamiento (en lugar de subprocesos) sigue siendo la forma de elección para usar múltiples núcleos en CPython (IronPython y Jython también están bien, pero actualmente no son compatibles con Python 3, ni tampoco hacen que la integración de C ++ sea tan fácil; - ).

Answer 2

Se producirán cambios significativos en el GIL para Python 3.2. Eche un vistazo a las Novedades de Python 3.2 , y el hilo que lo inició en la lista de correo .

Si bien los cambios no significan el final del GIL, anuncian ganancias de rendimiento potencialmente enormes.

Actualización0

• Las ganancias generales de rendimiento con el nuevo GIL en 3.2 de Antoine Pitrou fueron insignificantes y, en cambio, se centraron en mejorar los problemas de contención que surgen en ciertos casos de esquina.
• Se hizo un esfuerzo admirable por David Beazley para implementar un programador para mejorar significativamente el rendimiento cuando CPU e IO los hilos encuadernados se mezclan, lo que desafortunadamente fue derribado.
• El trabajo de Swallow sin carga fue propuesto para fusionarse en Python 3.3, pero esto ha sido retirado debido a la falta de resultados en ese proyecto. PyPy es ahora el proyecto preferido y actualmente es solicitando fondos para agregar soporte para Python3k. Hay muy pocas posibilidades de que PyPy se convierta en el valor predeterminado en este momento.

Se han realizado esfuerzos durante los últimos 15 años para eliminar el GIL de CPython, pero en el futuro previsible está aquí para quedarse.

Answer 3

El GIL no afectará su código que no utiliza objetos de python. En Numpy, lanzamos el GIL para el código computacional (llamadas de álgebra lineal, etc.), y el código subyacente puede usar múltiples subprocesos libremente (de hecho, esas son generalmente bibliotecas de terceros que no saben nada sobre python)

Answer 4

El GIL es algo bueno.

Simplemente haga que su aplicación C ++ libere el GIL mientras realiza su trabajo multiproceso. El código de Python continuará ejecutándose en los otros subprocesos, intactos. Solo adquiera el GIL cuando tenga que tocar objetos de Python.

Answer 5

Supongo que siempre habrá un GIL. La razón es el rendimiento. Hacer que todos los subprocesos de acceso de bajo nivel sean seguros - significa poner un mutex alrededor de cada operación de hash, etc. Recuerde que una declaración simple como

self.foo(self.bar, 3, val)

Puede que ya tenga al menos 3 (si val es una búsqueda global de tablas hash) en este momento y tal vez incluso más si la caché del método no está activa (dependiendo de la profundidad de herencia de la clase)

Es costoso, por eso Java abandonó la idea e introdujo tablas de hash que no utilizan una llamada de monitor para deshacerse de su "Java es lento" marca registrada.

Answer 6

Según tengo entendido, el "brainfuck" el planificador reemplazará el GIL de Python 3.2

Programador BFS Bainfuck

Answer 7

Si el GIL se interpone, simplemente use el módulo multiprocesamiento . Genera nuevos procesos, pero utiliza el modelo de subprocesos y (la mayoría de las) api. En otras palabras, puede hacer paralelismo basado en procesos de forma similar a un hilo.