D'après ce que j'ai lu des objectifs, ils ciblent la compatibilité source avec les extensions C de Python : Goals
3. Maintain source-level compatibility with CPython applications.
4. Maintain source-level compatibility with CPython extension modules.
Sachant cela, sachant aussi que les parties critiques des traitements lourds sont déjà écrits en C donc exécuté avec du code natif.
Comme ils restent avec la compatibilité CPython, ils vont juste remplacer l'interprétation de byte-code par du code déjà compilé en natif.
Mais, ils se heurteront au lock global et à sa prise/libération, s'ils réussissent à le contourner et que ça fonctionne encore bien, chapeau (et GVR sera sûrement très intéressé) [*].
Ils se heurteront aussi à tous les moments où le programme passe par de la résolution de noms, inévitable si l'on veut conserver la souplesse qu'apporte ce mode de fonctionnement de Python.
Je vois bien un intérêt fort pour ce qui est boucles, pour la compilation native de certains modules standards actuellement en code Pyhton. Aller plus loin nécessiterais de donner au compilateur des indications plus complètes (genre variable typée entier ou chaîne, où l'on pourrait alors court-circuiter la résolution de noms et passer directement à du code de calcul natif...) qui peuvent faire gagner beaucoup, mais éloignent du langage dynamique que l'on connaît.
Je suis franchement curieux de voir comment tout ça va évoluer.
Et une petite mise en garde pour les détracteurs "python est trop lent": même avec un tel projet en fonctionnement, un programme Python avec le côté dynamique du langage ne pourra jamais aller plus vite qu'un programme équivalent en langage style C/C++/Fortran... bien codé (j'insiste là dessus) [**].
Après, combien de temps pour bien coder en Python, et combien de temps pour bien coder en C/C++/Fortran... et quel est le ratio de code sur lequel le programme passe 90% de son temps...
[*] A lire dans les liens donnés: http://code.google.com/p/unladen-swallow/wiki/ProjectPlan, par exemple ils considèrent l'utilisation d'un autre type de ramasse-miettes pour éviter le problème du GIL (gaffe aux effets de bords par rapport aux codeurs qui auront joué avec le fait que pour le moment CPython utilise un comptage de références) - et il me semble que le GIL a aussi un effet de protection de l'ensemble des donnés, pas uniquement des compteurs de références.
[**] Je ne parle pas d'un programme Python qui se limiterais à un appel à une fonction de Numpy... mais d'un truc complet avec tout plein de scripts derrière.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# C'est ambitieux... mais si ça marche...
Posté par lolop (site web personnel) . En réponse à la dépêche Publication de Unladen Swallow 2009Q3. Évalué à 6.
Goals3. Maintain source-level compatibility with CPython applications.
4. Maintain source-level compatibility with CPython extension modules.
Sachant cela, sachant aussi que les parties critiques des traitements lourds sont déjà écrits en C donc exécuté avec du code natif.
Comme ils restent avec la compatibilité CPython, ils vont juste remplacer l'interprétation de byte-code par du code déjà compilé en natif.
Mais, ils se heurteront au lock global et à sa prise/libération, s'ils réussissent à le contourner et que ça fonctionne encore bien, chapeau (et GVR sera sûrement très intéressé) [*].
Ils se heurteront aussi à tous les moments où le programme passe par de la résolution de noms, inévitable si l'on veut conserver la souplesse qu'apporte ce mode de fonctionnement de Python.
Je vois bien un intérêt fort pour ce qui est boucles, pour la compilation native de certains modules standards actuellement en code Pyhton. Aller plus loin nécessiterais de donner au compilateur des indications plus complètes (genre variable typée entier ou chaîne, où l'on pourrait alors court-circuiter la résolution de noms et passer directement à du code de calcul natif...) qui peuvent faire gagner beaucoup, mais éloignent du langage dynamique que l'on connaît.
Je suis franchement curieux de voir comment tout ça va évoluer.
Et une petite mise en garde pour les détracteurs "python est trop lent": même avec un tel projet en fonctionnement, un programme Python avec le côté dynamique du langage ne pourra jamais aller plus vite qu'un programme équivalent en langage style C/C++/Fortran... bien codé (j'insiste là dessus) [**].
Après, combien de temps pour bien coder en Python, et combien de temps pour bien coder en C/C++/Fortran... et quel est le ratio de code sur lequel le programme passe 90% de son temps...
[*] A lire dans les liens donnés: http://code.google.com/p/unladen-swallow/wiki/ProjectPlan, par exemple ils considèrent l'utilisation d'un autre type de ramasse-miettes pour éviter le problème du GIL (gaffe aux effets de bords par rapport aux codeurs qui auront joué avec le fait que pour le moment CPython utilise un comptage de références) - et il me semble que le GIL a aussi un effet de protection de l'ensemble des donnés, pas uniquement des compteurs de références.
[**] Je ne parle pas d'un programme Python qui se limiterais à un appel à une fonction de Numpy... mais d'un truc complet avec tout plein de scripts derrière.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN