PyPy, le serpent qui se mord la queue, sort en version 0.99

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
1
22
fév.
2007
Python
PyPy est un projet financé par l'Union Européenne qui vise à écrire un interpréteur Python en Python. Le projet est sur le point d'aboutir : il n'est plus que 3x plus lent que l'implémentation de référence (CPython) avec laquelle il est compatible à 98%.

PyPy apporte de nombreuses améliorations à Python comme les « espaces d'objet », la programmation logique, la programmation concurrente, etc. Une partie de l'interpréteur Python est écrite en RPython, sous-ensemble limité de Python, ce qui permet de le compiler pour LLVM, .NET ou encore en C.

La version 0.99 apporte un backend pour la plateforme .NET, beaucoup de travail sur le backend JavaScript (AJAX fonctionne), et les derniers modules Python qui manquaient ont été écrits : mmap, signal, bz2 et fcntl.

Encore une fois, un gros travail a été fait sur l'optimisation : limitation des appels à malloc(), inlining, accélération des dictionnaires, etc. Cette version est deux fois plus rapide que la précédente, mais l'ajout du compilateur JIT devrait encore améliorer les performances de la prochaine version. La version 1.0 finale incorporera tous les projets de recherche de PyPy :
  • Un compilateur JIT qui devrait encore améliorer les performances. Il n'a pas été intégré à la version 0.99 car il ne donnait pas les résultats escomptés.
  • Des extensions au parseur permettant de modifier la grammaire de Python. En particulier, on pourra facilement ajouter à Python des notions de programmation orientée aspect et de programmation par contrat.
  • L'espace d'objet logique qui offre des variables logiques (à la manière de Prolog) et un résolveur de contrainte.

Ce n'est pas un effet d'annonce, le code existe et fonctionne, mais soit le code n'est pas assez testé, soit il est encore mal intégré au projet PyPy.

Aller plus loin

  • # un très bon exemple

    Posté par  (site web personnel) . Évalué à 6.

    pour ceux que ça interesse, il y a une petite manip décrite ici qui permet d'effleurer les possibilités de pypy :

    http://programming.reddit.com/info/152lr/comments/c156v0

    Moi ce projet, il me fait délirer. Et le gain qu'il va apporter à python est incommensurable ...

    • [^] # Re: un très bon exemple

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Tu peux m'expliquer et me donner des exemples de ce que ça va apporter ? Personnellement, je trouve ça chouette comme recherche théorique, mais je ne vois pas d'intérêt direct en fait. (j'ai pas approfondi non plus)

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: un très bon exemple

        Posté par  (site web personnel) . Évalué à 5.

        J'étais justement en train de poster un commentaire similaire.

        Les choses sont expliquées ici, mais je n'ai jamais lu de vulgarisation bien faite.
        http://codespeak.net/pypy/dist/pypy/doc/architecture.html#mi(...)

        On entend juste « implémentation de python en python ». Après une introduction comme ça, 1% des gens vont prendre la peine de creuser un peu pour découvrir ce que ça apporte.

      • [^] # Re: un très bon exemple

        Posté par  (site web personnel) . Évalué à 6.

        oui, j'ai aussi beaucoup de mal à cerner la bête ... même après la lecture (ultra interessante) du site de pypy ...

        Le premier gros apport, c'est facilité la maintenance/evolution de python. Python est codé en C, et l'ajout de fonctionnalités/evolutions commence à devenir un petit cauchemar dans certains cas. Le fait de pour coder python, en python va énormément simplifier la maintenance/evolution du language.
        Un autre apport, c'est la couche basse "rpython", si j'ai bien compris. Tout en programmant en python, on pourra targetter ... soit du C, soit du .Net, soit du javascript (d'autres devrait suivre, pk il suffit de faire les traductions "rpython -> destination").
        Développer une appli web entièrement en python, qui fabriquera le code JS/ajax coté client est déjà une réalitée ( http://play1.codespeak.net:8008/ )
        Une fois la VM bien rodé, d'autres languages (ruby par exemple, en fabriquant le traducteur ruby->rpython) pourrait générer du python, du c, du .net ou autres ... bref, le début d'une VM communautaire (ala CLR)
        (Et je crois qu'il y a aussi l'idée de réduire le runtime au minimum)

        Voilà ce que j'ai un peu prêt compris ...

        • [^] # Re: un très bon exemple

          Posté par  . Évalué à 2.

          Il y a beaucoup de confusion à propos de pypy, Beaucoup pensent que pypy va permettre de convertir de code python en C, mais ce n'est pas le cas, il ne permet que de convertir du code Rpython en d'autre language et selon les développeur de pypy (en tous cas ceux qui était sur #pypy sur freenode quand je me suis informé), Coder en Rpython est plutôt chiant et celui-ci n'est destiné qu'à coder Python en Rpython et non coder des applications...

        • [^] # Re: un très bon exemple

          Posté par  (site web personnel) . Évalué à 5.

          Le premier gros apport, c'est facilité la maintenance/evolution de python. Python est codé en C, et l'ajout de fonctionnalités/evolutions commence à devenir un petit cauchemar dans certains cas.

          De par sa nature très modulaire, PyPy permet également des changements majeurs dans l'implémentation de Python. CPython utilise par exemple un ramasse miette à générations. C'est un choix, mais PyPy en permet d'autres, ce qui permet de comparer les performances et de choisir une alternative qui serait plus rapide dans un cas précis. D'ailleurs, PyPy a déjà des outils pour supprimer des malloc().

          La mémoire n'était qu'un exemple, mais la gestion des processus concurrents est également remise en question : thread, greenlets, proxy d'objet fonctionnant sur réseau, clonage de générateur... PyPy apporte encore une fois un air frais dans ce domaine.

          Et alors que CPython n'optimise peu ou pas, PyPy fait de l'inlining, a un annotateur de type, permet de compiler dans de nombreux langages, etc. Il offre la possibilité d'optimisations très complexes qui seraient impossibles avec CPython.

          • [^] # Re: un très bon exemple

            Posté par  (site web personnel) . Évalué à 7.

            Le site web de pypy est out en ce moment, mais dans mon souvenir, le principal intérêt de pypy est d'avoir une espèce de générateur d'interpréteur python.

            Au lieu d'avoir un interpreteur python avec des fonctionnalités édictées une fois pour toute dans la spec, on pourrait "faire ses courses" en terme de fonctionnaliteset générer un interpréteur sur mesure.

            Cela permet de modifier la grammaire de python pour des projets dédiés (programmation oriente aspect, programmation par contrat sont les exemples cités, mais on peut en trouver d'autres). On garde donc les principes de base du langage python, mais les fonctionnalités sont extensibles à merci.

            J'avais posé une question à l'époque sur la faisabilité d'une inférence de type à la ocaml. C'est là qu'on m'a renvoyé vers pypy où ce genre de chose est envisageable (meme si je ne crois pas que ce soit au programme pour l'instant).

            En ce qui me concerne, ce qui m'intéresserait à l'heure actuelle, ce serait une réduction de fonctionnalité : dans la façon dont j'utilise python, le typage dynamique me crée plus de problèmes qu'il n'en résoud. Je préfererai avoir un typage statique, ou en tout cas, l'interdiction a une variable de changer de type au cours de son existence. C'est possible grâce à pypy.

            Maintenant, les inconvénients : d'une part, c'est quand même beaucoup plus lent, alors que python n'est déjà pas renommé pour sa vitesse. Ensuite, ça veut dire qu'on va peut-être récuperer des softs qui ne marchent qu'avec un certain jeu de fonctionnalité de l'interpréteur python, et qu'ils seront incompatibles avec d'autres softs utilisant un jeu de fonctionnalité différent.

        • [^] # Re: un très bon exemple

          Posté par  (site web personnel) . Évalué à 5.

          > bref, le début d'une VM communautaire

          Cela existe déjà, cela s'appelle Parrot. C'est une machine orienté pour les langages de script contrairement à la JVM et à .Net.

          http://www.parrotcode.org/

      • [^] # Re: un très bon exemple

        Posté par  (site web personnel) . Évalué à 10.

        L'intérêt est évident : Si a force d'optimisation PyPy devient plus rapide que CPython, il suffira de lancer PyPy sous PyPy pour qu'il soit encore plus rapide. Et ainsi de suite, on peux tendre vers un temps d'exécution nul en empilant les PyPy.

        C'est méga-prometteur quoi !

        • [^] # Re: un très bon exemple

          Posté par  . Évalué à -9.

          S'il est plus rapide que CPython, il est plus rapide que CPython, point.

          Je ne vois pas pourquoi lancer plusieurs fois pypy sur lui même le rendrait plus rapide

  • # Et pour Caml ?

    Posté par  . Évalué à 10.

    Maintenant que PyPy est sur la bonne voie, est-ce que l'équivalent va être écrit pour Caml ?

    Le jour ou l'UE aura financé PyPy et CaCa, on peut dire que la boucle sera alors bouclée.

    Uhm, ok ... --> []

    • [^] # Re: Et pour Caml ?

      Posté par  (site web personnel) . Évalué à 4.

      Hihi..

      En l'occurence le compilo Caml est bootstrapé depuis le début (dès Caml Light). Le runtime est écrit en C, mais la complexité bytecode Caml n'a rien à voir avec Python et même RPython.

      L'avantage principal de cette approche est la maintenabilité -- écrire un compilo en Caml est inifiniment plus agréable qu'en C à mon gout. Accessoirement, ça assure que les gens qui écrivent le compilo programment dans le langage de destination, et s'impliquent donc sur sa qualité...

      Pour finir, je suis déçu de lire que RPython est inutilisable. Quand j'ai appris l'existence de RPython je me suis dit que les Pythoneux découvraient enfin les horreurs cachées de leur langage et les écartaient en créant un sous-ensemble propre, RPython. Visiblement ce n'est pas le cas.

      • [^] # Re: Et pour Caml ?

        Posté par  . Évalué à 1.

        euh, pourquoi inutilisable ?

        RPython reste infiniment plus agréable que du C en tous cas. C'est un langage jeune, car il a moins de deux ans d'âge, alors il faut un peu d'indulgence ... :)

    • [^] # Re: Et pour Caml ?

      Posté par  . Évalué à 10.

      oui, c'est de la Programmation Objet en Programmation Objet (PoPo), on a ainsi PyPy, CaCa et PoPo.

      ---> (oui je sais, commentaire de chiotte...)

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Et pour Caml ?

      Posté par  (site web personnel) . Évalué à 2.

      Non, il faudra un papier qui couvre ce qui a été fait.

    • [^] # Re: Et pour Caml ?

      Posté par  (site web personnel) . Évalué à 2.

      Déjà qu'il paraît que le java est durétique :-/

  • # Lent ...

    Posté par  . Évalué à 1.

    il n'est plus que 3x plus lent que l'implémentation de référence (CPython)

    Ca parait quand même enorme comme différence de preformance, même avec l'interpreteur JIT je ne sais pas si ils arriveront a rattraper un tel retard ... cela ne seras t il pas un frein a son adoption ?

    • [^] # Re: Lent ...

      Posté par  (site web personnel) . Évalué à 4.

      > si ils arriveront a rattraper un tel retard

      Il y a qques temps pypy était 20x plus lent que cpython ...

      Mais si tu peut generer du C (et donc du binaire après coup) à partir d'un source python ... comme c'est un peu décrit ici :
      http://programming.reddit.com/info/152lr/comments/c156v0

      Et obtenir des performances 70 à 100x supérieur à cpython, le jeu en vaut la chandelle.

      • [^] # Re: Lent ...

        Posté par  . Évalué à 3.

        Hé mais, dans ce cas, on pourra compiler pypy en C avec lui même et obtenir une VM python en C qu'on compilera pour obtenir un binaire qui rox dans l'exécution des programmes pythons.

        C'est fou ce qu'on peut s'embrouiller avec tout ça.

    • [^] # Re: Lent ...

      Posté par  (site web personnel) . Évalué à 2.

      CPython ne permet pas de faire de la programmation logique et Stackless Python est moins poussé en programmation concurrente. PyPy apporte également la fonctionnalité de « clonage de générateur », outil très utile dans le calcul distribué. Et on pourrait encore trouver une longue liste de fonctionnalités qu'apporte PyPy.

      Le problème des performances va peu à peu s'effacer et je pense qu'à terme PyPy sera plus rapide.

      • [^] # Re: Lent ...

        Posté par  . Évalué à 1.

        On transforme de l'interprété en compilé, c'est bien pour nos micros ça ! De quoi peut-être redonner vie au BASIC :)

    • [^] # Re: Lent ...

      Posté par  . Évalué à 1.

      1- il y a environ un an pypy était cent ou deux cents fois plus lent que cpython
      2- pypy est pour l'instant lancé avec cpython, donc il est forcément plus lent :)

      (corrigez moi si je me trompe, pour le 2- :)

      • [^] # Re: Lent ...

        Posté par  (site web personnel) . Évalué à 3.

        2- pypy est pour l'instant lancé avec cpython, donc il est forcément plus lent :)

        Non, c'était justement quand PyPy était interprété par CPython qu'il était plusieurs centaines de fois plus lent. Maintenant PyPy est traduit en C puis compilé par gcc pour arriver à être "à peine" 3x plus lent que CPython. La page suivante présente les perfs selon le mode de compilation (C, LLVM, etc.) :
        http://tuatara.cs.uni-duesseldorf.de/benchmark.html

        PyPy .NET est 70x plus lent que CPython :-p

  • # What's in a name

    Posté par  . Évalué à -2.

    Tout ça pour pisser du code...

  • # Question de profane total

    Posté par  . Évalué à 2.

    De ce que je viens de lire au sein des commentaires,

    ceci servirait notamment à convertir un code d'un langage en un autre.

    Existe-t-il un programme qui pourrait convertir tous ces langages de programmation (C, python, etc...) en assembleur (le langage, finalement dit le plus proche de la machine ?).

    Juste une question candide.
    Ne vous déchaînez pas sur moi :)

    • [^] # Re: Question de profane total

      Posté par  . Évalué à 10.

      Tous je ne sais pas mais un bon paquet oui, ce logiciel existe. Son nom : http://gcc.gnu.org/ .

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Question de profane total

        Posté par  . Évalué à 4.

        Merde....question de buse, désolé, je viens de revoir la définition de compilateur...

        Mais alors dans ce cas, quel est l'intérêt de programmer directement en assembleur ?

        • [^] # Re: Question de profane total

          Posté par  . Évalué à 4.

          Bonjour,

          Parfois le compilateur n'arrive pas à optimiser le code assembleur de la même façon qu'un humain l'aurais produit. La programmation en assembleur a aussi existé avant l'arrivée des compilateurs. On remarquera que les erreurs sont vites arrivées et que la maintenance du code est quasi-nulle ...

          Après l'intérêt peut-être pédagogique... ou pour développer des compilateurs (bien qu'ils soient souvent développés dans un autre langage plus haut niveau).

        • [^] # Re: Question de profane total

          Posté par  . Évalué à 6.

          En général sur PC c'est un mode de fonctionnement qui à été abandonné depuis quelques temps. Dans mon cas (soft embarqué avec des petits micro 8 ou 16bits) la régle est
          -Le micro passe 80% de sont temps dans 20% du code

          c'est généralement vrai, donc l'optimisation ultime est d'identifier les 20% de code et de ré-écrire ces 20% en assembleur permet d'obtenir des resultats bluffants (j'ai deja vu des 400% de gains de temps de traitement).Il est tres simple d'interfacer l'assembleur avec le C (mais il faut s'astreindre à une version particulière de compilateur pour ne pas avoir de surprise).

          Le langage C est tres proche du materiel, avec une bonne habitude de ton compilateur tu peut prevoir comment il traduira en assembleur ce que tu est en train d'ecrire et produire un code avec une bonne optimisation de base.

          • [^] # Re: Question de profane total

            Posté par  . Évalué à 2.

            En complément de ces précisions, je tiens à faire de la pub pour MenuetOS, écrit en assembleur et qui tient sur une disquette apparemment :

            http://www.menuetos.net/

          • [^] # Re: Question de profane total

            Posté par  . Évalué à 2.

            Et j'ajouterai que parfois, il y a des bouts de code pour lesquels on n'a pas forcement envie de voir un compilo essayer d'optimiser, et ou l'on veut decider exactement ce que fait la machine.
            Genre un bootloader sur TigerSharc qui tient en 256 instructions max et doit finir par lancer un DMA pour se remplacer par le vrai executable puis enchainer par un branch a l'adresse qui va bien.

  • # Impossible?

    Posté par  . Évalué à 0.

    Ce projet et les objectifs annoncés semblent déments... En effet, nous apprenons dès nos début en programmation que plus un langage est "haut niveau" et plus ses performances sont dégradées (en général). De la même façon, nous apprenons (et vérifions) que les langages interprétés sont généralement plus lents que les langages compilés. Les objectifs de ce projet, s'ils sont atteints, viendraient bousculer notre conception de la programmation "efficace".
    Par ailleurs, cela fait quelques temps que Python et Scipy/Numpy est utilisable pour faire de la simulation numérique. À présent, on peut espérer voir un interpréteur Python optimisé pour le calcul massivement parallèle, ou encore avec des déclarations de type évoluées.
    Python est de plus en plus prometteur, et ça faire plaisir de voir de l'argent européen investit dans un tel projet.

    En résumé: Python, c'est bon!

    • [^] # Re: Impossible?

      Posté par  . Évalué à 2.

      le probleme c'est que scipy/numpy c'est du CPython uniquement et vu la quantite de boulot fournit par Travis Oliphant pour faire ca ca risque de pas etre simple de reoptimiser en pure python... surtout que la tendance est de transformer en C les partis en python pour accelerer la chose.

      • [^] # Re: Impossible?

        Posté par  . Évalué à 2.

        Ah bon?
        Tu veux dire que les extensions en C ne seront pas utilisable avec un interpréteur PyPy construit en C par PyPy lui-même? Pourquoi est-ce que du C ne serait pas compatible avec du C?

        Je m'emmèle peut-être les pinceaux, mais moi ce que j'ai compris c'est que PyPy permet de fabriquer le code C d'un interpréteur Python lui même très rapide pour l'interprétation du code Python. Après, les extensions en C, ben ça reste du C.
        A la fin, un interpréteur Python, c'est capable d'utiliser des modules C ou Fortran, ou autre. C'est justement la force de Python. Je vois pas pourquoi ils s'en passeraient.

        • [^] # Re: Impossible?

          Posté par  . Évalué à 2.

          c'est moi qui est pas du comprendre ce qu'etait pypy, j'avais compris que c'etait une implementation de python en python. Comme ironpython l'etait en C#, jython en java et Cpython en C. Maintenant j'ai peut etre compris de travers...

        • [^] # Re: Impossible?

          Posté par  (site web personnel) . Évalué à 3.

          oui mais les extensions elles utilisent l'api CPython, celle qui est décrite là http://docs.python.org/api/api.html et qui n'est bien sur pas celle utilisée par pypy, donc vraisemblablement tout sera à refaire..

    • [^] # Re: Impossible?

      Posté par  . Évalué à 2.

      En fait si j'ai bien compris c'est comme pour la JVM:
      ce qui est le plus prometteur c'est le JIT, car ça permet de compiler le code en effectuant des optimisation que l'on ne peux pas faire avec les langages compilés classiques (qui génère du code objet).
      Comme par exemple de compiler avec des optimisation spécifique à la machine et à l'OS, ou la prévision des branchements, en utilisant des infos disponible à l'exécution.

    • [^] # Re: Impossible?

      Posté par  . Évalué à 4.

      En effet, nous apprenons dès nos début en programmation que plus un langage est "haut niveau" et plus ses performances sont dégradées (en général).
      Gnome est lent, ils auraient du coder en assembleur :)
      Plus serieusement, plus le langage est bas niveau, plus il est possible de faire un truc hyper performant ou un truc mega lent (si on loupe des optimisations qu'un compilo aurait vu).

      De la même façon, nous apprenons (et vérifions) que les langages interprétés sont généralement plus lents que les langages compilés.
      Avec la compilation JIT, les langages interprétés doivent pouvoir etre plus rapide que leur equivalent compilé dans certains cas.
      Voir par exemple un scaler compilé en JIT, plus rapide que son equivalent C compilé statiquement : http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/42975

      • [^] # Re: Impossible?

        Posté par  (site web personnel) . Évalué à 1.

        Avec la compilation JIT, les langages interprétés doivent pouvoir etre plus rapide que leur equivalent compilé dans certains cas.

        Hum, je pense que ce n'est sûrement pas vrai dans tous les cas. Je pense plutôt qu'étant donné qu'un programme Python est bien plus court (en nombre de lignes), on peut passer plus de temps à réécrire l'algorithme / faire des tests.

  • # Ca c'est une révolution

    Posté par  . Évalué à -5.

    "Le projet est sur le point d'aboutir : il n'est plus que 3x plus lent que l'implémentation de référence (CPython) "

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.