tutorial - python virtualenv pypy




PyPy-Come può battere CPython? (3)

Dal blog di Google Open Source :

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, che va dall'essere leggermente più lento, agli aumenti di velocità fino a 2x sul codice dell'applicazione reale, agli accelerazioni fino a 10x su piccoli benchmark.

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

(Su una nota correlata ... perché qualcuno dovrebbe provare qualcosa di simile?)


"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. La struttura della traduzione
  2. L'interprete

Il framework di traduzione è un compilatore. Compilano il codice RPython in C (o in altri target), aggiungendo automaticamente aspetti come la 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 il contrario. Non esiste una definizione formale di RPython, perché 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 si dichiara, ma è ancora strettamente un tipo per variabile), e non si possono fare cose come dichiarare / modificare funzioni / anche le classi in fase di runtime.

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

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

Con quello capito, dovrebbe essere immediatamente ovvio che le speculazioni su PyPyPy o PyPyPyPy in realtà 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 "Com'è possibile che PyPy sia più veloce di CPython" diventa anche abbastanza ovvio. PyPy ha un'implementazione migliore, incluso un compilatore JIT (credo che non sia altrettanto veloce senza il compilatore JIT, il che significa che PyPy è solo più veloce per i programmi suscettibili 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).

Il bit davvero innovativo del progetto PyPy è che non scrivono a mano schemi sofisticati di GC o compilatori JIT. Scrivono l'interprete in modo relativamente semplice in RPython, e per tutti i livelli RPython è inferiore a quello di Python, è ancora un linguaggio di raccolta dati orientato agli oggetti, molto più alto di C. Quindi il framework di traduzione aggiunge automaticamente cose come GC e JIT. Quindi il framework di traduzione è un enorme sforzo, ma si applica ugualmente bene all'interprete Python Python, ma cambiano la loro implementazione, consentendo molta più libertà nella sperimentazione per migliorare le prestazioni (senza preoccuparsi di introdurre bug di GC o aggiornare il compilatore JIT per far fronte a i cambiamenti). Significa anche che quando riescono a implementare un interprete Python3, otterranno automaticamente gli stessi benefici. E qualsiasi altro interprete scritto con il framework PyPy (di cui ci sono un numero a vari stadi di smalto). 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 indipendente dalla piattaforma efficiente per un linguaggio dinamico. E poi ne viene fuori una buona implementazione in un unico posto, che può essere riutilizzata attraverso molti interpreti. Non è una vittoria immediata come "il mio programma Python è più veloce adesso", ma è una grande prospettiva per il futuro.

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


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

La ragione per implementare PyPy su Python è probabilmente che è semplicemente un linguaggio molto produttivo, soprattutto perché il compilatore JIT rende le prestazioni della lingua ospite alquanto irrilevanti.


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.

Limitazioni nell'implementazione dell'interprete CPython precludono alcune ottimizzazioni che PyPy può fare (ad esempio blocchi a grana fine).

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

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

L'interprete PyPy è implementato in RPython che è un sottoinsieme tipizzato staticamente di Python (il linguaggio e non l'interprete CPython). - Per i dettagli, consultare https://pypy.readthedocs.org/en/latest/architecture.html .

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

Ciò dipenderebbe dall'implementazione di questi ipotetici interpreti. Se ad esempio uno di questi ha preso la fonte, ha fatto qualche tipo di analisi su di esso e lo ha convertito direttamente in uno stretto codice di assembly specifico dopo aver eseguito per un po ', immagino che sarebbe molto più veloce di CPython.

Aggiornamento: recentemente, su un esempio accuratamente predisposto , PyPy ha sovraperformato un programma C simile compilato con gcc -O3 . È un caso inventato ma mostra alcune idee.

Q4. Perché qualcuno dovrebbe provare qualcosa di simile?

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

Miriamo a fornire:

  • una struttura di traduzione e supporto comune per la produzione
    implementazioni di linguaggi dinamici, sottolineando una pulizia
    separazione tra specifiche linguistiche e implementazione
    aspetti. Chiamiamo questo la RPython toolchain _.

  • implementazione conforme, flessibile e veloce del linguaggio Python che utilizza la toolchain 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. Inoltre, consente 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. Avete qualche motivo per l'interprete / compilatore Python di non essere scritto in Python?





language-implementation