¿Por qué no debería usar PyPy sobre CPython si PyPy es 6.3 veces más rápido?

He estado escuchando mucho sobre el proyecto PyPy . Afirman que es 6.3 veces más rápido que el CPython intérprete de en su sitio .

Siempre que hablamos de lenguajes dinámicos como Python, la velocidad es uno de los principales problemas. Para resolver 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 desarrollador típico de Python, cambie a PyPy en este momento ?

NOTA: PyPy es más maduro y mejor soportado ahora que en 2013, cuando se hizo esta pregunta. Evite sacar conclusiones de información desactualizada.

1. PyPy, como otros se han apresurado a hablar, tiene soporte para extensiones C tenue . Se cuenta con el apoyo, pero por lo general a una velocidad más lenta de lo Python y es dudoso en el mejor. Por lo tanto, muchos módulos simplemente requieren CPython. PyPy no admite numpy. PyPy ahora admite numpy . Algunas extensiones aún no son compatibles (Pandas, SciPy, etc.), eche un vistazo a la lista de paquetes compatibles antes de realizar el cambio.
2. El soporte de Python 3 es experimental en este momento. acaba de llegar estable! A partir del 20 de junio de 2014, PyPy3 2.3.1 - ¡Fulcrum está disponible !
3. PyPy a veces no es realmente más rápido para "scripts", para lo cual mucha gente usa Python. Estos son los programas de ejecución corta que hacen algo simple y pequeño. Debido a que PyPy es un compilador JIT, sus principales ventajas provienen de tiempos de ejecución largos y tipos simples (como números). Francamente, las velocidades anteriores a JIT de PyPy son bastante malas en comparación con CPython.
4. La inercia . Pasar a PyPy a menudo requiere una actualización, lo que para algunas personas y organizaciones es simplemente demasiado trabajo.

Esas son las principales razones que me afectan, diría.

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 muy declaración 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 "use PyPy". Puede sonar como que estoy buscando cosas, pero entender por qué estas dos afirmaciones son totalmente diferentes es vital.

Para desglosar eso:

• La declaración que hacen solo se aplica a los puntos de referencia que han utilizado. No dice absolutamente nada acerca de 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 se afirma que ejecutar PyPy proporcionará una mejora de 6.3 veces incluso para los programas que han probado.

• No hay ninguna afirmación de que PyPy incluso ejecutar todos los programas que ejecuta CPython en absoluto , y mucho menos rápido.

Debido a que pypy no es 100% compatible, toma 8 gigas de ram para compilar, es un objetivo móvil y altamente experimental, donde cpython es estable, el objetivo predeterminado para los constructores de módulos durante 2 décadas (incluidas las extensiones c que no funcionan en pypy) ), y ya ampliamente implementado.

Pypy probablemente nunca será la implementación de referencia, pero es una buena herramienta para tener.

La segunda pregunta es más fácil de responder: básicamente puedes usar PyPy como reemplazo directo si todo su código es Python puro. Sin embargo, muchas bibliotecas ampliamente utilizadas (incluidas algunas de la biblioteca estándar) están escritas en C y compiladas como extensiones de Python. Algunos de estos pueden hacerse funcionar 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 para Python alejarse de sus cimientos. Pero no sucederá por un tiempo. PyPy aún no ha alcanzado la masa crítica donde es casi lo suficientemente útil por sí solo para hacer todo lo que desee, lo que motivaría a las personas a llenar los vacíos.

Hice un pequeño punto de referencia sobre este tema. Si bien muchos de los otros carteles han hecho buenos comentarios sobre la compatibilidad, mi experiencia ha sido que PyPy no es mucho más rápido para moverse por bits. Para muchos usos de Python, realmente solo existe para traducir bits entre dos o más servicios. Por ejemplo, no muchas aplicaciones web realizan 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 inteligente y han logrado ayudar a CPython a desempeñarse de manera excelente en tal escenario. Aquí hay un complemento de blog descarado: 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 al usar PyPy en ese caso.

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. Así que PyPy todavía 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 al 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 afecta 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 de CPython.

P: ¿Por qué no puedo dejar de reemplazar CPython con PyPy ahora?

R: PyPy no es 100% compatible con CPython porque no simula CPython debajo del capó. Algunos programas aún pueden depender de las características únicas de CPython que están ausentes en PyPy, tales como enlaces C, implementaciones C de objetos y métodos de Python, o la naturaleza incremental del recolector de basura de CPython.

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 softwares 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 qué tan importante 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 todas las pitones tienen la misma cantidad de soporte de biblioteca.

Para simplificar esto: PyPy proporciona la velocidad que le falta a CPython pero sacrifica su compatibilidad. Sin embargo, la mayoría de las personas eligen Python por su flexibilidad y su característica de "batería incluida" (alta compatibilidad), no por su velocidad (aunque todavía se prefiere).

He encontrado ejemplos, donde 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 loop

Entonces, si piensas en PyPy, olvida Windows. En Linux, puedes lograr aceleraciones increíbles. 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 ventanas. Ahí solo es 3 veces más rápido.

PyPy ha tenido soporte para Python 3 por 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, en particular los cálculos matriciales, numpy es una mejor opción (consulte 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 del Proyecto Euler, hago uso frecuente de PyPy, y para cálculos numéricos simples a menudo from __future__ import divisiones suficiente para mis propósitos, pero el soporte de Python 3 todavía se está trabajando a partir de 2018, con su mejor apuesta en Linux de 64 bits. Windows PyPy3.5 v6.0, la última versión de diciembre de 2018, está en versión beta.

Versiones de Python compatibles

Para citar el Zen de Python :

La legibilidad cuenta.

Por ejemplo, Python 3.7 introdujo clases de datos y Python 3.8 introdujo fstring = .

Puede haber otras características en Python 3.7 y Python 3.8 que son más importantes para usted. El punto es que PyPy no es compatible con Python 3.7 o Python 3.8 en este momento.