python - microsoft - visual studio community
¿Los subprocesos de Python tienen errores? (6)
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.
Un amigo confiable del programador me dijo que la implementación actual de múltiples subprocesos de Python tiene fallas graves, lo suficiente como para evitar el uso por completo. ¿Qué puede decir sobre este rumor?
Por lo que yo 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 generalmente lo suficientemente bueno si la mayoría de los subprocesos se bloquean) debido a GIL (Global Interpreter Bloquear), 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.
Consulte esta publicación sobre por qué no es realmente posible eliminar el GIL de la implementación de cPython, y esto para algunas elaboraciones prácticas y soluciones alternativas.
Haz un google rápido para "Python GIL" para más información.
La implementación estándar de Python (generalmente conocida como CPython tal como está escrita en C) usa subprocesos de sistema operativo, pero dado que existe el bloqueo de intérprete global , solo se permite ejecutar un subproceso a la vez para ejecutar 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 e IronPython .
Jython está escrito en Java, y ahora está bastante maduro, aunque persisten algunas incompatibilidades. Por ejemplo, el framework web Django no funciona perfectamente todavía , pero se está acercando todo el tiempo. Jython es ideal para la seguridad de hilos , sale mejor en puntos de referencia y tiene un mensaje descarado para aquellos que quieren el GIL .
IronPython usa .NET framework y está escrito en C #. La compatibilidad está llegando a la etapa en que Django puede ejecutarse en IronPython (al menos como una demostración) y hay guías para usar hilos en IronPython .
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.
Los subprocesos de Python son buenos para la programación de E / S concurrente . 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 el 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.
Hay soluciones como ejecutar múltiples intérpretes de Python al mismo tiempo, usando una biblioteca de threading 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.
El GIL (Global Interpreter Lock) podría ser un problema, pero la API está bastante bien. Pruebe el excelente módulo de 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!
EDITAR : 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!