URL: https://linuxfr.org/users/bluebird/journaux/des-nouvelles-de-pypy Title: Des nouvelles de PyPy Authors: Philippe F Date: 2009年04月07日T17:27:21+02:00 Tags: Score: 10 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(...)](http://morepypy.blogspot.com/2009/04/pycon-videos-are-online.html) 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.