Re: [Python-es] Concurrencia, GIL y multi-núcleo

[Pau Freixes]

Buenas Lista, siguiendo las objetividades de Francesc hago algunos apuntes
que creo que a mi punto de vista podrían desmitificar
el uso de procesos como sistema primario de multiconcurrencia vs threads en
la actual arquitectura de Python.


> Bueno, pues la pregunta es bastante general, pero intentaré responder.
> Personalmente pienso que existen todavia muchas maneras de sacar
> rendimiento a
> las CPUs multi-núcleo sin necesidad de acudir a temas de concurrencia.  Por
> ejemplo, hacer un uso óptimo del ancho de banda de memoria es una cosa
> crítica
> y muy poca gente es consciente de ello.  Si nuestros cálculos están
> limitados
> por el acceso a memoria (y hoy en día la mayoría lo están), un sistema
> multi-
> núcleo poco podrá hacer por acelerarlos.
>
> Otro tema importante es hacer uso de las capacidades de cálculo vectorial
> que
> vienen en las CPUs modernas (instrucciones SSE[2-4] o VMX en el futuro
> próximo) y que estan bastante desaprovechadas en general.  Creo que si los
> desarrolladores hicieran un mejor aprovechamiento de las instrucciones
> vectoriales, se podrian conseguir velocidades bastante superiores en muchas
> situaciones.


Totalmente decuerdo, pero no sera un problema especifico de las aplicaciones
en Python, es un problema orientado a la optimización de código dependiente
de arquitectura. Se han hecho pasos para "oficializar" sistemas de calculo
vectoriales entre
distintos fabricantes de marcas para poder dar al programador un mínimo
entorno neutro - AMD, INTEL - pero seguimos teniendo
diferentes instrucciones para distintos procesadores. Además - como es
lógico - este conjunto de instrucciones se amplian a medida que mejoramos
las prestaciones de los procesadores - lease diferentes releasees de
procesadores para un mismo
fabricante.

Por esta razón el programador de apie, ha hecho poco o nada para intentar
optimizar sus programas. De hecho este es un proceso
que puede dejarse a razón del compilador - no en su totalidad, pero si con
el tipico inlinning, loop unrolling, especializacion - pero la mayoria de
los programas de hoy en dia los compilamos sin tener en cuenta los flags de
optimización.

Para el tema del ancho de banda de memoria, totalmente de acuerdo. Tener
consciencia de la cache de nivel 1 i nivel 2 y de sus características pueden
modificar sobradamente el rendimiento de una aplicación. Por bien o por mal
actualmente tiene que ser el
programador que tendrá que tener en cuenta estas opciones, y siempre acabará
dependiendo de la arquitectura donde se esta ejecutando.


>
>
> Así es que me da la impresión que, debido a que la industria ha derivado
> hacia
> la construcción de procesadores con núcleos múltiples (básicamente por
> razones
> de imposibilidad técnica de seguir por los caminos tradicionales de subir
> la
> frecuencia de los procesadores), existe una fiebre un poco desmesurada por
> parte de los usuarios en poder usar todos los procesadores de forma
> paralela,
> cuando la realidad es que conseguir esto no es posible en general.  Por
> esta
> razón coincido con GvR en que no veo demasiado crítico la limitación del
> GIL.
>

Umm a parte de ser una salida hacia delante contra el problema actual de
seguir escalando la frequencia, por suerte sigue siendo una solución
"valida" para augmentar el rendimiento de nuestras maquinas. El programador
tiene que ser consciente de la nueva arquitectura y sacar el maximo jugo a
ella. Pero para poder hacerlo tendrá que tener las herramientas. El quid de
la questión es como y sobre que raizes se contruyen estas herramientas. En
el caso de Python esta claro que hay una apuesta a corto plazo para
utilizar el proceso como entidad de procesamiento en un entorno de múltiples
cores. Distinto por ejemplo a openMP sobre linux que lo hace sobre pthreads.



>
> Dicho esto, es cierto que hay problemas que pueden sacar rendimiento a
> varios
> procesadores simultáneamente (codificación de vídeo, por ejemplo), aunque
> en
> mi opinión, son áreas bastante restringidas y no afectan a la mayoría de
> desarrollos.


Creo sinceramente que hay otros paradigmas donde puede ser interesante, en
los modelos tradicionales de cliente-servidor. Los actuales desarrollos de
servidores - apache, squid, postfix, ... - han tenido que modificar a lo
largo del tiempo sus paradigmas para dar soporte cada vez a mas i mas
usuarios simultaneos. Algunos eliguieron cambiar a sistemas event-driven,
otros a multihilos/procesos, y otros a sistemas mixtos.



>
> Para la gente interesada en estos temas, hay un par de presentaciones
> bastante
> interesantes que dió Jesse Noller en el último PyCon de Chicago.  En [1],
> describe el paquete ``multiprocessing`` incluido en las últimas versiones
> de
> Python, y cómo se compara con los threads clásicos.  En [2], hace una
> introducción bastante básica y asequible sobre los sistemas concurrentes
> hoy
> en día, haciendo especial énfasis en aclarar unas cuantas falsedades sobre
> la
> percepción que la gente tiene de ellos.  La encuentro bastante
> esclarecedora,
> pues desmitifica un poco las expectativas puestas en el paralelismo.
>

Vi haze tiempo la prensentacion [1], que està realmente bien. Ahora bien
tengo un pero de la presentación, el justifica en cierta medida el uso de
multiprocessing mediante un ejemplo de los tiempos utilizados por el modelo
antiguo de threads y el que el presenta para calcular N numeros primos. Pero
claro justamente en aprlicaciones de CPU intensiva el diseño de Python sobre
threads es bastante deficiente, los números cantan por si solo y no es
justamente por el uso explicito de threads sino por la implemetnación actual
de GIL. Habría estado muy bien una comparativa contra una versión del
programa con python stackless.


Ahora bien, sigo creyendo que Python podría haber hecho una apuesta de
futuro, y no a corto plazo. Solucionando el "problema"
de GIL vs Threads. Tal como comentan la actual implementación libera GIL de
forma implicita cada n instrucciones o bien mediante el orden explicito por
la macro Py_BEGIN_ALLOW_THREADS.

De hecho la construcción de un sistema multi concurrente con uso de threads
tiene la gran problematica del uso de la compartición de memoria de facto,
pero tambien tiene sus cosas positivas : proceso ligero, context switch mas
rapido, uso de memomria más eficiente - en procesos tenemos COW - , etc ..

Bueno estas son mis reflexiones, espero no ser muy pesado :P




>
> [1] http://us.pycon.org/2009/conference/schedule/event/31/
> [2] http://us.pycon.org/2009/conference/schedule/event/69/
>
> Saludos,
>
> --
> Francesc Alted
> _______________________________________________
> Lista de correo Python-es
> http://listas.aditel.org/listinfo/python-es
> FAQ: http://listas.aditel.org/faqpyes
>



-- 
--pau
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes