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...
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...
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...
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éé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
Bref, en pratique il y a très peu de cas où cela pose problème.
Oui, dans le projethttp://code.google.com/p/unladen-swallow/qui vise
également à accélérer d'autres parties.
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.
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éé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
Bref, en pratique il y a très peu de cas où cela pose problème.
Oui, dans le projethttp://code.google.com/p/unladen-swallow/qui vise
également à accélérer d'autres parties.
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.
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éé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
Bref, en pratique il y a très peu de cas où cela pose problème.
Oui, dans le projethttp://code.google.com/p/unladen-swallow/qui vise
également à accélérer d'autres parties.
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.
On 15 juin, 12:56, William Dode wrote: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éé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 :-)
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.
On 15 juin, 12:56, William Dode <w...@flibuste.net> wrote:
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éé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 :-)
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.
On 15 juin, 12:56, William Dode wrote: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éé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 :-)
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.
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
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...
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 ?
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.
On a déjà le gain lorsque plusieurs applis tournent en même temps.. .
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
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...
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 ?
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.
On a déjà le gain lorsque plusieurs applis tournent en même temps.. .
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
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...
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 ?
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.
On a déjà le gain lorsque plusieurs applis tournent en même temps.. .
Juste une précision :
Pour le parallélisme et le "number crunching", voir à :http://www.sci py.org/ParallelProgramming
Juste une précision :
Pour le parallélisme et le "number crunching", voir à :http://www.sci py.org/ParallelProgramming
Juste une précision :
Pour le parallélisme et le "number crunching", voir à :http://www.sci py.org/ParallelProgramming
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.
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.
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.
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 !
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 !
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 !
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
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
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>
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_TACT=105AGX59&S_CMP=grsitelnxw07>
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>