GIL e hyperthreading

rosendo rosendo.martinez en valdisme.com
Mie Mar 24 19:27:07 CET 2004


Buenas, Chema, la verdad que tampoco soy un experto en el tema.....pero como
he tenido algunos 'problemas' de esos teóricos con python(que a la hora de
la implementación no fueron determinantes), pues he leido un poquillo al
respecto del GIL y el porque no multithreading de la 'maquina virtual' de
python.
Creo que la pregunta a ¿Realmente es tan complicado eliminar este lock?, la
respuesta es parece que sí, si quieres conservar la opción de
multiplataforma. Por ejemplo(esto cojido con pinzas, si alguien puede dar un
poco de luz), java en unix(solaris) tiene lo que se llama greenthreads, lo
hace que en si la maquina pueda ejecutar distintos threads, pero sólo en un
procesador. Solaris(digo Solaris, porque el problema lo tuve en ese OS) para
que una aplicación se pueda ejecutar en distintas CPU ha de tener distintos
procesos(fork), sinó no hay tu tia. Como todo el mundo sabe, eso en java
tiene una solución y es la ejecución de procesos en distintas máquinas
virtuales....etc..(cosa que existe en python pero de una forma un poco más
manual). En python existe otra distribución stackless, que surge a raiz de
una discusión entre Christian Tismer y Guido Van Rossum, en la que no se
ponen de acuerdo. Total es una escisión de python, que funciona mejor para
ciertas aplicaciones que necesitan ejecutarse en entornos
multithread(implementa en concepto de threds ligeros, los greenthreds, que
no se xq se llaman así). Con respecto a jython, no lo tiene xq es java el
que ejecuta los threads, aunque con la salvedad esa que he comentado.
Lo del hyperthreading.....uhmmmmm, pues no lo sé,.....el rendimiento nunca
ha sido un de las premisas de Guido a la hora  de implementar el python y
menos, según sus palabras en entornos multithreading(aunque si es así, xq
tiene la lib thread?...hay no estoy de acuerdo con Guido).
Desde luego no hay un metodo mejor, pero yo lo haria usando objetos
compartidos, e implementando una estructura de servidor-consumidor,...aunque
eso puede variar mucho en función de lo que tengas que implementar.

Bueno, espero haber ayudado, aunque me da la impresión de que he sembrado
más dudas que otra cosa.

Un saludo.
Rosendo.

-----Mensaje original-----
De: python-es-bounces en aditel.org [mailto:python-es-bounces en aditel.org] En
nombre de Chema Cortes
Enviado el: miércoles, 24 de marzo de 2004 13:25
Para: Python-es en aditel.org
Asunto: [Python-es] GIL e hyperthreading

No comprendo del todo bien el mecanismo del "Global Interpreter
Lock" (GIL) para los procesos multihilo (en CPython). Sé que se hace por
conservar el contaje de las referencias a variables, pero no entiendo
porqué bloquear todo el intérprete. ¿No sería factible bloquear sólo el
acceso a una determinada zona "compartida" en lugar de bloquear todo el
intérprete? ¿Realmente es tan complicado eliminar este lock? (Por
ejemplo jython no lo tiene).

Otra pregunta es respecto al hyperthreading del pentium4. Se supone que
engaña al software para que piense que hay dos procesadores, cuando en
realidad sólo hay uno. ¿Pierde rendimiento el intérprete de CPythonen
los cambios de estados en hyperthreading a causa del GIL? ¿Cómo habría
que recompilar python para hyperthreading y linux [0]?

Y como "escape", entiendo que va a resultar mejor utilizar "forking" en
linux en sistemas multiprocesador pero, ¿qué método sería el más
apropiado para intercambiar información entre los procesos sin tener que
echar mano de las bases de datos?


Referencias:
[0] http://www.zaralinux.org/modules.php?name=News&file=article&sid=648



Más información sobre la lista de distribución Python-es