Python Global intérprete de bloqueo (GIL) solución en sistemas de múltiples núcleos utilizando taskset en Linux?

Question

Así que acabo de terminar de ver esta charla sobre el pitón Global intérprete de bloqueo (GIL) http://blip.tv/ presentar / 2232410 .

El quid de la cuestión es que el GIL es un muy buen diseño para los sistemas de un solo núcleo (Python deja esencialmente el manejo hilo / programación de hasta el sistema operativo). Pero que esto puede ser contraproducente en serio en los sistemas multi-núcleo y se termina con IO hilos intensivos siendo fuertemente bloqueadas por hilos intensivo de CPU, el costo de cambio de contexto, el problema ctrl-C [*] y así sucesivamente.

Así que desde el GIL nos limita a ejecutar básicamente un programa Python en una CPU mi pensamiento es ¿por qué no aceptar esto y simplemente utilizar taskset en Linux para establecer la afinidad del programa para un núcleo determinado / CPU en el sistema (especialmente en una situación con múltiples aplicaciones Python se ejecuta en un sistema multi-core)?

Así que en última instancia, mi pregunta es la siguiente: ¿alguien ha intentado usar taskset en Linux con aplicaciones Python (especialmente cuando se ejecutan múltiples aplicaciones en un sistema Linux para que varios núcleos se pueden utilizar con las aplicaciones de uno o dos Python unidos a un núcleo específico) y Si es así ¿cuáles fueron los resultados? es que vale la pena hacerlo? ¿Tiene cosas peores para ciertas cargas de trabajo? Tengo la intención de hacer esto y probarlo (básicamente ver si el programa tiene más o menos tiempo para correr), pero me encantaría saber de otros en cuanto a sus experiencias.

Además: David Beazley (el individuo que da la charla en el video relacionado) señaló que algunos C / extensiones de C ++ liberan manualmente el bloqueo GIL y si estas extensiones están optimizadas para multi-núcleo (es decir, el análisis de datos científicos o numérico / etc .) a continuación, en lugar de obtener los beneficios de múltiples núcleos de procesamiento de números de la extensión se paralizó con eficacia, ya que se limita a un solo núcleo (por tanto, potencialmente ralentizar su programa de manera significativa). Por otro lado, si usted no está utilizando extensiones como este

La razón por la que no estoy usando el módulo de multiprocesamiento es que (en este caso) parte del programa es en gran medida la red de E / S de la envolvente (peticiones HTTP) para tener un grupo de subprocesos de trabajo es una gran manera de exprimir el rendimiento de una caja desde un hilo dispara una solicitud HTTP y, a continuación, ya que está a la espera de e / S da el GIL y otro hilo puede hacer es cosa, de modo que parte del programa se puede ejecutar fácilmente más de 100 hilos sin perjudicar a la CPU mucho y dejar yo utilizo realmente el ancho de banda de red disponible. En cuanto a sin apilado Python / etc no estoy demasiado interesado en volver a escribir el programa o la sustitución de mi pila de Python (disponibilidad también sería una preocupación).

[*] Sólo el hilo principal puede recibir señales por lo que si se envía un ctrl-C, el intérprete de Python trata básicamente para obtener el hilo principal para ejecutar lo que puede manejar la señal, pero ya que no controla directamente el que el hilo se ejecute (esto se deja al sistema operativo) que básicamente dice al sistema operativo para mantener hilos de conmutación hasta que finalmente golpea el hilo principal (que si tienes la mala suerte puede tomar un tiempo).

Answer 1

Nunca he oído hablar de cualquier persona que utilice taskset para una ganancia de rendimiento con Python. No quiere decir que no puede pasar en su caso, pero definitivamente publicar sus resultados para que otros puedan criticar sus métodos de evaluación comparativa y proporcionar validación.

Personalmente, sin embargo, me desacoplar los hilos de E / S de las roscas con destino CPU utilizando una cola de mensajes. De esa manera su extremo delantero está ahora completamente que la red / S de la envolvente (algunos con interfaz HTTP, algunas de ellas con interfaz de cola de mensajes) y es ideal para su situación roscado. Luego de intensos procesos de la CPU puede utilizar multiproceso o simplemente sean procesos individuales de espera para el trabajo en llegar a la cola de mensajes.

A más largo plazo también puede ser que desee considerar la sustitución de su E / S frontal roscada I con trenzado o algo como eventlets porque, incluso si no van a ayudar al rendimiento que deben mejorar la escalabilidad. Su fondo es ahora ya escalable, ya que puede ejecutar su cola de mensajes a través de cualquier número de máquinas + CPUs según sea necesario.

Answer 2

Otra solución es: http://docs.python.org/library/multiprocessing.html

Nota 1:. Este es no una limitación del lenguaje Python, sino de aplicación CPython

Nota 2: En cuanto a la afinidad, su sistema operativo no debe tener un problema haciendo que el propio

.

Answer 3

Una solución interesante es el experimento reportado por Ryan Kelly en su blog: http://www.rfk.id.au/blog/entry/a-gil-adventure-threading2/

Los resultados parecen muy satisfactorio.

Answer 4

He encontrado la siguiente regla de oro suficiente en los últimos años: Si los trabajadores son dependientes de un estado compartido, utilizo un proceso de multiprocesamiento por núcleo (CPU obligado), y por núcleo un grupo fijo de subprocesos de trabajo (I / S de la envolvente). El sistema operativo se encargará de assigining los diferentes procesos de Python a los núcleos.

Answer 5

El GIL Python es por intérprete Python. Eso significa que el sólo para evitar problemas con él mientras se hace multiprocesamiento es simplemente comenzando múltiples intérpretes (es decir, usando procesos separados en lugar de hilos para la concurrencia) y luego utilizando algún otro IPC primitiva para la comunicación entre los procesos (tales como tomas de corriente). Dicho esto, el GIL no es un problema cuando se usan hilos con el bloqueo de las llamadas de E / S.

El principal problema de la GIL como se mencionó anteriormente es que no se puede ejecutar 2 hilos de código Python diferentes al mismo tiempo. Un hilo de bloqueo en una llamada de E / S de bloqueo se bloquea y por lo tanto no executin código pitón. Esto significa que no está bloqueando el GIL. Si tiene dos tareas intensivas de la CPU en hilos separados pitón, que es donde el GIL mata multi-procesamiento en Python (sólo la aplicación CPython, como se ha señalado anteriormente). Debido a que el GIL detiene CPU # 1 de la ejecución de un hilo pitón mientras CPU # 0 es ocupado ejecutando el otro hilo pitón.

Answer 6

Hasta el momento en que el GIL se elimina de Python, co-rutinas pueden ser utilizados en lugar de roscas. Sé de buena fuente que esta estrategia ha sido implementada por dos exitosas empresas de nueva creación, mediante Verdecillo en al menos un caso.

Answer 7

Esta es una pregunta bastante viejo, pero ya cada vez que la búsqueda Sobre la información relacionada con Python y el rendimiento en sistemas multi-núcleo esta entrada está siempre en la lista de resultados, no dejaría que este pasado ante mí un no comparto mis pensamientos.

Puede utilizar el módulo de multiprocesamiento que en lugar de crear hilos para cada tarea, se crea otro proceso de Compier CPython interpretar el código. Sería hacer su solicitud para tomar ventaja de los sistemas multinúcleo. El único problema que veo en este enfoque es que va a tener una considerable sobrecarga mediante la creación de toda una pila nuevo proceso en la memoria. ( http://en.wikipedia.org/wiki/Thread_(computing)#How_threads_differ_from_processes )

el módulo

multiprocesamiento Python: http://docs.python.org/dev/library/multiprocessing.html

"La razón por la que no estoy usando el módulo de multiprocesamiento es que (en este caso) parte del programa es en gran medida que la red de E / S Bound (peticiones HTTP) para tener un grupo de subprocesos de trabajo es una gran manera de exprimir el rendimiento de una caja ... "

Sobre esto, supongo que se puede tener también una piscina de proceso también: http://docs.python.org/dev/library/multiprocessing.html#using-a-pool-of-workers

Att, Leo