Journal Appel au dons pour PyPy

Posté par  .
Étiquettes : aucune
15
11
fév.
2012

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  . Évalué à 5.

    Que signifie ceci ?

    une implémentation de Python en Python

    Ç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  (site web personnel) . Évalué à 9.

      qui fera tourner PyPy ?

      Explication : http://fr.wikipedia.org/wiki/Pypy#PyPy

      quel est l'intérêt de PyPy ?

      Ça va plus vite que CPython.

      • [^] # Re: une implémentation de Python en Python

        Posté par  . Évalué à 1.

        Ces deux composants sont indépendants

        Pas vraiment puisque la chaîne d'outils utilise l’interpréteur

        • [^] # Re: une implémentation de Python en Python

          Posté par  . É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  . É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  (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  . É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  . Évalué à 5.

    Faut donner dans une soucoupe ?

    Il se prend pour Napoléon, son état empire.

  • # STM

    Posté par  . É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  . É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  . É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  . É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  (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  . É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  (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  . É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  . Évalué à 2.

          Ne pas oublier non plus :

          • la portabilité : Pypy peut-il être installé sur des architectures exotiques ? Le JIT est-il activable partout (sans cela, le site de performance montre un Pypy moins rapide que CPython) ?
          • la consommation mémoire : bien que le site de comparaison des performances ne regarde que le temps CPU, l'empreinte mémoire a son importance. Je n'ai pas vu de chiffres officiels, mais on dirait que cela va de +50% et plus fréquemment deux à trois fois la consommation de CPython.
          • [^] # Re: Portage de Numpy

            Posté par  . É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  . É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  . É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  . É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  . Évalué à 1.

            il est difficile de rentrer dans le code de PyPy (touffu, très peu documenté ni commenté, y compris RPython lui-même)

            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)

            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)

            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  . Évalué à 3.

              C'est vrai pour la chaîne d'outils mais pas pour l’interpréteur

              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).

              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

              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  . Évalué à 2.

                Pourtant, j'ai touché à l'interpréteur et c'était un joli bordel.

                J'ai été capable d'implémenter 2 fonctionnalités de Python 3 dans PyPy sans avoir toucher a un interpréteur avant.

                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

                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  . Évalué à 0.

                  J'ai été capable d'implémenter 2 fonctionnalités de Python 3 dans PyPy sans avoir toucher a un interpréteur avant.

                  Tant mieux.

                  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.

                  Fais-moi confiance, ça arrive.

          • [^] # Re: Portage de Numpy

            Posté par  . Évalué à 1.

            • 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)

            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.

  • # UE

    Posté par  . É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  (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  . É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  . É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.