Un amigo confiable del programador me dijo que la implementación actual de múltiples subprocesos de Python tiene errores graves, lo suficiente como para evitar el uso por completo. ¿Qué puede decir sobre este rumor?¿Los subprocesos de Python tienen errores?
Los subprocesos de Python son buenos para programación simultánea de E/S. Los subprocesos se intercambian fuera de la CPU tan pronto como bloquean esperando la entrada de un archivo, red, etc. Esto permite que otros subprocesos de Python usen la CPU mientras que otros esperan. Esto le permitiría escribir un servidor web multiproceso o un rastreador web, por ejemplo.
Sin embargo, los hilos de Python son serializados por GIL cuando ingresan al núcleo del intérprete. Esto significa que si dos hilos están machacando números, solo uno puede ejecutarse en cualquier momento dado. También significa que no puede aprovechar las arquitecturas multi-core o multiprocesador.
Existen soluciones como ejecutar varios intérpretes de Python al mismo tiempo, utilizando una biblioteca de subprocesamiento basada en C. Esto no es para los débiles de corazón y los beneficios pueden no valer la pena. Esperemos una solución de Python en una versión futura.
La solución hoy en día es usar el módulo de multiprocesamiento. – nosklo
Los hilos de Python son ciertamente hilos de CPU REALES. – zweiterlinde
No sé qué significa "subprocesos de CPU", pero los subprocesos de Python * son * subprocesos de sistema operativo. – tzot
Lo he usado en varias aplicaciones y nunca he escuchado que el enhebrado sea otra cosa que no sea 100% confiable, siempre y cuando conozca sus límites. No puede generar 1000 hilos al mismo tiempo y espera que su programa se ejecute correctamente en Windows, sin embargo, puede escribir fácilmente un grupo de trabajadores y solo alimentarlo con 1000 operaciones, y mantener todo agradable y bajo control.
Por lo que sé, no hay errores reales, pero el rendimiento cuando se enhebra en cPython es realmente malo (en comparación con la mayoría de las implementaciones de subprocesamiento, pero suele ser suficiente si la mayoría de los subprocesos se bloquean) debido a la (bloqueo de intérprete global), así que realmente es específico de la implementación en lugar de específico del idioma. Jython, por ejemplo, no sufre esto debido al uso del modelo de subproceso de Java.
Ver this post sobre por qué no es realmente viable para eliminar el GIL de la aplicación CPython y this para una elaboración práctica y soluciones.
Haz un Google rápido para "Python GIL" para obtener más información.
No sé si diría que el enhebrado de python es ineficaz. Es solo que no puedes aprovechar las máquinas multinúcleo. –
Lo haría, y esta charla está de acuerdo conmigo, y proporciona abundantes ejemplos: http://blip.tv/file/2232410 En la mayoría de los casos, no importará sin embargo. Aún así, mira la charla, ¡es genial! –
GIL (Global Interpreter Lock) podría ser un problema, pero la API está bastante bien. Pruebe el excelente módulo processing, que implementa la API Threading para procesos separados. Estoy usando eso en este momento (aunque en OS X, aún tengo que hacer algunas pruebas en Windows) y estoy realmente impresionado. ¡La clase Queue realmente está salvando mi tocino en términos de administración de complejidad!
EDIT: parece que el módulo de procesamiento se está incluyendo en la biblioteca estándar a partir de la versión 2.6 (import multiprocessing). ¡Alegría!
La implementación estándar de Python (generalmente conocida como CPython como está escrita en C) usa subprocesos del sistema operativo, pero como existe Global Interpreter Lock, solo se permite ejecutar un subproceso a la vez en el código de Python. Pero dentro de esas limitaciones, las bibliotecas de threading son robustas y ampliamente utilizadas.
Si desea poder utilizar múltiples núcleos de CPU, existen algunas opciones. Una es usar múltiples intérpretes de Python concurrentemente, como lo mencionaron otros. Otra opción es usar una implementación diferente de Python que no use un GIL. Las dos opciones principales son Jython y IronPython.
Jython está escrito en Java, y ahora está bastante maduro, aunque persisten algunas incompatibilidades. Por ejemplo, el marco web Django does not run perfectly yet, pero se está acercando todo el tiempo. Jython es great for thread safety, sale better in benchmarks y tiene un cheeky message for those wanting the GIL.
IronPython usa .NET framework y está escrito en C#. La compatibilidad está llegando a la etapa donde Django can run on IronPython (al menos como una demostración) y hay guides to using threads in IronPython.
CPython no usa Green Threads. Utiliza subprocesos nativos del sistema operativo, pero el bloqueo de intérprete global significa que se comportan de manera similar a los subprocesos verdes (ya que solo un subproceso se puede ejecutar a la vez). –
Secundado. CPython no usa hilos verdes. –
Si desea codificar en python y obtener una excelente compatibilidad con threading, es posible que desee comprobar IronPython o Jython. Dado que el código python en IronPython y Jython se ejecuta en .NET CLR y Java VM, respectivamente, disfrutan del excelente soporte de subprocesamiento integrado en esas bibliotecas. Además de eso, IronPython no tiene el GIL, un problema que evita que los hilos CPython aprovechen al máximo las arquitecturas multi-core.
Nueva presentación de David Beazly sobre el GIL en Python: http://blip.tv/file/2232410 – guns