PyPy - Come può eventualmente battere CPython?

Dal blog open source di Google :

PyPy è una reimplementazione di Python in Python, utilizzando tecniche avanzate per cercare di ottenere prestazioni migliori rispetto a CPython. Molti anni di duro lavoro hanno finalmente ripagato. I nostri risultati di velocità spesso battono CPython, spaziando da un po 'più lento, a velocizzazioni fino a 2 volte su un codice applicativo reale, a velocizzazioni fino a 10 volte su piccoli benchmark.

Com'è possibile? Quale implementazione di Python è stata utilizzata per implementare PyPy? CPython ? E quali sono le probabilità che un PyPyPy o PyPyPyPy battano il loro punteggio?

(In una nota correlata ... perché qualcuno dovrebbe provare qualcosa del genere?)

Q1. Com'è possibile?

La gestione manuale della memoria (che è ciò che CPython fa con il suo conteggio) può essere più lenta della gestione automatica in alcuni casi.

Le limitazioni nell'implementazione dell'interprete CPython precludono alcune ottimizzazioni che PyPy può fare (es. Serrature a grana fine).

Come accennato da Marcelo, il JIT. Essere in grado di confermare al volo il tipo di un oggetto può farti risparmiare la necessità di fare più dereferenze del puntatore per arrivare finalmente al metodo che vuoi chiamare.

Q2. Quale implementazione di Python è stata utilizzata per implementare PyPy?

L'interprete PyPy è implementato in RPython che è un sottoinsieme tipicamente statico di Python (il linguaggio e non l'interprete CPython). - Fare riferimento a https://pypy.readthedocs.org/en/latest/architecture.html per i dettagli.

Q3. E quali sono le probabilità che un PyPyPy o PyPyPyPy battano il loro punteggio?

Ciò dipenderebbe dall'implementazione di questi ipotetici interpreti. Se uno di loro, ad esempio, prendesse il sorgente, facesse una sorta di analisi su di esso e lo convertisse direttamente in un codice assembly specifico target target dopo averlo eseguito per un po ', immagino che sarebbe molto più veloce di CPython.

Aggiornamento: Di recente, su un esempio accuratamente realizzato , PyPy ha superato un programma C simile compilato gcc -O3. È un caso inventato ma mostra alcune idee.

Q4. Perché qualcuno dovrebbe provare qualcosa del genere?

Dal sito ufficiale. https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement

Miriamo a fornire:

• un quadro comune di traduzione e supporto per la produzione di
  implementazioni di linguaggi dinamici, sottolineando una netta
  separazione tra specifiche della lingua e
  aspetti dell'implementazione . Lo chiamiamo RPython toolchain_.

• un'implementazione conforme, flessibile e rapida del linguaggio Python_ che utilizza la toolchain di cui sopra per abilitare nuove funzionalità avanzate di alto livello senza dover codificare i dettagli di basso livello.

Separando le preoccupazioni in questo modo, la nostra implementazione di Python - e di altri linguaggi dinamici - è in grado di generare automaticamente un compilatore Just-in-Time per qualsiasi linguaggio dinamico. Consente inoltre un approccio mix-and-match alle decisioni di implementazione, incluse molte che sono state storicamente al di fuori del controllo di un utente, come piattaforma di destinazione, modelli di memoria e threading, strategie di garbage collection e ottimizzazioni applicate, incluso se avere o meno un JIT in primo luogo.

Il compilatore C gcc è implementato in C, il compilatore Haskell GHC è scritto in Haskell. Hai qualche motivo per l'interprete / compilatore Python di non essere scritto in Python?

"PyPy è una reimplementazione di Python in Python" è un modo piuttosto fuorviante per descrivere PyPy, IMHO, anche se tecnicamente vero.

Ci sono due parti principali di PyPy.

1. Il framework di traduzione
2. L'interprete

Il framework di traduzione è un compilatore. Compila il codice RPython fino a C (o altri target), aggiungendo automaticamente aspetti come garbage collection e un compilatore JIT. Non può gestire codice Python arbitrario, solo RPython.

RPython è un sottoinsieme del normale Python; tutto il codice RPython è codice Python, ma non viceversa. Non esiste una definizione formale di RPython, poiché RPython è fondamentalmente solo "il sottoinsieme di Python che può essere tradotto dal framework di traduzione di PyPy". Ma per essere tradotto, il codice RPython deve essere tipizzato staticamente (i tipi sono dedotti, non li dichiari, ma è comunque rigorosamente un tipo per variabile) e non puoi fare cose come dichiarare / modificare funzioni / classi durante l'esecuzione.

L'interprete quindi è un normale interprete Python scritto in RPython.

Poiché il codice RPython è un normale codice Python, è possibile eseguirlo su qualsiasi interprete Python. Ma nessuna delle affermazioni sulla velocità di PyPy proviene dal farlo in quel modo; questo è solo per un rapido ciclo di test, perché la traduzione dell'interprete richiede molto tempo.

Detto ciò, dovrebbe essere immediatamente ovvio che le speculazioni su PyPyPy o PyPyPyPy non hanno alcun senso. Hai un interprete scritto in RPython. Lo traduci in codice C che esegue rapidamente Python. Lì il processo si ferma; non c'è più RPython per accelerare elaborandolo di nuovo.

Quindi "Come è possibile che PyPy sia più veloce di CPython" diventa anche abbastanza ovvio. PyPy ha un'implementazione migliore, incluso un compilatore JIT (in genere non è altrettanto veloce senza il compilatore JIT, credo, il che significa che PyPy è solo più veloce per i programmi sensibili alla compilazione JIT). CPython non è mai stato progettato per essere un'implementazione altamente ottimizzante del linguaggio Python (sebbene provino a renderlo un'implementazione altamente ottimizzata , se segui la differenza).

La parte davvero innovativa del progetto PyPy è che non scrivono a mano sofisticati schemi GC o compilatori JIT. Scrivono l'interprete in modo relativamente semplice in RPython, e per tutti RPython è di livello inferiore rispetto a Python è ancora un linguaggio di raccolta dei rifiuti orientato agli oggetti, molto più alto livello di C. Quindi il framework di traduzione aggiunge automaticamente cose come GC e JIT. Quindi il framework di traduzione è enormesforzo, ma si applica ugualmente bene all'interprete PyPy Python, tuttavia modificano la loro implementazione, consentendo molta più libertà nella sperimentazione per migliorare le prestazioni (senza preoccuparsi di introdurre bug GC o aggiornare il compilatore JIT per far fronte alle modifiche). Significa anche che quando riescono a implementare un interprete Python3, otterranno automaticamente gli stessi vantaggi. E qualsiasi altro interprete scritto con il framework PyPy (di cui esiste un numero in varie fasi di polacco). E tutti gli interpreti che utilizzano il framework PyPy supportano automaticamente tutte le piattaforme supportate dal framework.

Quindi il vero vantaggio del progetto PyPy è quello di separare (il più possibile) tutte le parti dell'implementazione di un interprete efficiente indipendente dalla piattaforma per un linguaggio dinamico. E poi escogita una buona implementazione di essi in un unico posto, che può essere riutilizzato in molti interpreti. Non è una vittoria immediata come "il mio programma Python funziona più velocemente ora", ma è una grande prospettiva per il futuro.

E può eseguire il tuo programma Python più velocemente (forse).

PyPy è implementato in Python, ma implementa un compilatore JIT per generare al volo codice nativo.

Il motivo per implementare PyPy su Python è probabilmente che è semplicemente un linguaggio molto produttivo, soprattutto perché il compilatore JIT rende le prestazioni del linguaggio host un po 'irrilevanti.

PyPy è scritto in Python con restrizioni. Non funziona sull'interprete CPython, per quanto ne so. Python limitato è un sottoinsieme del linguaggio Python. AFAIK, l'interprete PyPy viene compilato in codice macchina, quindi quando installato non utilizza un interprete Python in fase di esecuzione.

La tua domanda sembra aspettarsi che l'interprete PyPy sia in esecuzione su CPython durante l'esecuzione del codice. Modifica: Sì, per usare PyPy devi prima tradurre il codice Pyon PyPy, in C e compilare con gcc, in codice byte jvm o in codice CLI .Net. Vedi Introduzione