Escuché mucho sobre el proyecto PyPy . Afirman que es 6,3 veces más rápido que el intérprete CPython en su sitio .
Siempre que hablamos de lenguajes dinámicos como Python, la velocidad es uno de los principales problemas. Para solucionar esto, dicen que PyPy es 6,3 veces más rápido.
El segundo problema es el paralelismo, el infame Global Interpreter Lock (GIL). Para esto, PyPy dice que puede dar Python sin GIL .
Si PyPy puede resolver estos grandes desafíos, ¿cuáles son sus debilidades que impiden una adopción más amplia? Es decir, ¿qué impide que alguien como yo, un típico desarrollador de Python, cambie a PyPy en este momento ?
Para citar el Zen de Python :
La legibilidad cuenta.
Por ejemplo, Python 3.8 introdujo fstring = .
Puede haber otras características en Python 3.8+ que sean más importantes para usted. PyPy no es compatible con Python 3.8+ en este momento.
Auto-publicidad desvergonzada: Killer Features by Python version - si quieres saber más cosas que extrañas al usar versiones anteriores de Python
PyPy ha sido compatible con Python 3 durante un tiempo, pero según esta publicación de HackerNoon de Anthony Shaw del 2 de abril de 2018 , PyPy3 sigue siendo varias veces más lento que PyPy (Python 2).
Para muchos cálculos científicos, particularmente los cálculos matriciales, numpy es una mejor opción (ver Preguntas frecuentes: ¿Debo instalar numpy o numpypy? ).
Pypy no es compatible con gmpy2. En su lugar, puede utilizar gmpy_cffi aunque no he probado su velocidad y el proyecto tuvo un lanzamiento en 2014.
Para los problemas de Project Euler, uso PyPy con frecuencia, y para cálculos numéricos simples, a menudo from __future__ import division es suficiente para mis propósitos, pero la compatibilidad con Python 3 todavía se está trabajando a partir de 2018, y su mejor opción es 64 bits. linux Windows PyPy3.5 v6.0, la última versión de diciembre de 2018, está en versión beta.
He encontrado ejemplos en los que PyPy es más lento que Python. Pero: solo en 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 loopEntonces, si piensas en PyPy, olvídate de Windows. En Linux, puede lograr aceleraciones asombrosas. Ejemplo (enumere todos los números primos entre 1 y 1 000 000):
from sympy import sieve primes = list(sieve.primerange(1, 10**6))Esto se ejecuta 10 (!) veces más rápido en PyPy que en Python. Pero no en las ventanas. Allí es sólo 3 veces más rápido.
Para hacerlo simple: PyPy proporciona la velocidad que le falta a CPython pero sacrifica su compatibilidad. La mayoría de las personas, sin embargo, eligen Python por su flexibilidad y su función de "batería incluida" (alta compatibilidad), no por su velocidad (aunque sigue siendo la preferida).
Debido a que pypy no es 100% compatible, requiere 8 gigas de ram para compilar, es un objetivo móvil y altamente experimental, donde cpython es estable, el objetivo predeterminado para los creadores de módulos durante 2 décadas (incluidas las extensiones c que no funcionan en pypy ), y ya ampliamente desplegado.
Es probable que Pypy nunca sea la implementación de referencia, pero es una buena herramienta.
La segunda pregunta es más fácil de responder: básicamente puede usar PyPy como un reemplazo directo si todo su código es Python puro. Sin embargo, muchas bibliotecas ampliamente utilizadas (incluidas algunas de las bibliotecas estándar) están escritas en C y compiladas como extensiones de Python. Algunos de estos se pueden hacer para trabajar con PyPy, otros no. PyPy proporciona la misma herramienta "orientada hacia adelante" que Python, es decir, es Python, pero sus entrañas son diferentes, por lo que las herramientas que interactúan con esas entrañas no funcionarán.
En cuanto a la primera pregunta, me imagino que es una especie de Catch-22 con la primera: PyPy ha evolucionado rápidamente en un esfuerzo por mejorar la velocidad y mejorar la interoperabilidad con otro código. Esto lo ha hecho más experimental que oficial.
Creo que es posible que si PyPy entra en un estado estable, puede comenzar a ser más utilizado. También creo que sería genial que Python se alejara de sus fundamentos C. Pero no sucederá por un tiempo. PyPy aún no ha alcanzado la masa crítica en la que es casi lo suficientemente útil por sí solo para hacer todo lo que quieras, lo que motivaría a las personas a llenar los vacíos.
NOTA: PyPy es más maduro y tiene mejor soporte ahora que en 2013, cuando se hizo esta pregunta. Evite sacar conclusiones de información desactualizada.
Esas son las principales razones que me afectan, diría yo.
Hice un pequeño punto de referencia sobre este tema. Si bien muchos de los otros publicadores han hecho buenos comentarios sobre la compatibilidad, mi experiencia ha sido que PyPy no es mucho más rápido solo para mover bits. Para muchos usos de Python, en realidad solo existe para traducir bits entre dos o más servicios. Por ejemplo, no hay muchas aplicaciones web que realicen análisis intensivos de CPU de conjuntos de datos. En cambio, toman algunos bytes de un cliente, los almacenan en algún tipo de base de datos y luego los devuelven a otros clientes. A veces se cambia el formato de los datos.
Los desarrolladores de BDFL y CPython son un grupo de personas notablemente inteligentes y han logrado ayudar a que CPython se desempeñe de manera excelente en tal escenario. Aquí hay un complemento de blog desvergonzado: http://www.hydrogen18.com/blog/unpickling-buffers.html . Estoy usando Stackless, que se deriva de CPython y conserva la interfaz completa del módulo C. No encontré ninguna ventaja en usar PyPy en ese caso.
Ese sitio no afirma que PyPy sea 6,3 veces más rápido que CPython. Citar:
El promedio geométrico de todos los puntos de referencia es 0,16 o 6,3 veces más rápido que CPython
Esta es una declaración muy diferente a la declaración general que hizo, y cuando comprenda la diferencia, comprenderá al menos un conjunto de razones por las que no puede simplemente decir "usar PyPy". Puede parecer que estoy quisquilloso, pero es vital comprender por qué estas dos afirmaciones son totalmente diferentes.
Para romper eso:
La declaración que hacen solo se aplica a los puntos de referencia que han utilizado. No dice absolutamente nada sobre su programa (a menos que su programa sea exactamente el mismo que uno de sus puntos de referencia).
La declaración es sobre un promedio de un grupo de puntos de referencia. No hay ninguna afirmación de que ejecutar PyPy dará una mejora de 6,3 veces incluso para los programas que han probado.
No se afirma que PyPy incluso ejecute todos los programas que CPython ejecuta, y mucho menos más rápido.
CPython tiene conteo de referencias y recolección de basura, PyPy solo tiene recolección de basura.
Por lo tanto, los objetos tienden a eliminarse antes y __del__ se llama de una manera más predecible en CPython. Algunos programas dependen de este comportamiento, por lo que no están listos para migrar a PyPy.
Otro software funciona con ambos, pero usa menos memoria con CPython, porque los objetos no utilizados se liberan antes. (No tengo ninguna medida para indicar cuán significativo es esto y qué otros detalles de implementación afectan el uso de la memoria).
Para muchos proyectos, en realidad hay una diferencia del 0% entre las diferentes pitones en términos de velocidad. Esos son aquellos que están dominados por el tiempo de ingeniería y donde todos los pitones tienen la misma cantidad de soporte de biblioteca.
P: Si PyPy puede resolver estos grandes desafíos (velocidad, consumo de memoria, paralelismo) en comparación con CPython, ¿cuáles son sus debilidades que impiden una adopción más amplia?
R: Primero, hay poca evidencia de que el equipo de PyPy pueda resolver el problema de la velocidad en general . La evidencia a largo plazo muestra que PyPy ejecuta ciertos códigos de Python más lentamente que CPython y este inconveniente parece estar muy arraigado en PyPy.
En segundo lugar, la versión actual de PyPy consume mucha más memoria que CPython en un conjunto bastante grande de casos. Entonces PyPy aún no resolvió el problema del consumo de memoria.
Si PyPy resuelve los grandes desafíos mencionados y, en general , será más rápido, menos hambriento de memoria y más amigable con el paralelismo que CPython es una pregunta abierta que no se puede resolver a corto plazo. Algunas personas apuestan a que PyPy nunca podrá ofrecer una solución general que le permita dominar CPython 2.7 y 3.3 en todos los casos.
Si PyPy logra ser mejor que CPython en general, lo cual es cuestionable, la principal debilidad que afectará su adopción más amplia será su compatibilidad con CPython. También existen problemas, como el hecho de que CPython se ejecuta en una gama más amplia de CPU y sistemas operativos, pero estos problemas son mucho menos importantes en comparación con el rendimiento de PyPy y los objetivos de compatibilidad con CPython.
P: ¿Por qué no puedo reemplazar CPython con PyPy ahora?
R: PyPy no es 100 % compatible con CPython porque no simula CPython bajo el capó. Algunos programas aún pueden depender de las características únicas de CPython que están ausentes en PyPy, como enlaces C, implementaciones C de objetos y métodos de Python o la naturaleza incremental del recolector de basura de CPython.