unladen-swallow

On Jul 28, 10:39 pm, "Michel Claveau -
MVP"<enleverLesX_XX...@XmclavXeauX.com> wrote:

Est-ce que quelqu'un, qui apprécie Python et comprend l'anglais, aurait déjà vu ça :
   http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
Et, est-ce que ce "quelqu'un" pourrait donner quelques explications en fr ançais ?

C'est un projet d'accélération du moteur de Python (CPython, en
l'occurence). Ces gars (de chez Google) travaillent d'une part sur la
réécriture et l'optimisation de diverses choses dans le moteur, mais
aussi sur l'ajout d'un compilateur "just-in-time" (en très gros, un
truc qui transforme les bouts de code Python en paquets de code
machine, au moment de l'exécution).

Ils causent avec Guido, avec les gens de CPython, et ils ont déjà
quelques résultats, alors ça fait du bruit.

Un article sur LWN (toujours en anglais, mais bon, un poil moins
technique) : http://lwn.net/Articles/332038/

a+
--
Thomas

On 28-07-2009, Michel Claveau - MVP wrote:

Bonsoir !

Est-ce que quelqu'un, qui apprécie Python et comprend l'anglais, aurait déjà vu ça :
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

Et, est-ce que ce "quelqu'un" pourrait donner quelques explications en français ?

En plus de ce qu'as écrit thomas, ils vont s'appuyer sur LLVM, une sorte
de machine virtuelle de bas niveau avec JIT. Ca permettra également de
ne plus avoir de GIL.
Pour info, mono va également s'appuyer sur LLVM, avec déjà un gain de
26%.
Le problème en revanche c'est la mémoire...

En même temps ils vont optimiser certains modules, comme pickle et re.

La raison pour laquelle ils ne travaillent pas plutôt sur PyPy (qui
bosse aussi sur du JIT) ou sur Jython, c'est qu'ils ont pas mal
d'extensions en C.

Le but est d'avoir un résultat très rapidement, 100% compatible et
intégré dans la branche standard (la 2.6 en priorité).

J'ai fait quelques benchs sur un programme de déplacement de chevaux,
donc du récursif avec petit tableau :

http://hg.flibuste.net/libre/games/cheval

Les résultats :

c 1.65s
gcj 1.9s
cython 2s
java 2.4s
shedskin 0.2 -bw 2.6s
python2.5 + psyco 2.9s
unladen-2009Q2 125s (2m05)
Jython 2.2.1 on java1.6.0_12 176s (without array, like shedskin)
python2.5 215s (3m35s)
python3.1 246s (4m06s)
Jython 2.2.1 on java1.6.0_12 334s (with array)
php5.2.6 500 (8m20s)
ironpython1.1.1 (mono) 512 (8m32s)

Mais cette 2ème version d'unladen ne signifie pas grand chose, le but
à se stade était juste d'avoir quelque chose qui marche avec LLVM.
L'optimisation du moteur commence juste maintenant. (pareil pour jython
d'ailleurs)

On voit que psyco permet déjà d'être très proche du C pour ce genre de
routine.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

"Michel Claveau - MVP"<enleverLesX_XXmcX@XmclavXeauX.com> writes:

Est-ce que quelqu'un, qui apprécie Python et comprend l'anglais,
aurait déjà vu ça :
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

Et, est-ce que ce "quelqu'un" pourrait donner quelques explications en
français ?

Il s'agit d'ajouter un compilateur JIT dans l'interpréteur python. Le
problème des langages interprétés ("de script") comme Python , c'est que
quand on commence à l'utiliser pour des programmes qui tournent
"longtemps", le cout de l'interprétation devient significatif en valeur
absolue. L'idée est donc de générer du code natif pour les " hotspots",
c'est-à-dire les bouts de code qui s'exécutent souvent/longtemps. Tout
le monde fait cela en ce moment, et Google s'était déjà dist ingué avec
la machine virtuelle pour JavaScript dans Chrome. Ce n'est pas étonnant
qu'il s'intéresse à Python puisqu'une partie (non connue) de leur
architecture utilise Python (via MapReduce en particulier). Sun fait
cela depuis des années avec HotSpot, sa machine virtuelle pour Java. L es
techniques utilisées datent des années 90 et ont largement fait l eurs
preuves dans les langages compilés.

LLVM est, pour faire simple, un compilateur dont le code source est une
sorte d'assembleur enrichi, et qui inclut toutes les optimisations
"modernes". Il suffit donc de produire du code LLVM pour profiter
immédiatement d'un compilateur performant, et cela sur diverses
architectures. C'est aussi ce que fait Apple (qui a embauché le crà ©ateur
de LLVM) mais on ne sait pas trop pour quoi. L'avantage est que le
langage intermédiaire est unifié, et qu'on peut ajouter ses propr es
passes d'optimisation.

Les JIT sont en général déterminants en termes de performanc e. Cela dit,
les problèmes de performance ont des provenances multiples. Typiquemen t,
dans les langages de scripts à typage dynamique, on est très limi té (par
exemple il est en général impossible de faire de l'inlining, donc des
optimisations "globales"). Je ne serai donc pas étonné qu'on nous parle
bientôt de typage statique dans Python, au-delà des annotations q ui
apparaissent dans P3.

-- Alain.

On 29-07-2009, Alain Ketterlin wrote:

Les JIT sont en général déterminants en termes de performance. Cela dit,
les problèmes de performance ont des provenances multiples. Typiquement,
dans les langages de scripts à typage dynamique, on est très limité (par
exemple il est en général impossible de faire de l'inlining, donc des
optimisations "globales"). Je ne serai donc pas étonné qu'on nous parle
bientôt de typage statique dans Python, au-delà des annotations qui
apparaissent dans P3.

C'est un peu déjà ce qui est fait avec shedskin, pyrex, cython... A mon
avis pareil, on n'y coupera pas, mais tant que ça restera en option ce
n'est pas très gênant.
En tout cas il me semble que c'est la première fois qu'il y a autant de
boulot en cours focalisé sur les perfs de python. Je ne sais pas si ça
me servira souvent mais en tout cas c'est passionnant à suivre !

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Alain Ketterlin a écrit :

Est-ce que quelqu'un, qui apprécie Python et comprend l'anglais,
aurait déjà vu ça :
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

Et, est-ce que ce "quelqu'un" pourrait donner quelques explications en
français ?

Il s'agit d'ajouter un compilateur JIT dans l'interpréteur python.

Étant un néophyte sur ces questions, j'aimerais bien qu'on
m'éclaire un peu si c'est possible.

Quand je tape "python mon_script.py"

D'abord 1) un compilateur compile le source "mon_script.py"
en bytecode et 2) ce bytecode est interprété par la machine
virtuelle Python. C'est bien ça ?

Mais le compilateur dont il est question dans 1), ce n'est
pas un JIT justement ? Ou alors le JIT est un autre
compilateur qui intervient dans l'étape 2) (au moment de
l'interprétation du bytecode) pour à nouveau compiler
certaines partie du bytecode en langage machine, c'est ça ?
Du coup, avec un JIT, il y aurait alors deux phases de
compilation ?



--
François Lafont

On 29-07-2009, Francois wrote:

Alain Ketterlin a écrit :

Est-ce que quelqu'un, qui apprécie Python et comprend l'anglais,
aurait déjà vu ça :
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

Et, est-ce que ce "quelqu'un" pourrait donner quelques explications en
français ?

Il s'agit d'ajouter un compilateur JIT dans l'interpréteur python.

Étant un néophyte sur ces questions, j'aimerais bien qu'on
m'éclaire un peu si c'est possible.

Quand je tape "python mon_script.py"

D'abord 1) un compilateur compile le source "mon_script.py"
en bytecode et 2) ce bytecode est interprété par la machine
virtuelle Python. C'est bien ça ?

Mais le compilateur dont il est question dans 1), ce n'est
pas un JIT justement ? Ou alors le JIT est un autre
compilateur qui intervient dans l'étape 2) (au moment de
l'interprétation du bytecode) pour à nouveau compiler
certaines partie du bytecode en langage machine, c'est ça ?
Du coup, avec un JIT, il y aurait alors deux phases de
compilation ?

Tout juste. La première compilation en bytecode écrit sur disque (le
.pyc) tandis que la deuxième, le jit c'est en mémoire, d'où le terme 'in
time'.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

William Dode <wilk@flibuste.net> writes:

On 29-07-2009, Alain Ketterlin wrote:

[...] Je ne serai donc pas étonné qu'on nous parle bientô t de typage
statique dans Python, au-delà des annotations qui apparaissent dans
P3.

C'est un peu déjà ce qui est fait avec shedskin, pyrex, cython. .. A mon
avis pareil, on n'y coupera pas, mais tant que ça restera en option ce
n'est pas très gênant.

Juste pour préciser mon point de vue : je pense que le typage statique
est une excellente chose, et je regrette vraiment que Python n'y attache
pas plus d'importance. Et pas seulement pour des raisons d'efficacité. ..

En tout cas il me semble que c'est la première fois qu'il y a autant de
boulot en cours focalisé sur les perfs de python. Je ne sais pas si ça
me servira souvent mais en tout cas c'est passionnant à suivre !

Tu as parfaitement résumé le dilemme : dans un script qui passe 9 0% de
son temps à attendre des entrées sorties, le gain sera négli geable s'il
est perceptible. Et j'ai l'impression que les gens qui font du calcul
avec python ont déjà passé tout ce qui est long en C. Mais q uand c'est
google qui a besoin de quelque chose...

-- Alain.

Francois <francois@noSpam.fr> writes:

Il s'agit d'ajouter un compilateur JIT dans l'interpréteur python.

Étant un néophyte sur ces questions, j'aimerais bien qu'on m' éclaire
un peu si c'est possible.

Quand je tape "python mon_script.py"

D'abord 1) un compilateur compile le source "mon_script.py" en
bytecode et 2) ce bytecode est interprété par la machine virtue lle
Python. C'est bien ça ?

C'est bien cela. Le point important est que c'est une machine virtuelle
(un programme comme un autre) qui joue le rôle de... machine : cette MV
doit donc interpéter une à une les instructions du bytecode, four nir une
zone de mémoire, une pile d'exécution, etc.

Mais le compilateur dont il est question dans 1), ce n'est pas un JIT
justement ?

Non pas vraiment : il compile tout d'un coup, puis exécute (ou à peu
près). Eventuellement il compile à la volée des modules, mai s le grain
est un peu trop gros pour qu'on parle de JIT.

Ou alors le JIT est un autre compilateur qui intervient dans l'étape
2) (au moment de l'interprétation du bytecode) pour à nouveau c ompiler
certaines partie du bytecode en langage machine, c'est ça ?

Exactement. Le résultat en est du code natif, exécuté direct ement, ce
qui est beaucoup plus rapide que la MV. Un autre avantage de cette
stratégie est que le compilateur peut être sélectif dans ce qu'il
compile en natif, et garder dans le même programme des parties en
bytecode et des parties en natif.

Du coup, avec un JIT, il y aurait alors deux phases de compilation ?

Oui, voire même plusieurs : la première, globale, pour passer en
bytecode, les suivantes, partielles, pour convertir le bytecode en
natif. Ces compilations partielles ne sont pas systématiques. La
compilation d'une part est un processus éventuellement coûteux qu and
elle optimise, et d'autre part elle peut tirer profit d'informations
obtenues à l'exécution. Il est donc possible qu'un JIT décid e de
recompiler un bout de code déjà compilé parce que l'exé cution lui
indique que ce serait profitable. Inversement, le JIT peut abandonner un
bout compilé parce que le gain est minime et qu'il ne veut pas exploser
la taille du code qu'il gère. Bref, ça peut sembler de la magie n oire,
mais ça répond vraiment à des besoins et ça donne de bo ns résultats.

-- Alain.

William Dode a écrit :

Quand je tape "python mon_script.py"

D'abord 1) un compilateur compile le source "mon_script.py"
en bytecode et 2) ce bytecode est interprété par la machine
virtuelle Python. C'est bien ça ?

Mais le compilateur dont il est question dans 1), ce n'est
pas un JIT justement ? Ou alors le JIT est un autre
compilateur qui intervient dans l'étape 2) (au moment de
l'interprétation du bytecode) pour à nouveau compiler
certaines partie du bytecode en langage machine, c'est ça ?
Du coup, avec un JIT, il y aurait alors deux phases de
compilation ?

Tout juste. La première compilation en bytecode écrit sur disque (le
.pyc) tandis que la deuxième, le jit c'est en mémoire, d'où le terme 'in
time'.

D'accord. Merci bien. Juste une remarque, le .pyc n'est pas
toujours sur le disque mais en mémoire RAM également il me
semble, non ? C'est quand le code est un module que le .pyc
est copié sur le disque. Enfin je crois.


--
François Lafont

Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:

'Lut,

C'est aussi ce que fait Apple (qui a embauché le créateur de LLVM)
mais on ne sait pas trop pour quoi.

Si j'ai tout bien compris, Grand Central permet de générer à la volée du
code pour les unités de calcul disponibles à partir d'une représentation
intermédiaire llvm, que ce soit pour une cpu classique ou encore une
gpu.

http://www.appletell.com/apple/comment/grand-central-and-opencl-detailed/

--
Pour moi, que ce soit fr.rec.arts.musique.variete ou
fr.rect.arts.chansons, c négatif, parce que je considére pas
la musique comme un art,
-+- BenC in http://www.le-gnu.net : Neuneu joue du pipo.