L'interpréteur python PyPy 1.8 est sorti

Posté par . Édité par baud123, patrick_g, Nÿco, Pierre Jarillon et Malicia. Modéré par Xavier Claude. Licence CC by-sa
27
15
fév.
2012
Python

L'équipe PyPy à le plaisir de vous annoncer la sortie de la version 1.8 de PyPy. PyPy est une version différente de l'interpréteur du langage Python écrite elle-même en Python, et publiée sous licence expat. Comme à l'habitude, cette version apporte des corrections de bugs, et des améliorations concernant les performances et la consommation mémoire.

Les "list strategies" sont le principal ajout de cette version. Elles permettent de rendre les listes Python homogènes (contenant des objets du même type) plus efficaces (tant en terme de consommation mémoire que de performances).

Cette version apporte aussi la compatibilité avec Python 2.7.2. Mis à part ça, c'est "comme d'habitude", les performances ont été améliorées d'environ 10% par rapport a la version précédente.

Dans la suite de la dépêche vous trouverez une traduction des notes de version de PyPy 1.8.

Qu'est ce que PyPy

PyPy est un interpréteur Python qui se veut respectueux du standard de facto CPython 2.7, qu'il peut presque entièrement remplacer. Il est rapide grâce au compilateur juste-à-temps intégré.

Apports de cette version

  • "List strategies" : Les listes qui contiennent seulement des entiers ou des flottants sont maintenant aussi efficaces que si ils étaient stockés dans un tableau créé avec le module array, le code produit par le compilateur juste-à-temps est aussi plus efficace aux endroits où sont utilisés ces listes. Il y a aussi des stratégies particulières pour les listes contenant des chaînes de caractères ou des chaînes unicode.
  • Comme d'habitude, des améliorations de performances, trop pour les lister
  • Corrections de bugs et de compatibilité avec CPython
  • Corrections pour Windows
  • Du progrès sur l'implémentation de Numpy, pour la liste exacte des fonctionnalités implémentées, consultez la page Numpy Status
    • Tableaux multi-dimensionnels
    • Plusieurs tailles de dtypes
    • Beaucoup d'ufuncs
    • Beaucoup de changements mineurs

Le module numpy est disponible sous les noms de numpy et numpypy. En revanche, parce qu'il est incomplet, il faut d'abord importer numpypy avant d'importer des choses du module numpy

  • Nouveaux "JIT Hooks" qui permettent d'accéder au processus de compilation depuis du code Python
  • Mise-à-jour de la bibliothèque standard de 2.7.1 à 2.7.2

Travaux en cours

  • Backends ARMv7 (presque prêt) et PPC64 (en cours) en plus de x86 et x86-64
  • Plus de Numpy
  • Des instances ayants des attributs typés automatiquement
  • Depuis la version précédente, il y a eu une montée des dons pour PyPy. Nous avons maintenant assez d'argent pour lancer la première partie des travaux sur numpypy et py3k, nous voulons remercier tous ceux qui ont donné
  • Nous pensons aussi à faire un appel au dons pour avoir une Mémoire transactionnelle logicielle, vous pouvez en apprendre plus sur ce que nous prévoyons

L'équipe PyPy

  • # Petite explication

    Posté par . Évalué à 2.

    Je ne suis pas bien sûr de comprendre, pourquoi faut-il réimplémenter Numpy si PyPy est compatible avec Python 2.7.2 ? Après tout, PyPy est censé proposé la compatibilité avec tout code Python 2.7.2, alors pourquoi faut-il réimplémenter certains modules ? ou alors Numpy est particulier ?

    • [^] # Re: Petite explication

      Posté par (page perso) . Évalué à 1.

      Il n'y a pas des routines de numpy en C?

    • [^] # Re: Petite explication

      Posté par . Évalué à 2.

      C'est peut-être compatible mais pas optimal, par exemple si NumPy utilise certaines techniques liées à l'implémentation en C pour être plus performant mais qui se montrent moins efficaces avec PyPy ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Petite explication

      Posté par (page perso) . Évalué à 4.

      Numpy est écrit en grande partie en C (et en FORTRAN aussi je crois, au moins pour certaines parties).

    • [^] # Re: Petite explication

      Posté par . Évalué à 3.

      Le support des extensions C est lent car l'API C est trop proche du modèle objet de CPython et pas assez de celui de PyPy, en plus le compilateur juste-à-temps ne peut pas optimiser du code C.

      • [^] # Re: Petite explication

        Posté par . Évalué à 2.

        Ce n'est pas seulement qu'il est lent, c'est qu'il est limité et fragile (pour les mêmes raisons).

  • # Pourquoi des backends ARM??

    Posté par (page perso) . Évalué à 2.

    J'ai l'impression de passer à coté de quelque chose...
    D'après ce que j'ai cru comprendre de pypy, c'est que c'est une implémentation d'un interpréteur Python, lui-même écrit en Python (bref, le serpent qui se mord la queue... elle est facile, je sais ;-) )
    Alors ça sert à quoi un backend ARM?

  • # Lapin qu’on pri

    Posté par . Évalué à 4.

    Je comprends pas, on fait tourner un script Python sur PyPy qui tourne lui même sur un interpréteur. En gros, ça peut donner une PyCeption : Script → PyPy → PyPy → PyPy → […] → interpréteur natif :)

    • [^] # Re: Lapin qu’on pri

      Posté par . Évalué à 8.

      Comme c'est confus pour pas mal de monde je vais faire un explication globale:

      PyPy est écrit dans un sous-ensemble de Python (appelé RPython) sur lequel il est possible de réaliser de l'inférence de types, PyPy peut donc être exécuté au dessus d'un interpréteur Python (principalement pour debugger) mais aussi compilé vers du C (ou vers du bytecode Java, ou vers du bytecode CLI).

      Les principaux avantages sont :
      - Code écrit en (R)Python (avec une vitesse proche du C)
      - La mémoire est gérée automatiquement dans l'interpréteur, on peut choisir le Garbage Collector à la compilation.
      - Le compilateur juste-à-temps est automatiquement généré a partir de l'interpréteur (ce qui fait que le compilateur couvre toujours 100% du langage)

      • [^] # Re: Lapin qu’on pri

        Posté par (page perso) . Évalué à 6.

        je vais essayer d'ajouter de ma couche car, il me semble qu'il manque la description du JIT et de ses particularités.

        • RPython est un compilateur d'un sous ensemble de python
        • Pypy est un interpréteur de python écrit en RPython + un compilateur de trace (Le JIT : j'y reviens plus tard )

        RPython sert compiler Pypy pour donner PypyC (pour compilé). PypyC interprète du code python et compile des traces.

        Pypy        ---Compilo RPython--->    PypyC
        Code python ---Interpréteur PypyC---> execution du code
        
        

        La partie intéressante c'est le compilateur de trace.

        Qu'est-ce qu'un compilateur de trace ?

        Un interpréteur (Pypy) c'est globalement un grande boucle :

        while true
         charger instruction
         si intruction = addition faire
           simuler addition
         sinon si instruction = ... faire
           simuler ...
         ...
        
        

        Une trace c'est un chemin d'exécution dans un programme c'est à dire la liste des instructions qui ont été exécuté pour arriver au point courant dans le programme.

        PypyC (compilé avec RPython) quand il interprète du code python va retenir son chemin d'exécution, une trace. La trace est donc le code machine de PypyC qui vient juste d'être exécuté. Nous avons par conséquent une version compilé du code qui vient juste d'être exécuté : la trace. Quand on boucle dans le programme python, on repasse sur du code dont on possède la trace, on peut donc directement exécuter la trace (Ou plutôt une version optimisée de celle-ci). Les différentes traces (chemins d'exécution) sont fusionnées progressivement entre elles. On finit donc par avoir les parties les plus fréquemment utilisées complètement compilée.

        • [^] # Re: Lapin qu’on pri

          Posté par . Évalué à 3.

          Je chipotte mais un JIT a trace ne fusionne pas les traces, les traces sont attachées entre elles.

          Aussi si tu veux décrire le JIT faut aussi décrire ce que c'est une Guard car il ne faut pas oublier que le JIT ne compile qu'un seul chemin d'exécution, par exemple si on trace un "if" et que la partie "True" est emprunté, quand on compile il faut un moyen de dire "si le if est Faux, revenir a l'interpréteur", c'est ce qu'on appelle une Guard et c'est assez important.

  • # Une petite question sur le bootstrap

    Posté par . Évalué à 2.

    Bonjour à tous !

    Autant le bootstrap GCC je vois comment ça marche, autant avec Pypy je n'arrive pas à le conceptualiser : est-ce que CPython est toujours nécessaire pour faire fonctionner Pypy ? Sinon comment se passe le bootstrap ?

    Merci beaucoup d'avance pour vos lumières.

    • [^] # Re: Une petite question sur le bootstrap

      Posté par (page perso) . Évalué à 5.

      Sur la page wikipedia, on trouve

      PyPy est constitué de deux composants principaux :
      - un interpréteur Python, écrit lui-même en un sous-ensemble restreint de Python
      - une chaîne d'outils qui analyse ce sous-ensemble de Python (RPython), le traduit en un langage bas niveau tel que C et le compile.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Une petite question sur le bootstrap

        Posté par (page perso) . Évalué à 4.

        En complément, vu que R-Python dans lequel est exprimé PyPy est un sous-ensemble de Python, PyPy est normalement interprétable par C-Python, ce qui lui permet de se compiler lui-même (le bootstrap) et ensuite de prendre la main.

Suivre le flux des commentaires

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