[Python-es] Python y Procesadores

[Javier Garcia]

Joder tio !! (con perdón), me ha quedado todo clarísimo, muchisimas gracias.

Ahora entiendo muchas cosas. ( todo suposiciones posiblemente
infundadas, soy un pajillero mental no puedo evitarlo )

Supongo que parallelPython funciona ejecutando tantos intérpretes como
workers le indiques, entiendo que multiplica el contexto del script y
utiliza forks a todos esos procesos para recoger la información que
generan. Curioso, curioso.....La cantidad de memoria utilizada, asumo,
que se multiplica por el numero de workers...

¿Se podría separar el contexto ( entiendo por contexto definición de
variables,funciones,objetos..etc) de la ejecución ( entiendo por
ejecución la utilización de esas definiciones)  ?

¿ alguna referencia en la web interesante y no demasiado abstracta a
cambiar la forma en la que python ejecuta scripts, es decir, convertir
la ejecución lineal de un script en python en no-lineal, no sé si me
explico, que las definiciones (contexto) se puedan cambiar en tiempo
de ejecución y el resultado (ejecución) cambia ? ¿live python? aunque
lo del live python no me convence mucho...

Muchisimas gracias por todo

PD lo de offtopic del PyFLTK era por que no tenia que ver mucho con la
cuestión de los procesadores, pero es cierto, en la lista de python no
sería offtopic sería offthread


El 28/10/07, Chema Cortes <pych3m4 en gmail.com> escribió:
> 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.
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es
>


-- 
Drink www.UnMundoFeliz.org