[Python-es] Python y Procesadores

[Chema Cortes]

El 27/10/07, Javier Garcia <red.octobered en gmail.com> escribió:
> Hola a todos,
>
> hace poco que estoy subscrito a esta lista y supongo que el tema se
> habrá tratado en algún momento pero,

Hemos hablado alguna vez del tema, pero no creas que lo tenemos claro
del todo. Desde luego no es para novatos, por lo que si has empezado
por aquí has tenido que mirar mucho.

> ¿por qué python no utiliza el 100% del procesador en sistemas N-core,
> es cosa del GIL?

En ingeniería se dice que si una persona tarda 10 horas en realizar un
trabajo, éso no implica que se pueda hacer ese mismo trabajo en una
hora empleando 10 personas. Con los N-core pasa lo mismo. Con un
procesador N-core puedes ejecutar mejor N tareas, pero no por eso se
puede ejecutar una tarea N veces más rápida.

En python no es posible ejecutar múltiples hilos en paralelo por culpa
del GIL. Siendo precisos, ésto sólo ocurre con CPython, ya que sí que
es posible con jython e ironpython que usan el multihilo nativo de las
máquinas virtuales JVM y CLI, respectivamente.

Para python3k se quiso eliminar la restricción del GIL en CPython,
pero se comprobó, contra lo que se pueda pensar, que decaía el
rendimiento rápidamente en procesadores multinúcleo, por lo que se
dejó como estaba.

> ¿si tenemos un quad-core ( en mi caso dual core ) solo utilizaria 1/4
> de la potencia del procesador?
>
> ¿ocurre lo mismo en linux?

Sí y no. No pienses que por tener un quad-core tu sistema operativo
irá cuatro veces más rápido. Hay un problema gordo con los cambios de
contexto del procesador, cuando un procesador debe guardar su entorno
de ejecución para dejar paso a una nueva tarea. Estos cambios son tan
costosos que en windows se llegó a optar por congelar el kernel en uno
de los cores para mejorar el rendimiento global del sistema operativo,
lo que llegaba a degradaba el rendimiento del resto de aplicaciones.

En linux está mejor diseñado el tema de multiprocesamiento. Si quieres
que tu programa python funcione a tope, basta con crear 4 forks, cada
uno corriendo su propio intérprete python. El GIL se aplicaría por
fork. Diseñar por fork o por hilo es algo que tendrás que evaluar al
programar tu aplicación.

> incluso utilizando stackless... (comprobado,  50% en un dualCore)
> ¿habría que recurrir a modulos tipo Parallel Python, MPI etc?

Tan sólo indicar que los módulos de python hechos en C sólo están
sujetos al GIL en los accesos a los objetos globales python. Para todo
lo demás aprovechan toda la potencia del procesador multicore.

Desconozco el rendimiento del stackless en multicores. Pero, si lo
piensas bien, la ventaja del stackless es que se libera del stack de
C, pero nada cambia en cuanto al acceso a las variables globales que
es donde actúa el bloqueo del GIL.

> ¿si la ejecución de python, en modo interactivo, es puramente lineal,
> el interprete de python no podria utilizar un Dual Core como si se
> tratara de un solo procesador?

Ya te digo que los cambios de contexto son costosos y que resulta
mejor trabajar, siempre que se pueda, con un sólo core.

> y una offtopic ¿que opinión os merece FLTK?

¿offtopic? http://pyfltk.sourceforge.net

Aunque lo he visto alguna vez, no lo he probado ni lo he seguido
demasiado. No puedo decirte mucho más.