Chers petits Naux,
PyPy est une implémentation de Python en Python qui va vite, est plus facile à faire évoluer que d'autres, et dont un bout de l'architecture peut aussi servir à faire d'autres langages qui vont vite et d'une manière plus facile à maintenir et faire évoluer.
Je ne sais pas depuis combien de temps cet appel est lancé, mais je suis récemment tombé dessus : le projet PyPy aimerait bien pouvoir financer du développement à plein temps pour supporter Python 3 ainsi que NumPy
Attention aux 3 liens en haut à droite, par défaut "Donate towards NumPy in pypy" est sélectionné, même lorsque vous lisez l'appel au dons pour Python3.
À l'heure où j'écris ces lignes, l'état des dons pour Python3 dans PyPy est le suivant : $39882 of $105000 (38.0%).
À noter que "Should we not receive enough donations to complete all stages by 1st March 2012 at the latest, we will try our best to make PyPy support Python 3 anyway. We however reserve the right to shift any unused funds to other PyPy activities when that date is reached."
Traduction : "Si au 1er Mars 2012 nous n'avons pas reçu assez de dons pour compléter toutes les étapes, nous ferons de notre mieux pour ajouter tout de même le support de Python 3. Nous nous réservons néanmoins le droit de rediriger les fonds non utilisés pour d'autres activités de PyPy à cette date."
Le 1er Mars 2012 arrivant bientôt, si vous êtes tellement riche que vous ne savez plus du tout quoi faire de votre argent et que vous trouvez toussa très bien, n'hésitez pas à faire péter $65k
++
# une implémentation de Python en Python
Posté par goeb . Évalué à 5.
Que signifie ceci ?
Ça voudrait dire que pour faire tourner mon programme python à l'aide de PyPy, j'aurais quand même besoin d'un autre interpréteur Python (en instructions machines natives) qui fera tourner PyPy ?
Si oui, quel est l'intérêt de PyPy ? un intérêt académique ?
[^] # Re: une implémentation de Python en Python
Posté par patrick_g (site web personnel) . Évalué à 9.
Explication : http://fr.wikipedia.org/wiki/Pypy#PyPy
Ça va plus vite que CPython.
[^] # Re: une implémentation de Python en Python
Posté par HardShooter . Évalué à 1.
Pas vraiment puisque la chaîne d'outils utilise l’interpréteur
[^] # Re: une implémentation de Python en Python
Posté par monde_de_merde . Évalué à 3.
Si, enfin presque, c'est compliqué, on parle de compilateur, du coup l’œuf et la poule tout ça.
PyPy c'est 2 morceaux.
Le premier c'est l'interpréteur en lui même. Il est écrit en RPython (en gros un sous ensemble de python).
Ce premier morceau tu peux le faire fonctionner de plusieurs manières. tu peux le faire fonctionner au dessus de CPython, avec Jython, avec IronPython etc... Mais l'avantage de RPython c'est qu'il existe l'auter morceau une chaîne d'outils (elle même écrite en RPython) qui traduit et compile le code RPython en C (compilable et tout et tout). Mais dans la mesure où tu pourrais écrire un compilateur (parce c'est ce qu'est en gros la chaîne d'outils) pour RPython dans un autre language, on peut dire que les 2 morceaux sont indépendant.
J'espère que je suis un petit peu clair.
[^] # Re: une implémentation de Python en Python
Posté par HardShooter . Évalué à 1.
La chaîne d'outils utilise "l’interpréteur en lui même" pour créer des Control Flow Graphs (à défaut de traduction) à partir du code RPython
[^] # Re: une implémentation de Python en Python
Posté par Guillaume Knispel . Évalué à 7.
Sans rentrer dans les détails, cela signifie a peu près la même chose que lorsque l'on remarque que gcc est une implémentation de C en C.
En rentrant un peu plus dans les détails (j'espère que je ne vais pas dire de connerie, je ne suis pas ce projet de très près), PyPy est une VM (avec un JIT généré d'une manière stylée, cf http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time ) écrite en RPython qui est un sous-ensemble de Python suffisamment souple pour écrire des choses intéressantes avec, et suffisamment restreint pour que de l'inférence de type des autres trucs funs soient possible, permettant la compilation en un code efficace.
# Evil or not evil ?
Posté par patrick_g (site web personnel) . Évalué à 3.
A noter que Google a donné 35 000$ pour le portage vers Python 3.
La source de l'info avec des détails sur la campagne de dons : http://morepypy.blogspot.com/2012/01/py3k-and-numpy-first-stage-thanks-to.html
[^] # Re: Evil or not evil ?
Posté par Guillaume Knispel . Évalué à 2.
Ça signifie qu'il y a uniquement $5k qui viennent d'ailleurs que Google pour Python3. Je pense qu'avec un peu de pub, ça pourrait monter plus haut.
# En liquide ?
Posté par be_root . Évalué à 5.
Faut donner dans une soucoupe ?
Il se prend pour Napoléon, son état empire.
# STM
Posté par HardShooter . Évalué à -2.
Il y aura surement un autre appel au don pour avoir une Software Transactionnal Memory dans PyPy (ce qui permettra d'avoir du vrai parallélisme en Python)
# A donné !
Posté par koxinga . Évalué à 3.
A donné ! Je suis un grand fan de NumPy et la combination avec PyPy semble naturelle, je suis impatient de voir ce que cela va donner.
# Portage de Numpy
Posté par Nonolapéro . Évalué à 8.
D'après Travis Oliphant, le créateur de Numpy/Scipy, le portage ne serait pas une très bonne idée. Le problème est la création de deux branches de Numpy qui ne vont pas évoluer à la même vitesse. Il pense qu'il serait mieux d'intégrer les améliorations que propose Pypy au cœur de Numpy.
http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-numpy-to-pypy.html
[^] # Re: Portage de Numpy
Posté par HardShooter . Évalué à 2.
Sinon, tout le monde pourrait passer sur PyPy et il n'y aurait qu'une branche :D
[^] # Re: Portage de Numpy
Posté par Jux (site web personnel) . Évalué à 3.
D'ailleurs, pourquoi est-ce que ça n'arrive pas ? PyPy semble avoir l'énorme avantage de la vitesse (les benchmarks montrent des différences monstrueuses), pourquoi le développement officiel continu-t-il sur CPython ?
[^] # Re: Portage de Numpy
Posté par HardShooter . Évalué à 1.
Certains développeurs de CPython pensent que l'architecture de PyPy est trop complexe et qu'il est difficile d'y contribuer.
Il y a aussi le problème des extensions C.
[^] # Re: Portage de Numpy
Posté par Jux (site web personnel) . Évalué à 2. Dernière modification le 12 février 2012 à 22:41.
Est-il possible d'imaginer utiliser LLVM dans ce cas ? Il me semble que ça permettrait d'avoir du JIT tout en gardant une compatibilité avec les modules C.
[^] # Re: Portage de Numpy
Posté par HardShooter . Évalué à 2.
Ça a existé sous le nom d'Unladen Swallow (un fork de CPython) mais LLVM était trop buggé et limité a l'époque (je sais pas maintenant) et le code était lui aussi assez complexe, le but d'Unladen Swallow était d'être 5x plus rapide que CPython sur leurs benchmarks, PyPy le fait déjà.
PyPy a aussi un garbage collector bien plus performant que CPython et l'implémenter dans CPython serait un bordel monstre.
[^] # Re: Portage de Numpy
Posté par Yakulu . Évalué à 2.
Ne pas oublier non plus :
[^] # Re: Portage de Numpy
Posté par HardShooter . Évalué à 2.
Concernant ton premier point, le JIT pourra bientôt être activé sur ARM et PPC. Concernant le 2e, si tu désactive le JIT, PyPy consomme moins de mémoire que CPython et est un peu plus lent.
[^] # Re: Portage de Numpy
Posté par vermillon . Évalué à 1.
Désolé pour la question bête, mais "et est un peu plus lent"... que CPython ou que PyPy avec le JIT?
[^] # Re: Portage de Numpy
Posté par HardShooter . Évalué à 1.
Que CPython (je crois que ça pourrait être améliorer mais que ce n'est pas une priorité pour l'instant)
[^] # Re: Portage de Numpy
Posté par Antoine . Évalué à 2.
Quelques raisons en vrac :
- PyPy n'est pas (encore) compatible Python 3
- l'écosystème n'est pas prêt (extensions C, par exemple, ou bien la possibilité d'embarquer l'interpréteur)
- il est difficile de rentrer dans le code de PyPy (touffu, très peu documenté ni commenté, y compris RPython lui-même)
- le système de build peut rendre fou (traduire l'interpréteur en code natif prend 30 à 60 minutes, et il n'y a pas de traduction incrémentale)
[^] # Re: Portage de Numpy
Posté par HardShooter . Évalué à 1.
C'est vrai pour la chaîne d'outils mais pas pour l’interpréteur (et actuellement les développeurs CPython touchent à l’interpréteur, pas à GCC)
Il n'y a pas besoin de traduire l’interpréteur la plupart du temps, seulement pour savoir si le code peut être traduit, et le build crash dans les 5-10 premières minutes rarement après
[^] # Re: Portage de Numpy
Posté par Antoine . Évalué à 3.
Pourtant, j'ai touché à l'interpréteur et c'était un joli bordel. Le seul point qui aide un peu, c'est que l'architecture interne de l'interpréteur reprend souvent celle de CPython (mais en largement plus confus, et sans docs).
5-10 minutes d'attente après chaque modif, c'est déjà énorme (compilation incrémentale de CPython : quelques secondes, selon le fichier modifié).
Mais quand le build réussit et que l'exécutable produit crashe, c'est le pompon : 30-60 minutes de rebuild par itération.
[^] # Re: Portage de Numpy
Posté par HardShooter . Évalué à 2.
J'ai été capable d'implémenter 2 fonctionnalités de Python 3 dans PyPy sans avoir toucher a un interpréteur avant.
L’exécutable a peu de chances de crasher car on le fait tourner d'abord au dessus d'un interpréteur Python avant le build pour vérifier que tout fonctionne.
[^] # Re: Portage de Numpy
Posté par Antoine . Évalué à 0.
Tant mieux.
Fais-moi confiance, ça arrive.
[^] # Re: Portage de Numpy
Posté par wilk . Évalué à 1.
Ce sont ces points qui mériteraient un appel au don car ils ne seront jamais faits gratuitement contrairement à des choses plus motivantes... Ca rendrait pypy plus pérenne, les boites qui l'utilisent aujourd'hui y seraient sûrement sensibles.
[^] # Re: Portage de Numpy
Posté par Antoine . Évalué à 3.
C'est une idée fausse. La doc de CPython est faite entièrement par des bénévoles : http://docs.python.org/dev/
Et l'API C y est dûment documentée :
http://docs.python.org/dev/c-api/index.html
# UE
Posté par neil . Évalué à 1. Dernière modification le 13 février 2012 à 19:10.
À noter que le projet PyPy a initialement (il y a 8 ans) été financé par l'Europe, à hauteur de 1,35 millions d'euros. Donc vous avez déjà contribué, pour beaucoup d'entre vous.
# Pourquoi un enième interpréteur ?
Posté par Sylvain Colinet (site web personnel) . Évalué à -2.
Je comprend pas qu'on s'éclate à réécrire un enième interpréteur Python au lieu d'aller vers une solution comme Parrot ou LLVM ? Je peux comprendre le besoin de performance, mais pourquoi réinventer la roue tout les 5 ans ?
[^] # Re: Pourquoi un enième interpréteur ?
Posté par wilk . Évalué à 2.
Si on ne réinventait pas la roue de temps en temps on aurait des roues en bois sur les vélos ;-)
[^] # Re: Pourquoi un enième interpréteur ?
Posté par HardShooter . Évalué à 1.
Parce que Python écrit en Python c'est logique, et en plus la chaîne d'outils permet de faire des choses qui n'ont jamais été fait avant (tu peux implémenter rapidement un langage dynamique, avoir un garbage collector sans avoir a l'écrire, avoir un JIT sans avoir a l'écrire, pouvoir tout tester sans compiler).
LLVM avait déjà été tester et à l'époque les gens en charge du projet on passer plus de temps a debugger LLVM qu'a écrire un JIT pour CPython.
L’implémentation est aussi beaucoup plus flexible, je te renvoie a la doc mais les espaces d'objets sont par exemple quelque chose qu'il serait difficile d'implémenter.
Pour l'instant PyPy utilise un Global Interpreter Lock comme CPython mais il est possible que demain il utilise une STM pour avoir du vrai parallélisme, essaye d'implémenter ca sur CPython.
Essaye de changer le Garbage Collector de CPython...
CPython a été créer en 1990 avec les connaissances de l'époque (si on est gentil), et n'a pas été conçu pour évoluer, l'avantage c'est que c'est un interpréteur très simple mais qu'il est très compliqué de le mettre au goût du jour.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.