Question Pourquoi ne devrais-je pas utiliser PyPy sur CPython si PyPy est 6,3 fois plus rapide?


J'ai beaucoup entendu parler de la PyPy projet. Ils prétendent qu'il est 6,3 fois plus rapide que le CPython interprète sur leur site.

Chaque fois que nous parlons de langages dynamiques comme Python, la vitesse est l'un des principaux problèmes. Pour résoudre ce problème, ils disent que PyPy est 6,3 fois plus rapide.

Le deuxième problème est le parallélisme, le tristement célèbre Global Interpreter Lock (GIL). Pour cela, PyPy le dit peut donner Python sans GIL.

Si PyPy peut résoudre ces grands défis, quelles sont ses faiblesses qui empêchent une adoption plus large? C'est-à-dire, ce qui empêche quelqu'un comme moi, un développeur typique de Python, de passer à PyPy maintenant?


598
2017-09-22 17:24


origine


Réponses:


  1. PyPy, comme d'autres l'ont rapidement mentionné, a support ténu pour les extensions C. Il a support, mais typiquement à des vitesses plus lentes que Python et c'est au mieux incertain. D'où beaucoup de modules simplement exiger CPython. Cython et Numpy sont impressionnant pour les nombres, et la plupart des gens qui ont vraiment besoin de la vitesse en Python utilisent ces (+ Pandas, SciPy, etc.) fortement. Comme ils sont soit inexistants ou ténuement supportés et lents les gens qui ont besoin d'un Python rapide sont souvent mieux avec CPython à la fois pour la rapidité et la facilité d'utilisation.
  2. Python 3 support est expérimental pour le moment.  vient d'atteindre stable! Au 20 juin 2014, PyPy3 2.3.1 - Fulcrum est sorti!
  3. PyPy parfois n'est pas en fait plus rapide pour les "scripts", pour lesquels beaucoup de gens utilisent Python. Ce sont les programmes à court terme qui font quelque chose de simple et de petit. Parce que PyPy est un compilateur JIT, ses principaux avantages viennent des temps longs et des types simples (tels que les nombres). Franchement, Les vitesses pré-JIT de PyPy sont plutôt mauvaises par rapport à CPython.
  4. Inertie. Passer à PyPy nécessite souvent un réoutillage qui, pour certaines personnes et organisations, est simplement trop de travail.

Ce sont les principales raisons qui m'affectent, je dirais.

REMARQUE: Cette question est ancienne! Évitez de tirer des conclusions à partir d'informations périmées.


603
2017-09-22 17:40



Ce site ne ne pas réclamation PyPy est 6,3 fois plus rapide que CPython. Citer:

La moyenne géométrique de tous les benchmarks est 0.16 ou 6.3 fois plus rapide que CPython

C'est un très déclaration différente à la déclaration générale que vous avez faite, et quand vous comprenez la différence, vous comprendrez au moins une série de raisons pour lesquelles vous ne pouvez pas simplement dire «utiliser PyPy». Il peut sembler que je suis en train de choisir, mais comprendre pourquoi ces deux affirmations sont totalement différentes est vital.

Pour décomposer:

  • La déclaration qu'ils font ne s'applique qu'aux points de référence qu'ils ont utilisés. Il ne dit absolument rien de votre programme (sauf si votre programme est exactement le même que l'un de leurs repères).

  • La déclaration concerne un moyenne d'un groupe de benchmarks. Il n'y a aucune prétention que l'exécution de PyPy donnera une amélioration de 6,3 fois même pour les programmes qu'ils ont testés.

  • Il n'y a aucune prétention que PyPy exécutera même tous les programmes que CPython exécute du tout, encore moins vite.


94
2017-09-22 21:42



Parce que pypy n'est pas 100% compatible, prend 8 gigs de ram pour compiler, est une cible mouvante, et hautement expérimentale, où cpython est stable, la cible par défaut pour les constructeurs de modules pendant 2 décennies (y compris les extensions c qui ne fonctionnent pas sur pypy ), et déjà largement déployé.

Pypy ne sera probablement jamais l'implémentation de référence, mais c'est un bon outil à avoir.


67
2017-09-22 17:27



La deuxième question est plus facile à répondre: vous essentiellement pouvez utilisez PyPy comme remplacement si tout votre code est pur Python. Cependant, de nombreuses bibliothèques largement utilisées (y compris une partie de la bibliothèque standard) sont écrites en C et compilées en tant qu'extensions Python. Certains d'entre eux peuvent être conçus pour fonctionner avec PyPy, d'autres non. PyPy fournit le même outil "orienté vers l'avant" que Python --- c'est à dire, c'est Python --- mais ses entrailles sont différentes, donc les outils qui interfacent avec ces entrailles ne fonctionneront pas.

En ce qui concerne la première question, j'imagine que c'est une sorte de Catch-22 avec le premier: PyPy a évolué rapidement dans le but d'améliorer la vitesse et d'améliorer l'interopérabilité avec d'autres codes. Cela l'a rendu plus expérimental qu'officiel.

Je pense qu'il est possible que si PyPy entre dans un état stable, il puisse commencer à être plus largement utilisé. Je pense aussi que ce serait génial pour Python de s'éloigner de ses sous-jacents C. Mais cela n'arrivera pas pendant un moment. PyPy n'a pas encore atteint la masse critique où il est presque assez utile en soi pour faire tout ce que vous voulez, ce qui motiverait les gens à combler les lacunes.


34
2017-09-22 17:31



Q: Si PyPy peut résoudre ces grands défis (vitesse, consommation de mémoire, parallélisme) par rapport à CPython, quelles sont ses faiblesses qui empêchent une adoption plus large?

R: Premièrement, il y a peu de preuves que l'équipe PyPy puisse résoudre le problème de vitesse en général. Les preuves à long terme montrent que PyPy exécute certains codes Python plus lentement que CPython et que cet inconvénient semble être profondément ancré dans PyPy.

Deuxièmement, la version actuelle de PyPy consomme beaucoup plus de mémoire que CPython dans un assez grand nombre de cas. Alors PyPy n'a pas encore résolu le problème de consommation de mémoire.

Si PyPy résout les grands défis mentionnés et en général être plus rapide, moins gourmand en mémoire et plus favorable au parallélisme que CPython est une question ouverte qui ne peut être résolue à court terme. Certaines personnes parient que PyPy ne sera jamais en mesure d'offrir un général solution lui permettant de dominer CPython 2.7 et 3.3 dans tous les cas.

Si PyPy réussit à être meilleur que CPython en général, ce qui est discutable, la principale faiblesse affectant son adoption plus large sera sa compatibilité avec CPython. Il existe également des problèmes tels que le fait que CPython fonctionne sur une plus grande gamme de processeurs et de systèmes d'exploitation, mais ces problèmes sont beaucoup moins importants par rapport aux performances de PyPy et aux objectifs de compatibilité avec CPython.


Q: Pourquoi je n'arrive pas à remplacer CPython par PyPy maintenant?

R: PyPy n'est pas compatible à 100% avec CPython car il ne simule pas CPython sous le capot. Certains programmes peuvent toujours dépendre des caractéristiques uniques de CPython qui sont absentes dans PyPy telles que les liaisons C, les implémentations C de l'objet et des méthodes Python, ou la nature incrémentale du garbage collector de CPython.


14
2017-09-23 11:32



J'ai fait un petit benchmark sur ce sujet. Alors que beaucoup d'autres affiches ont fait de bons points au sujet de la compatibilité, mon expérience a été que PyPy n'est pas beaucoup plus rapide pour simplement se déplacer autour des bits. Pour beaucoup d'utilisations de Python, il n'existe réellement que pour traduire des bits entre deux ou plusieurs services. Par exemple, peu d'applications Web effectuent une analyse intensive des ensembles de données. Au lieu de cela, ils prennent des octets d'un client, les stockent dans une sorte de base de données et les retournent ensuite à d'autres clients. Parfois, le format des données est modifié.

Les développeurs BDFL et CPython sont un groupe remarquablement intelligent et ont réussi à aider CPython à exceller dans un tel scénario. Voici un blogue impudique: http://www.hydrogen18.com/blog/unpickling-buffers.html . J'utilise Stackless, qui est dérivé de CPython et conserve l'intégralité de l'interface du module C. Je n'ai trouvé aucun avantage à utiliser PyPy dans ce cas.


13
2017-09-22 19:02



CPython a le comptage des références et la collecte des ordures, PyPy a le garbage collection seulement.

Ainsi, les objets ont tendance à être supprimés plus tôt et __del__ est appelé d'une manière plus prévisible dans CPython. Certains logiciels s'appuient sur ce comportement, ils ne sont donc pas prêts pour la migration vers PyPy.

Certains autres logiciels fonctionnent avec les deux, mais utilisent moins de mémoire avec CPython, car les objets inutilisés sont libérés plus tôt. (Je n'ai aucune mesure pour indiquer à quel point cela est important et quels autres détails d'implémentation affectent l'utilisation de la mémoire.)


8
2017-09-22 23:01