Journal Des nouvelles de PyPy

Posté par  (site web personnel) .
Étiquettes : aucune
10
7
avr.
2009
Il y a quelques jours se tenait la PyCon, grande conférence annuelle de python. Et il y avait notamment une pres sur PyPy, qui est en ligne:
http://morepypy.blogspot.com/2009/04/pycon-videos-are-online(...)

PyPy, en ce qui me concerne, après beaucoup d'enthousiasme, j'en étais resté au truc de loser. Rappelez-vous, on implémente dans un sous-langage de python un interpréteur python, et on utilise un compilateur juste à temps basé sur LLVM pour optimiser l'interpreteur PyPy qui exécute le python.

Résultats, des perf environ 10 fois plus lentes que CPython. Une démarche qui semble quand même sacrément alambiquée pour peu de résultats. En plus, le projet a été un temps financé par l'UE mais cela est fini, donc moins de monde payé pour bosser dessus.

Bon, et bien la vie n'est pas si noire que ça du côté de PyPy. En fait, ils en sont à la 3e réécriture de leur interpréteur et il semble que celle-là soit la bonne :
- ils font tourner des tests python et des applis à une vitesse similaire à celle de CPython.
- grâce à LLVM, ils peuvent faire un interpréteur qui se compile en C ou qui génère du bytecode jvm ou clr.
- leur interpréteur fait tourner pas mal d'applis réelles : django, twisted, stdlib de python, ...
- ils utilisent ctypes pour s'interfacer avec du C. Pas idéal, mais ca laisse de l'ouverture.
- sur certains tests isolés, le JIT peut permettre de faire un x20 sur la vitesse
- leur interpréteur se lance deux fois plus vite que celui de CPython
- ils ont une version stackless qui est juste une option de compilation
- la taille de leur exécutable est la moitié de l'exécutable python
- la taille des objets python est deux fois plus petite en PyPy qu'en python. Ca veut dire que des programmes qui utilisent beaucoup d'objets pourront faire des économies en RAM
- PyPy intéresse du monde dans l'embarqué, où le python de base est trop gourmand et PyPy permet une approche plus flexible, genre on dégage le GC, on enlève X et Y et on garde un petit interpréteur python. Voire on peut pas se permettre d'avoir un interpréteur et on compile direct un programme python en C


Bon, j'ai été agréablement surpris par ces nouvelles, sachant qu'il y a encore des choses à optimiser, on peut imaginer que à terme, PyPy peu réellement devenir plus rapide que CPython.

Et de l'autre côté, unladen-swallow avance tout doucement. Là, approche légèrement différente, ils modifient CPython pour générer de l'IR llvm plutôt que générer du byte code qui doit être interprété en C. A partir de l'IR llvm, pleins d'optimisations sont possibles. Les gars derrière visent en CPython x5 plus rapide. A lire la mailing list, je sais pas si ils y arriveront, mais en tout cas, c'est pas des petits joueurs. Tous les sujets sont hyper techniques.

  • # Ils vont trop loin avec leurs références...

    Posté par  . Évalué à 10.

    Pfff, ces développeurs Python sont vraiment *beaucoup* trop intoxiqués aux sketches et films des Monty Python : le mode de développement de PyPy est complétement calqué sur cette tirade extraite de "sacré graal" (Monty Python and the Holy Graal), scène 26 pour être précis :

    "
    FATHER: Listen, lad. I've built this kingdom up from nothing. When
    I started here, all there was was swamp. All the kings said I was
    daft to build a castle in a swamp, but I built it all the same,
    just to show 'em. It sank into the swamp. So, I built a second one.
    That sank into the swamp. So I built a third one. That burned down,
    fell over, then sank into the swamp. But the fourth one stayed up.
    "

    (3e réécriture, c'est donc bien la 4e version qui est l'actuelle et "la bonne")

  • # on enlève le GC ?

    Posté par  . Évalué à 1.

    euh comme il font ? comment la mémoire se libère .. parce que bon hein j ai rarement vu la ram se libérer par magie ...

    • [^] # Re: on enlève le GC ?

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

      Tu arrêtes le programme ....

      Ok je sors ---> []

    • [^] # Re: on enlève le GC ?

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

      J'imagine que c'est enlever le GC avec détection de cycles, mais garder le comptage de références.

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: on enlève le GC ?

        Posté par  . Évalué à 2.

        Pas évident, parce que PyPy implémente des GC alternatifs, qui n'ont pas besoin du comptage de référence.

        • [^] # Re: on enlève le GC ?

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

          Dans ce cas un GC est conservé...

          M'enfin, on chipote. Attendons de voir...

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: on enlève le GC ?

      Posté par  . Évalué à -1.

      En python, t'as un truc magique, ça s'appelle del.

    • [^] # Re: on enlève le GC ?

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

      euh ... il parlait d'enlever GC dans le monde de l'embarqué.
      genre un baladeur MP3 qui n'aurait pas besoin de vider sa mémoire, et qui la viderait quand tu met le baladeur sur OFF. par exemple

      • [^] # Re: on enlève le GC ?

        Posté par  . Évalué à 1.

        même un baladeur mp3 ca a besoin de vide sa mémoire de temp a aure ( en fonciton des programme qui sont dessus). si ya mémoire : ya utilisation de celle-ci et donc besoin de vidé celle qui sert plus a rien

        a moins qu'il code tous en C , ou truc du même genre sans aucun appel a malloc et ya qu'un pile qui garde les variables locale.

      • [^] # Re: on enlève le GC ?

        Posté par  . Évalué à 4.

        Embarqué et python ? C'est compatible ça ?

        Envoyé depuis mon lapin.

        • [^] # Re: on enlève le GC ?

          Posté par  . Évalué à 3.

          Ça dépend de ta définition d'embarqué ...

        • [^] # Re: on enlève le GC ?

          Posté par  (Mastodon) . Évalué à 3.

          Bien sûr !

          Embarqué ne signifie pas forcément recherche du gain absolu d'un octet, ou d'un cycle d'horloge ! Le monde de l'embarqué est vaste, et entre le baladeur mp3, le téléphone portable, la machine à laver et la voiture, il y a de la place pour à peu près toutes les technos.

          Il y en a meme qui embarquent Windows, c'est pour dire (-;

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # L'aboutissement

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

    Je ne sais plus où, j'avais lu que pour qu'un code soit bien / beau, il fallait le réécrire trois fois. Ils y sont.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # but, non ?

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

    > on peut imaginer que à terme, PyPy peu réellement
    > devenir plus rapide que CPython.

    C'était le but ... non ?
    Mais surtout, ça sera plus simple de maintenir et faire évoluer le langage python, tout en codant quasiment en python (plutôt qu'en C). (Et tout cela, en targetant n'importe quoi comme "vm" : binaire, clr, java, javascript ...)

  • # LLVM

    Posté par  . Évalué à 3.

    on implémente dans un sous-langage de python un interpréteur python, et on utilise un compilateur juste à temps basé sur LLVM pour optimiser l'interpreteur PyPy qui exécute le python.

    PyPy n'utilise plus LLVM, ils font tout à la main.

    • [^] # Re: LLVM

      Posté par  . Évalué à 4.

      Et c'est bien pour ça que unladen-swallow (utilise llvm) parait bien plus prometteur.

    • [^] # Re: LLVM

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

      Tu es sur de ton coup ? Ils n'utilisent peut-être plus le JIT de llvm, mais ils continuent à emettre de l'IR llvm non ? Ils utilisent bien llvm comme backend C, JVM ou CLR ?

      • [^] # Re: LLVM

        Posté par  . Évalué à 2.

        Tu es sur de ton coup ? Ils n'utilisent peut-être plus le JIT de llvm, mais ils continuent à emettre de l'IR llvm non ? Ils utilisent bien llvm comme backend C, JVM ou CLR ?

        Non je ne crois pas. Pour le backend C c'est gcc (mais le JIT en développement émet le code x86 à la main).
        Pour les backends JVM et CLR je n'en sais rien mais il y a des chances qu'ils émettent aussi le bytecode à la main.

        Un extrait du blog des développeurs de PyPy :
        « In the past we have looked into LLVM – at one point PyPy extensively use it but it wasn't clear how we could make good use to it. »
        http://morepypy.blogspot.com/2009/03/vm-summit-nice-to-see-f(...)

Suivre le flux des commentaires

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