Decu des Threads en Python ? lisez ceci...

Le
OdarR
C'est bien pire que ce que j'imaginais

Présentation video en anglais : http://blip.tv/file/2232410
et les slides présentés : http://www.dabeaz.com/python/GIL.pdf

Y a t-il une modernisation du GIL prévue ?

J'ai fais les tests expliqués au tout début, sur mon PC (XP), et je
confirme

Olivier
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
William Dode
Le #19570511
On 15-06-2009, OdarR wrote:
C'est bien pire que ce que j'imaginais...



Bien au contraire, il faut relativiser tout ça.

L'exemple n'est pertinent que si

- la machine n'a que ça a faire, sinon le deuxième proc sera utilisé par
une autre application, il n'y aura donc pas de perte globale. Ca peut
même être avantage que de ne pas saturer la machine.

- le problème ne peut pas être résolu autrement, soit en réécrivant
la partie critique avec un autre langage, soit en utilisant plusieurs
process au lieu de plusieurs threads. Il y a même un module pour ça :
http://docs.python.org/library/multiprocessing.html

Bref, en pratique il y a très peu de cas où cela pose problème.


Présentation video en anglais : http://blip.tv/file/2232410
et les slides présentés : http://www.dabeaz.com/python/GIL.pdf

Y a t-il une modernisation du GIL prévue ?



Oui, dans le projet http://code.google.com/p/unladen-swallow/ qui vise
également à accélérer d'autres parties.


J'ai fais les tests expliqués au tout début, sur mon PC (XP), et je
confirme...



Ce ne sont que des tests... Faut voir combien de nos applis sont
concernées. La plupart passent leur temps à attendre des données du
disque, d'une bdd, d'une requête web etc. Le tout pendant qu'une bonne
dizaines de services sur la même machine s'occupent de surcharger le
processeur restant.


--
William Dodé - http://flibuste.net
Informaticien Indépendant
OdarR
Le #19571171
On 15 juin, 12:56, William Dode
Bien au contraire, il faut relativiser tout ça.



Voyons...

L'exemple n'est pertinent que si

- la machine n'a que ça a faire, sinon le deuxième proc sera utilis é par
  une autre application, il n'y aura donc pas de perte globale. Ca peut
  même être avantage que de ne pas saturer la machine.



j'insiste sur la perte de perf sur les multi coeur, toute chose étant
égales par ailleurs :-(
c'est balot.

- le problème ne peut pas être résolu autrement, soit en réécri vant
  la partie critique avec un autre langage, soit en utilisant plusieurs
  process au lieu de plusieurs threads. Il y a même un module pour ça :
 http://docs.python.org/library/multiprocessing.html



ah là, merci. Je ne connaissais pas ce package.
J'ai essayé sur les mêmes traitements : on utilise réellement
plusieurs core, et les gains en temps sont significatifs !
En plus l'API est relativement simple et très proche de 'thread'.
Y a un espoir pour les traitements lourds, ouf.
thanks !

Bref, en pratique il y a très peu de cas où cela pose problème.



C'est facile de l'écrire :-)

La façon dont le GIL donne du travail aux différents Threads me fait
un peu peur, il semble que ce soit du multi tâches "coopératif". Ca ne
te gêne pas ?

Oui, dans le projethttp://code.google.com/p/unladen-swallow/qui vise
également à accélérer d'autres parties.



à voir. Ce n'est pas nouveau.

Ce ne sont que des tests... Faut voir combien de nos applis sont
concernées. La plupart passent leur temps à attendre des données du
disque, d'une bdd, d'une requête web etc. Le tout pendant qu'une bonne
dizaines de services sur la même machine s'occupent de surcharger le
processeur restant.



Oui et non, tout dépend de ce que tu dois faire.
Il est clair qu'une utilisation naturelle des thread pallie les
lenteurs d'un réseau, mais ne nous arrêtons pas là.
Le matériel change, et python risque de stagner.

Imagine une appli avec un GUI qui doit coordonner des E/S sur le
réseau, le disque, et en plus traiter les résultats à la volée. Je ne
vois pas pourquoi on devrait se satisfaire d'un seul Core.
Nos machines semblent gagner en perf grace au multi core., il est
normal d'en demander autant aux appli et aux outils de développement.

Olivier
William Dode
Le #19572061
On 15-06-2009, OdarR wrote:
On 15 juin, 12:56, William Dode
Bien au contraire, il faut relativiser tout ça.



Voyons...

L'exemple n'est pertinent que si

- la machine n'a que ça a faire, sinon le deuxième proc sera utilisé par
  une autre application, il n'y aura donc pas de perte globale. Ca peut
  même être avantage que de ne pas saturer la machine.



j'insiste sur la perte de perf sur les multi coeur, toute chose étant
égales par ailleurs :-(
c'est balot.



Il y a perte de perf uniquement si l'application est seule à tourner sur
la machine. Soit c'est une appli sur une machine du bureau qui demande
énormément de cpu, et dans ce cas si on cherche vraiment les perfs il
faut déjà commencer par réécrire la partie critique en C. Soit c'est une
appli serveur et dans ce cas il y aura d'autres services en même temps
donc les différents coeurs seront vraisemblablement déjà utilisés. Et si
on veut vraiment avoir une gestion multi-process il vaudrait mieux
prévoir dès le départ de pouvoir répartir la charge sur plusieurs
machines, on retrouve au paragraphe suivant...


- le problème ne peut pas être résolu autrement, soit en réécrivant
  la partie critique avec un autre langage, soit en utilisant plusieurs
  process au lieu de plusieurs threads. Il y a même un module pour ça :
 http://docs.python.org/library/multiprocessing.html



ah là, merci. Je ne connaissais pas ce package.
J'ai essayé sur les mêmes traitements : on utilise réellement
plusieurs core, et les gains en temps sont significatifs !
En plus l'API est relativement simple et très proche de 'thread'.
Y a un espoir pour les traitements lourds, ouf.
thanks !

Bref, en pratique il y a très peu de cas où cela pose problème.



C'est facile de l'écrire :-)



C'est la définition de python non ;-) !


La façon dont le GIL donne du travail aux différents Threads me fait
un peu peur, il semble que ce soit du multi tâches "coopératif". Ca ne
te gêne pas ?



Ben concrètement non pas trop...


Oui, dans le projethttp://code.google.com/p/unladen-swallow/qui vise
également à accélérer d'autres parties.



à voir. Ce n'est pas nouveau.



Je pense que les deux sont intimement liés. C'est à dire que tant que
python sera si relativement lent, multicoeur ou pas ça ne changera rien.
Par contre si python devenait effectivement quasiment aussi rapide que
du C, là on commencerai à trouver des applis qui peuvent en bénéficier.

C'est le cas de java par ex... Est-ce que ça saute aux yeux que java
exploite le multicoeur et est aussi rapide que le C sur du calcul
intensif ?


Ce ne sont que des tests... Faut voir combien de nos applis sont
concernées. La plupart passent leur temps à attendre des données du
disque, d'une bdd, d'une requête web etc. Le tout pendant qu'une bonne
dizaines de services sur la même machine s'occupent de surcharger le
processeur restant.



Oui et non, tout dépend de ce que tu dois faire.
Il est clair qu'une utilisation naturelle des thread pallie les
lenteurs d'un réseau, mais ne nous arrêtons pas là.
Le matériel change, et python risque de stagner.

Imagine une appli avec un GUI qui doit coordonner des E/S sur le
réseau, le disque, et en plus traiter les résultats à la volée. Je ne
vois pas pourquoi on devrait se satisfaire d'un seul Core.



Justement, dans ces cas là l'utilisation de plusieurs coeurs ne sert
à rien dans l'appli python vu qu'elle va attendre le réseau, le disque
etc.

Nos machines semblent gagner en perf grace au multi core., il est
normal d'en demander autant aux appli et aux outils de développement.



On a déjà le gain lorsque plusieurs applis tournent en même temps...


--
William Dodé - http://flibuste.net
Informaticien Indépendant
OdarR
Le #19572771
On 15 juin, 16:19, William Dode
Il y a perte de perf uniquement si l'application est seule à tourner su r
la machine. Soit c'est une appli sur une machine du bureau qui demande
énormément de cpu, et dans ce cas si on cherche vraiment les perfs il
faut déjà commencer par réécrire la partie critique en C. Soit c' est une



je ne suis pas d'accord.
si on aime le Py comme langage généraliste, c'est aussi pour sa
rapidité de codage pour divers problèmes ponctuels, mais aussi pour se
passer des langages plus lourds tels que le C, le java, ou même le
Perl.
Maintenant, si j'avais effectivement à construire une appli qui devait
durer, pourquoi pas optimiser des morceaux avec du C. Je n'en suis pas
là.

appli serveur et dans ce cas il y aura d'autres services en même temps
donc les différents coeurs seront vraisemblablement déjà utilisés . Et si



mon environnement de travail me donne accès à des vrais serveurs pas
toujours chargés, et parfois même tout à fait libres, et de tout
leurs cœurs :-)

on veut vraiment avoir une gestion multi-process il vaudrait mieux
prévoir dès le départ de pouvoir répartir la charge sur plusieurs
machines, on retrouve au paragraphe suivant...



Pourquoi pas aussi, oui.

Je pense que les deux sont intimement liés. C'est à dire que tant que
python sera si relativement lent, multicoeur ou pas ça ne changera rien .  
Par contre si python devenait effectivement quasiment aussi rapide que
du C, là on commencerai à trouver des applis qui peuvent en bénéf icier.

C'est le cas de java par ex... Est-ce que ça saute aux yeux que java
exploite le multicoeur et est aussi rapide que le C sur du calcul
intensif ?



La richesse de Python permet justement de ne presque plus avoir besoin
de regarder le C ou java dans pas mal de domaines.
Py est effectivement relativement lent p/r au C, raison de plus pour
pouvoir l'accélérer dans certains cas de figure :-)
Tu vois, c'est juste mon point de vue, on peut ne pas être d'accord.

Justement, dans ces cas là l'utilisation de plusieurs coeurs ne sert
à rien dans l'appli python vu qu'elle va attendre le réseau, le disqu e
etc.



et aussi du traitement de données à la volée.
j'utilise une appli de ce genre, écrite en VB. Le simple core est
parfois à la traine. Je pense que Python aurait les mêmes difficultés .
Un autre core à la rescousse serait d'un grand secours.

On a déjà le gain lorsque plusieurs applis tournent en même temps.. .



oui, aussi, ok.

Olivier
ne boudons pas notre plaisir :)
Bruno Piguet
Le #19573051
Juste une précision :

Même si l'intepréteur python n'est pas multi-threadé, il sait utiliser
des bibliothèques qui le sont.
Dans le cas du calcul numérique, il est hautement recommandé de
construire numpy avec les versions multi-threadé d'ATLAS (BLAS et LAPACK).
Une fois que c'est fait, peu importe que le langage d'appel soit
Python ou Fortran.
En plus, le multi-thread n'est pas le seul avantage : ces
bibliothèques sont codées et optimisées depuis longtemps. En
particulier, elles sont plus "cache-friendly" que l'implantation naïve
qu'on pourrait faire au premier abord.

Pour le parallélisme et le "number crunching", voir à :
http://www.scipy.org/ParallelProgramming

Bruno.
OdarR
Le #19573631
On 15 juin, 18:54, Bruno Piguet
Juste une précision :
Pour le parallélisme et le "number crunching", voir à :http://www.sci py.org/ParallelProgramming



Merci de rappeler numpy...que je n'ai pas encore essayé.
l'introduction sur le site en question est pleine de bon sens :)

Olivier
William Dode
Le #19576841
On 15-06-2009, OdarR wrote:

La richesse de Python permet justement de ne presque plus avoir besoin
de regarder le C ou java dans pas mal de domaines.
Py est effectivement relativement lent p/r au C, raison de plus pour
pouvoir l'accélérer dans certains cas de figure :-)
Tu vois, c'est juste mon point de vue, on peut ne pas être d'accord.



Je ne suis pas contre non plus d'accélérer python, ce que je veux juste
dire c'est qu'il y a très peu de cas où ça sera visible. Et donc que le
gil n'est pas si 'pire' que ça.
Si je comparais à java c'est pour dire que java n'a pas le problème du
gil et est compilé en temps réel, hors autant sur des benchs on peut
voir une différence énorme avec python, autant en pratique c'est
rarement le cas.

Il y a énormément de parties et modules python qui sont déjà écrites en
C. Donc quand on dit que python va aller 5x plus vite, ça veut juste
dire, la partie de python qui n'est pas écrite en C va aller 5x plus
vite, le reste ne va rien changer.

On peut déjà faire l'expérience avec psyco. Une simple boucle va 32x
plus vite avec psyco que sans, mais sur une appli réelle je n'ai jamais
vu de gain supérieur à 10%. J'en ai même une qui fait du calcul
intensif, sans accès disque ni réseau, ni module externe, c'est pas
mieux.

Revenons au gil, il faudrait donc pour bénéficier de sa suppression,
avoir d'une part une appli qui demande beaucoup de calcul en python pur
et qu'en plus ces calculs soient effectués en multithread. C'est quand
même pas tous les jours qu'on fait ce genre d'applis, et quand c'est le
cas a beaucoup plus d'avantages à les faire multiprocess (pas de gestion
de verrou, répartition sur plusieurs machines, pas de pénalité si un
seul process etc.)...

Il y a déjà eu des essais pour enlever le gil, mais d'une part le
résultat a été mineur pour le gain en multicoeur et d'autre part ça
a entrainé un ralentissement sur les applis monothread. Le tout
complique également la tache des développeurs d'extensions !

Ceci dit, le projet unladen-swallow est très intéressant car ils
optimisent justement des parties concrètes, comme pickle, regex par ex.
La le gain va être immédiatement visible sur beaucoup plus d'applis.

La réponse de gvr : http://www.artima.com/weblogs/viewpost.jsp?thread!4235

Bref, accélérer python, oui, enlever le gil non !

--
William Dodé - http://flibuste.net
Informaticien Indépendant
OdarR
Le #19581901
On 16 juin, 11:02, William Dode
On 15-06-2009, OdarR wrote:
> La richesse de Python permet justement de ne presque plus avoir besoin
> de regarder le C ou java dans pas mal de domaines.
> Py est effectivement relativement lent p/r au C, raison de plus pour
> pouvoir l'accélérer dans certains cas de figure :-)
> Tu vois, c'est juste mon point de vue, on peut ne pas être d'accord.

Je ne suis pas contre non plus d'accélérer python, ce que je veux jus te
dire c'est qu'il y a très peu de cas où ça sera visible. Et donc qu e le
gil n'est pas si 'pire' que ça.
Si je comparais à java c'est pour dire que java n'a pas le problème d u
gil et est compilé en temps réel, hors autant sur des benchs on peut
voir une différence énorme avec python, autant en pratique c'est
rarement le cas.

Il y a énormément de parties et modules python qui sont déjà éc rites en
C. Donc quand on dit que python va aller 5x plus vite, ça veut juste
dire, la partie de python qui n'est pas écrite en C va aller 5x plus
vite, le reste ne va rien changer.

On peut déjà faire l'expérience avec psyco. Une simple boucle va 32 x
plus vite avec psyco que sans, mais sur une appli réelle je n'ai jamais
vu de gain supérieur à 10%. J'en ai même une qui fait du calcul
intensif, sans accès disque ni réseau, ni module externe, c'est pas
mieux.

Revenons au gil, il faudrait donc pour bénéficier de sa suppression,
avoir d'une part une appli qui demande beaucoup de calcul en python pur
et qu'en plus ces calculs soient effectués en multithread. C'est quand
même pas tous les jours qu'on fait ce genre d'applis, et quand c'est le
cas a beaucoup plus d'avantages à les faire multiprocess (pas de gestio n
de verrou, répartition sur plusieurs machines, pas de pénalité si u n
seul process etc.)...

Il y a déjà eu des essais pour enlever le gil, mais d'une part le
résultat a été mineur pour le gain en multicoeur et d'autre part ça
a entrainé un ralentissement sur les applis monothread. Le tout
complique également la tache des développeurs d'extensions !

Ceci dit, le projet unladen-swallow est très intéressant car ils
optimisent justement des parties concrètes, comme pickle, regex par ex.  
La le gain va être immédiatement visible sur beaucoup plus d'applis.  

La réponse de gvr :http://www.artima.com/weblogs/viewpost.jsp?thread= 214235

Bref, accélérer python, oui, enlever le gil non !



Bonne conclusion générale, merci.

Olivier
OdarR
Le #19600121
On 15 juin, 11:41, OdarR
C'est bien pire que ce que j'imaginais...

Présentation video en anglais :http://blip.tv/file/2232410
et les slides présentés :  http://www.dabeaz.com/python/GIL.pdf

Y a t-il une modernisation du GIL prévue ?

J'ai fais les tests expliqués au tout début, sur mon PC (XP), et je
confirme...

Olivier



Encore un lien intéressant, mais positif cette fois :
<http://www.ibm.com/developerworks/aix/library/au-multiprocessing/
index.html?ca=dgr-lnxw07Python-
Multi&S_TACT5AGX59&S_CMP=grsitelnxw07>

Olivier
OdarR
Le #19600761
On 19 juin, 16:13, OdarR
Encore un lien intéressant, mais positif cette fois :
<http://www.ibm.com/developerworks/aix/library/au-multiprocessing/
index.html?ca=dgr-lnxw07Python-
Multi&S_TACT5AGX59&S_CMP=grsitelnxw07>



ou http://minilien.com/?SLPMeon16u

Olivier
Publicité
Poster une réponse
Anonyme