"PyPy est une réimplémentation de Python en Python" est une façon assez trompeuse de décrire PyPy, à mon humble avis, bien que ce soit techniquement vrai.
Il y a deux parties principales de PyPy.
- Le cadre de traduction
- L'interprète
Le cadre de traduction est un compilateur. Il compile le code RPython en C (ou d'autres cibles), ajoutant automatiquement des aspects tels que le garbage collection et un compilateur JIT. Il ne peut pas gérer du code Python arbitraire, seulement RPython.
RPython est un sous-ensemble de Python normal; tout le code RPython est du code Python, mais pas l'inverse. Il n'y a pas de définition formelle de RPython, car RPython est fondamentalement juste "le sous-ensemble de Python qui peut être traduit par le cadre de traduction de PyPy". Mais pour être traduit, le code RPython doit être typé statiquement (les types sont inférés, vous ne les déclarez pas, mais c'est toujours strictement un type par variable), et vous ne pouvez pas faire des choses comme déclarer / modifier des fonctions / cours à l'exécution non plus.
L'interpréteur est alors un interpréteur Python normal écrit en RPython.
Le code RPython étant du code Python normal, vous pouvez l'exécuter sur n'importe quel interpréteur Python. Mais aucune des prétentions de vitesse de PyPy ne vient de le faire de cette façon; c'est juste pour un cycle de test rapide, car la traduction de l'interpréteur prend beaucoup de temps.
Cela dit, il devrait être immédiatement évident que les spéculations sur PyPyPy ou PyPyPyPy n'ont en fait aucun sens. Vous avez un interprète écrit en RPython. Vous le traduisez en code C qui exécute Python rapidement. Là, le processus s'arrête; il n'y a plus de RPython à accélérer en le traitant à nouveau.
"Comment est-il possible que PyPy soit plus rapide que CPython" devient également assez évident. PyPy a une meilleure implémentation, y compris un compilateur JIT (ce n'est généralement pas aussi rapide sans le compilateur JIT, je crois, ce qui signifie que PyPy n'est que plus rapide pour les programmes sensibles à la compilation JIT). CPython n'a jamais été conçu pour être une implémentation hautement optimisante du langage Python (bien qu'ils essaient d'en faire une implémentation hautement optimisée , si vous suivez la différence).
La partie vraiment innovante du projet PyPy est qu'ils n'écrivent pas à la main des schémas GC sophistiqués ou des compilateurs JIT. Ils écrivent l'interpréteur relativement directement dans RPython, et pour tous RPython est de niveau inférieur à Python, c'est toujours un langage de récupération de place orienté objet, beaucoup plus haut niveau que C. Ensuite, le cadre de traduction ajoute automatiquement des choses comme GC et JIT. Le cadre de traduction est donc un énormemais cela s'applique également à l'interpréteur python PyPy, mais ils modifient leur implémentation, ce qui permet une plus grande liberté d'expérimentation pour améliorer les performances (sans se soucier de l'introduction de bogues GC ou de la mise à jour du compilateur JIT pour faire face aux changements). Cela signifie également que lorsqu'ils parviendront à implémenter un interpréteur Python3, cela bénéficiera automatiquement des mêmes avantages. Et tout autre interprète écrit avec le framework PyPy (dont il existe un certain nombre à différents stades de polissage). Et tous les interprètes utilisant le framework PyPy prennent automatiquement en charge toutes les plateformes prises en charge par le framework.
Ainsi, le véritable avantage du projet PyPy est de séparer (autant que possible) toutes les parties de la mise en œuvre d'un interprète indépendant de la plate-forme efficace pour un langage dynamique. Et puis en proposer une bonne mise en œuvre en un seul endroit, qui peut être réutilisée par de nombreux interprètes. Ce n'est pas une victoire immédiate comme «mon programme Python s'exécute plus rapidement maintenant», mais c'est une excellente perspective pour l'avenir.
Et il peut exécuter votre programme Python plus rapidement (peut-être).