Perché non dovrei usare PyPy su CPython se PyPy è 6,3 volte più veloce?

Ho sentito molto parlare del progetto PyPy . Affermano che è 6,3 volte più veloce dell'interprete CPython sul loro sito .

Ogni volta che parliamo di linguaggi dinamici come Python, la velocità è uno dei problemi principali. Per risolvere questo, dicono che PyPy è 6,3 volte più veloce.

Il secondo problema è il parallelismo, il famigerato Global Interpreter Lock (GIL). Per questo, PyPy dice che può dare Python senza GIL .

Se PyPy è in grado di risolvere queste grandi sfide, quali sono i suoi punti deboli che impediscono un'adozione più ampia? Vale a dire, cosa impedisce a qualcuno come me, un tipico sviluppatore di Python, di passare a PyPy in questo momento ?

NOTA: PyPy è più maturo e meglio supportato ora rispetto al 2013, quando è stata posta questa domanda. Evita di trarre conclusioni da informazioni non aggiornate.

1. PyPy, come altri si sono affrettati a parlare, ha il supporto per le estensioni tenue C . Essa ha il supporto, ma in genere a velocità più lenta del Python ed è incerto al meglio. Quindi molti moduli richiedono semplicemente CPython. PyPy non supporta numpy PyPy ora supporta numpy . Alcune estensioni non sono ancora supportate (Pandas, SciPy, ecc.), Dai un'occhiata all'elenco dei pacchetti supportati prima di apportare la modifica.
2. Il supporto di Python 3 è attualmente sperimentale. ha appena raggiunto la stabilità! A partire dal 20 giugno 2014, PyPy3 2.3.1 - Fulcrum è uscito !
3. PyPy a volte non è in realtà più veloce per gli "script", per cui molte persone usano Python. Questi sono i programmi a esecuzione breve che fanno qualcosa di semplice e piccolo. Poiché PyPy è un compilatore JIT, i suoi principali vantaggi derivano da tempi di esecuzione lunghi e tipi semplici (come i numeri). Francamente, le velocità pre-JIT di PyPy sono piuttosto scarse rispetto a CPython.
4. Inerzia . Passare a PyPy richiede spesso il riattrezzaggio, che per alcune persone e organizzazioni è semplicemente troppo lavoro.

Quelli sono i motivi principali che mi riguardano, direi.

Quel sito non afferma che PyPy è 6,3 volte più veloce di CPython. Per citare:

La media geometrica di tutti i benchmark è 0,16 o 6,3 volte più veloce di CPython

Questa è un'affermazione molto diversa dall'affermazione generale che hai fatto e quando capisci la differenza, capirai almeno una serie di motivi per cui non puoi semplicemente dire "usa PyPy". Potrebbe sembrare che io sia pignolo, ma capire perché queste due affermazioni sono totalmente diverse è vitale.

Per scomporlo:

• La dichiarazione che fanno si applica solo ai parametri di riferimento che hanno usato. Non dice assolutamente nulla sul tuo programma (a meno che il tuo programma non sia esattamente lo stesso di uno dei loro benchmark).

• La dichiarazione è circa una media di un gruppo di parametri di riferimento. Non si afferma che eseguire PyPy migliorerà 6,3 volte anche per i programmi che hanno testato.

• Non v'è alcuna pretesa che PyPy sarà anche eseguire tutti i programmi che CPython corre a tutti , per non parlare più velocemente.

Poiché pypy non è compatibile al 100%, richiede 8 GB di ram per essere compilato, è un obiettivo mobile e altamente sperimentale, in cui cpython è stabile, l'obiettivo predefinito per i costruttori di moduli per 2 decenni (incluse estensioni c che non funzionano su pypy ) e già ampiamente utilizzato.

Pypy probabilmente non sarà mai l'implementazione di riferimento, ma è un buon strumento da avere.

Alla seconda domanda è più facile rispondere: in pratica puoi usare PyPy come sostituto drop-in se tutto il tuo codice è Python puro. Tuttavia, molte librerie ampiamente utilizzate (incluse alcune delle librerie standard) sono scritte in C e compilate come estensioni di Python. Alcuni di questi possono essere fatti funzionare con PyPy, altri no. PyPy fornisce lo stesso strumento "rivolto in avanti" di Python --- cioè è Python --- ma le sue viscere sono diverse, quindi gli strumenti che si interfacciano con quelle viscere non funzioneranno.

Per quanto riguarda la prima domanda, immagino che sia una specie di Catch-22 con la prima: PyPy si è evoluto rapidamente nel tentativo di migliorare la velocità e migliorare l'interoperabilità con altri codici. Ciò lo ha reso più sperimentale che ufficiale.

Penso che sia possibile che se PyPy si trova in uno stato stabile, potrebbe iniziare ad essere più ampiamente utilizzato. Penso anche che sarebbe fantastico per Python allontanarsi dalle sue basi in C. Ma non succederà per un po '. PyPy non ha ancora raggiunto la massa critica in cui è quasi abbastanza utile da solo fare tutto ciò che desideri, il che motiverebbe le persone a colmare le lacune.

Ho fatto un piccolo punto di riferimento su questo argomento. Mentre molti degli altri poster hanno messo in evidenza la compatibilità, la mia esperienza è stata che PyPy non è molto più veloce semplicemente spostandosi sui bit. Per molti usi di Python, esiste davvero solo per tradurre bit tra due o più servizi. Ad esempio, non molte applicazioni Web stanno eseguendo un'analisi intensiva della CPU dei set di dati. Invece, prendono alcuni byte da un client, li memorizzano in una sorta di database e li restituiscono in seguito ad altri client. A volte il formato dei dati viene modificato.

Gli sviluppatori BDFL e CPython sono un gruppo di persone straordinariamente intelligenti e sono riusciti ad aiutare CPython a ottenere prestazioni eccellenti in questo scenario. Ecco un blog spudorato: http://www.hydrogen18.com/blog/unpickling-buffers.html . Sto usando Stackless, che è derivato da CPython e mantiene l'intera interfaccia del modulo C. Non ho trovato alcun vantaggio nell'usare PyPy in quel caso.

D: Se PyPy è in grado di risolvere queste grandi sfide (velocità, consumo di memoria, parallelismo) rispetto a CPython, quali sono i suoi punti deboli che impediscono un'adozione più ampia?

A: Innanzitutto, ci sono poche prove che il team PyPy possa risolvere il problema della velocità in generale . Le prove a lungo termine mostrano che PyPy esegue alcuni codici Python più lentamente di CPython e questo inconveniente sembra essere profondamente radicato in PyPy.

In secondo luogo, l'attuale versione di PyPy consuma molta più memoria rispetto a CPython in una serie piuttosto ampia di casi. Quindi PyPy non ha ancora risolto il problema del consumo di memoria.

Se PyPy risolve le grandi sfide menzionate e in generale sarà più veloce, meno affamato di memoria e più amichevole al parallelismo rispetto a CPython è una domanda aperta che non può essere risolta a breve termine. Alcune persone scommettono che PyPy non sarà mai in grado di offrire una soluzione generale che gli consenta di dominare CPython 2.7 e 3.3 in tutti i casi.

Se PyPy riesce a essere migliore di CPython in generale, il che è discutibile, la principale debolezza che influenza la sua adozione più ampia sarà la sua compatibilità con CPython. Esistono anche problemi come il fatto che CPython funzioni su una gamma più ampia di CPU e sistemi operativi, ma questi problemi sono molto meno importanti rispetto alle prestazioni di PyPy e agli obiettivi di compatibilità di CPython.

D: Perché non posso interrompere subito la sostituzione di CPython con PyPy?

A: PyPy non è compatibile al 100% con CPython perché non simula CPython sotto il cofano. Alcuni programmi possono ancora dipendere dalle caratteristiche uniche di CPython che sono assenti in PyPy come i collegamenti C, le implementazioni C dell'oggetto e dei metodi Python o la natura incrementale del garbage collector di CPython.

CPython ha il conteggio dei riferimenti e la garbage collection, PyPy ha solo la garbage collection.

Quindi gli oggetti tendono ad essere eliminati prima e __del__vengono chiamati in modo più prevedibile in CPython. Alcuni software si basano su questo comportamento, quindi non sono pronti per la migrazione a PyPy.

Alcuni altri software funzionano con entrambi, ma utilizzano meno memoria con CPython, poiché gli oggetti non utilizzati vengono liberati in precedenza. (Non ho alcuna misura per indicare quanto questo sia significativo e quali altri dettagli di implementazione influenzano l'uso della memoria.)

Per molti progetti, esiste una differenza dello 0% tra i diversi pitoni in termini di velocità. Ecco quelli che sono dominati dal tempo di ingegneria e in cui tutti i pitoni hanno la stessa quantità di supporto per la libreria.

Per renderlo semplice: PyPy fornisce la velocità che manca a CPython ma sacrifica la sua compatibilità. La maggior parte delle persone, tuttavia, sceglie Python per la sua flessibilità e la sua funzione "batteria inclusa" (alta compatibilità), non per la sua velocità (è comunque preferibile).

Ho trovato degli esempi in cui PyPy è più lento di Python. Ma: solo su 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

Quindi, se pensi a PyPy, dimentica Windows. Su Linux, puoi ottenere incredibili accelerazioni. Esempio (elenca tutti i numeri primi compresi tra 1 e 1.000.000):

from sympy import sieve
primes = list(sieve.primerange(1, 10**6))

Funziona 10 (!) Volte più velocemente su PyPy che su Python. Ma non su Windows. Lì è solo 3 volte più veloce.

PyPy ha avuto il supporto di Python 3 per un po ', ma secondo questo post di HackerNoon di Anthony Shaw del 2 aprile 2018 , PyPy3 è ancora più volte più lento di PyPy (Python 2).

Per molti calcoli scientifici, in particolare i calcoli con matrici, numpy è una scelta migliore (vedi FAQ: devo installare numpy o numpypy? ).

Pypy non supporta gmpy2. Puoi invece utilizzare gmpy_cffi anche se non ho testato la sua velocità e il progetto ha avuto una versione nel 2014.

Per i problemi di Project Euler, utilizzo spesso PyPy e per semplici calcoli numerici spesso from __future__ import divisionè sufficiente per i miei scopi, ma il supporto di Python 3 è ancora in fase di elaborazione a partire dal 2018, con la tua scommessa migliore su Linux a 64 bit. Windows PyPy3.5 v6.0, l'ultimo a dicembre 2018, è in versione beta.

Versioni di Python supportate

Per citare lo Zen di Python :

La leggibilità conta.

Ad esempio, Python 3.7 ha introdotto i dataclass e Python 3.8 ha introdotto fstring = .

Potrebbero esserci altre funzionalità in Python 3.7 e Python 3.8 che sono più importanti per te. Il punto è che PyPy al momento non supporta Python 3.7 o Python 3.8.