Pourquoi ne devrais-je pas utiliser PyPy sur CPython si PyPy est 6,3 fois plus rapide?
J'ai beaucoup entendu parler du projet PyPy . Ils affirment qu'il est 6,3 fois plus rapide que l'interprète CPython sur leur site .
Quand on parle de langages dynamiques comme Python, la vitesse est l’un des problèmes majeurs. Pour résoudre ce problème, ils disent que PyPy est 6,3 fois plus rapide.
Le deuxième problème concerne le parallélisme, l’infâme Global Interpreter Lock (GIL). Pour cela, PyPy le dit peut donner Python sans GIL .
Si PyPy peut résoudre ces grands problèmes, quelles sont ses faiblesses qui empêchent une adoption plus large? C'est-à-dire qu'est-ce qui empêche quelqu'un comme moi, un développeur typique de Python, de passer à PyPy maintenant ?
- PyPy, comme d’autres ont été prompts à le mentionner, a un support ténu pour les extensions C . Il prend en charge , mais généralement à une vitesse inférieure à celle de Python et il est au mieux douteux. Par conséquent, beaucoup de modules exigent simplement CPython. Cython et Numpy sont géniaux pour les nombres, et la plupart des gens qui ont réellement besoin de vitesse en Python utilisent beaucoup ceux-ci (+ Pandas, SciPy, etc.). Étant donné qu’ils sont inexistants ou mal pris en charge et lents , ceux qui ont besoin d’un service rapide Python sont souvent mieux traités avec CPython, à la fois pour leur rapidité et leur facilité d’utilisation. .
- Support de Python 3
est expérimental pour le moment.vient d'atteindre l'écurie! A partir du 20 juin 2014, PyPy3 2.3.1 - Fulcrum is out ! - PyPy parfois n'est pas réellement plus rapide pour les "scripts", pour lesquels beaucoup de gens utilisent Python pour. Ce sont les programmes à court terme qui font quelque chose de simple et de petit. PyPy étant un compilateur JIT, ses principaux avantages proviennent de durées de traitement longues et de types simples (tels que les nombres). Franchement, les vitesses de pré-JIT de PyPy sont plutôt mauvaises par rapport à CPython.
- Inertie . Passer à PyPy nécessite souvent un réoutillage, ce qui représente, pour certaines personnes et certaines organisations, tout simplement trop de travail.
Ce sont les principales raisons qui me touchent, je dirais.
NOTE: Cette question est ancienne! Évitez de tirer des conclusions d'informations obsolètes.
Ce site ne pas affirme que PyPy est 6,3 fois plus rapide que CPython. Citer:
La moyenne géométrique de tous les points de repère est 0,16 ou 6,3 fois plus rapide que CPython
Il s’agit d’une déclaration très différente de la déclaration générale que vous avez faite et, lorsque vous comprenez la différence, vous comprenez au moins un ensemble de raisons pour lesquelles vous ne pouvez pas simplement dire "utilisez PyPy". Cela peut sembler être une énigme, mais il est essentiel de comprendre pourquoi ces deux déclarations sont totalement différentes.
Pour décomposer cela:
La déclaration qu'ils font ne s'applique qu'aux points de repère qu'ils ont utilisés. Cela ne dit absolument rien sur votre programme (à moins que votre programme ne soit exactement identique à l'un de leurs points de repère).
La déclaration concerne un moyenne d'un groupe de points de repère. Rien ne permet d'affirmer que l'exécution de PyPy entraînera une amélioration de 6,3 fois, même pour les programmes testés.
Il n’est pas permis d’affirmer que PyPy exécutera même tous les programmes exécutés par CPython du tout, et encore moins plus rapidement.
Parce que pypy n’est pas compatible à 100%, il faut 8 Go de RAM pour la compiler, est une cible mobile et très expérimentale, où cpython est stable, la cible par défaut des 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.
Il est plus facile de répondre à la deuxième question: vous avez fondamentalement can == utilisez PyPy comme solution de remplacement si tout votre code est en pur Python. Cependant, de nombreuses bibliothèques largement utilisées (y compris certaines des bibliothèques standard) sont écrites en C et compilées sous la forme d'extensions Python. Certains d'entre eux peuvent fonctionner avec PyPy, d'autres non. PyPy fournit le même outil "orienté vers l’avant" que Python --- c’est-à-dire qu’il s’agit de Python ---, mais ses entrailles sont différentes, de sorte que les outils qui interagissent avec ces entrailles ça marche pas.
En ce qui concerne la première question, j’imagine que c’est une sorte de piège avec la première: PyPy évolue rapidement dans le but d’accroître 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 commence à être utilisé plus largement. Je pense aussi que ce serait bien que Python s'éloigne de ses bases en C. Mais cela n'arrivera pas avant un moment. PyPy n'a pas encore atteint la masse critique où il est presque == suffisamment utile pour faire tout ce que vous voulez, ce qui inciterait les gens à combler les lacunes.
J'ai fait un petit repère sur ce sujet. Bien que de nombreuses autres affiches aient bien exposé la compatibilité, mon expérience a été que PyPy n’est pas si rapide que ça. Pour de nombreuses utilisations de Python, il n'existe en réalité que la traduction de bits entre deux services ou plus. Par exemple, peu d'applications Web effectuent une analyse intensive des ensembles de données par le processeur. Au lieu de cela, ils prennent des octets d'un client, les stockent dans une sorte de base de données et les renvoient ensuite à d'autres clients. Parfois, le format des données est modifié.
Les développeurs BDFL et CPython forment un groupe de personnes remarquablement intelligent et ont réussi à aider CPython à exceller dans un tel scénario. Voici une fiche de blog sans vergogne: http://www.hydrogen18.com/blog/unpickling-buffers.html . J'utilise Stackless, qui est dérivé de CPython et conserve l'interface complète du module C. Je n'ai trouvé aucun avantage à utiliser PyPy dans ce cas.
Q: Si PyPy peut résoudre ces grands problèmes (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 existe peu de preuves que l’équipe PyPy puisse résoudre le problème de vitesse en général . Des preuves à long terme montrent que PyPy exécute certains Python codes plus lentement que CPython et 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. Donc, PyPy n'a pas encore résolu le problème de consommation de mémoire.
Que PyPy résolve les grands défis mentionnés et en général soit plus rapide, moins gourmand en mémoire et plus respectueux du parallélisme que CPython est une question ouverte qui ne peut être résolue à court terme. Certains parient que PyPy ne pourra jamais offrir une solution générale 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 qui affectera son adoption plus large sera sa compatibilité avec CPython. Il existe également des problèmes tels que le fait que CPython s’exécute sur un plus grand nombre de processeurs et de systèmes d’exploitation, mais ces problèmes sont beaucoup moins importants par rapport aux objectifs de performance et de compatibilité CPython de PyPy.
Q: Pourquoi ne puis-je pas remplacer maintenant CPython par PyPy?
R: PyPy n'est pas compatible à 100% avec CPython, car il ne simule pas CPython sous le capot. Certains programmes peuvent encore dépendre des fonctionnalités uniques de CPython absentes de PyPy, telles que les liaisons C, les implémentations C de Python objet & méthodes ou la nature incrémentielle du collecteur de déchets de CPython.
CPython a un comptage de références et une récupération de place, PyPy ne dispose que de la récupération de place.
Ainsi, les objets ont tendance à être supprimés plus tôt et __del__ est appelé de manière plus prévisible dans CPython. Certains logiciels reposent sur ce comportement et 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 son importance et quels autres détails d'implémentation affectent l'utilisation de la mémoire.)
J'ai trouvé des exemples, où PyPy est plus lent que Python. Mais: uniquement sous Windows.
C:\Users\User>python -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 294 msec per loop
C:\Users\User>pypy -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 1.33 sec per loop
Donc, si vous pensez à PyPy, oubliez Windows. Sous Linux, vous pouvez obtenir des accélérations impressionnantes. Exemple (liste tous les nombres premiers compris entre 1 et 1 000 000):
from sympy import sieve
primes = list(sieve.primerange(1, 10**6))
Cela s'exécute 10 (!) Fois plus rapidement sur PyPy que sur Python. Mais pas sur les fenêtres. Là, c'est seulement 3 fois plus vite.
Pour beaucoup de projets, il existe en réalité une différence de 0% entre les différents pythons en termes de vitesse. Ce sont ceux qui sont dominés par le temps d'ingénierie et où tous les pythons ont la même quantité de support de bibliothèque.
Pour simplifier les choses: PyPy fournit la vitesse qui manque à CPython mais sacrifie sa compatibilité. Cependant, la plupart des gens choisissent Python pour sa flexibilité et sa fonctionnalité "batterie incluse" (compatibilité élevée), et non pas pour sa vitesse (cela reste préférable).
PyPy est supporté par Python 3 depuis un moment, mais selon ce message message de HackerNoon par Anthony Shaw du 2 avril 2018 , PyPy3 est toujours plusieurs fois plus lent que PyPy (Python 2) .
Pour de nombreux calculs scientifiques, notamment matriciels, numpy est un meilleur choix (voir FAQ: Devrais-je installer numpy ou numpypy? ).
Pypy ne supporte pas gmpy2. Vous pouvez utiliser à la place gmpy_cffi bien que je n’aie pas testé sa vitesse et que le projet ait eu une version en 2014.
Pour les problèmes liés au projet Euler, je fais fréquemment appel à PyPy, et pour les calculs numériques simples, from __future__ import division suffit pour mes besoins, mais le support de Python 3 est toujours en cours à partir de 2018, avec votre Le meilleur pari étant sur Linux 64 bits. Windows PyPy3.5 v6.0, le dernier en date à décembre 2018, est en version bêta.