L'interpréteur Python 3 dispose-t-il d'une fonction JIT ?

Question

J'ai constaté que lorsque je demande quelque chose de plus à Python, ce dernier n'utilise pas les ressources de ma machine à 100% et il n'est pas vraiment rapide, il est rapide si on le compare à de nombreux autres langages interprétés, mais si on le compare à des langages compilés, je pense que la différence est vraiment remarquable.

Est-il possible d'accélérer les choses avec un compilateur Just In Time (JIT) dans Python 3 ?

Habituellement, un compilateur JIT est la seule chose qui peut améliorer les performances dans les langages interprétés, donc je me réfère à celui-ci, si d'autres solutions sont disponibles, je serais ravi d'accepter de nouvelles réponses.

Answer 1

Tout d'abord, Python 3(.x) est un langage, pour lequel il peut y avoir un nombre illimité d'implémentations. Bon, à ce jour, aucune implémentation à l'exception de CPython n'implémente réellement ces versions du langage. Mais cela va changer (PyPy est en train de rattraper son retard).

Pour répondre à la question que vous vouliez poser : CPython, 3.x ou autre, ne contient pas, n'a jamais contenu et ne contiendra probablement jamais un compilateur JIT. D'autres implémentations de Python (PyPy nativement, Jython et IronPython en réutilisant des compilateurs JIT pour les machines virtuelles sur lesquelles ils sont construits) ont un compilateur JIT. Et il n'y a aucune raison pour que leurs compilateurs JIT cessent de fonctionner lorsqu'ils ajouteront le support de Python 3.

Mais tant que je suis là, laissez-moi aussi répondre à une idée fausse :

En général, un compilateur JIT est la seule chose qui peut améliorer les performances dans les langages interprétés.

Ce n'est pas correct. Un compilateur JIT, dans sa forme la plus basique, supprime simplement la surcharge de l'interpréteur, ce qui explique une partie du ralentissement que vous constatez, mais pas la majorité. A bon Le compilateur JIT effectue également une série d'optimisations qui suppriment la surcharge nécessaire à l'implémentation de nombreuses fonctionnalités de Python en général (en détectant les cas particuliers qui permettent une implémentation plus efficace), les exemples les plus importants étant le typage dynamique, le polymorphisme et diverses fonctionnalités introspectives.

Il suffit de mettre en œuvre a Le compilateur n'y contribue pas. Vous avez besoin d'optimisations très astucieuses, dont la plupart ne sont valables que dans des circonstances très spécifiques et pour une fenêtre de temps limitée. Les compilateurs JIT ont la vie facile ici, car ils peuvent générer du code spécialisé au moment de l'exécution (c'est tout leur intérêt), peuvent analyser le programme plus facilement (et plus précisément) en l'observant pendant son exécution, et peuvent annuler les optimisations lorsqu'elles deviennent invalides. Ils peuvent également interagir avec les interprètes, contrairement aux compilateurs ahead of time, et le font souvent parce que c'est une décision de conception judicieuse. Je suppose que c'est la raison pour laquelle ils sont liés aux interprètes dans l'esprit des gens, bien qu'ils puissent exister indépendamment.

Il existe également d'autres approches pour rendre l'implémentation de Python plus rapide, en dehors de l'optimisation du code de l'interpréteur lui-même - par exemple, le projet HotPy (2). Mais ces approches sont actuellement au stade de la recherche ou de l'expérimentation, et doivent encore montrer leur efficacité (et leur maturité) par rapport au code réel.

Et bien sûr, les performances d'un programme spécifique dépendent du programme lui-même bien plus que de l'implémentation du langage. L'implémentation du langage ne fait que fixer une limite supérieure à la vitesse à laquelle vous pouvez effectuer une séquence d'opérations. En général, vous pouvez améliorer les performances d'un programme en évitant tout travail inutile, c'est-à-dire en optimisant le programme. Cela est vrai indépendamment du fait que vous exécutiez le programme par le biais d'un interprète, d'un compilateur JIT ou d'un compilateur en avance sur le temps. Si vous voulez que quelque chose soit rapide, ne faites pas d'efforts pour obtenir une implémentation plus rapide du langage. Il existe des applications qui ne sont pas réalisables avec les frais d'interprétation et de dynamisme, mais elles ne sont pas aussi courantes que vous le pensez (et souvent, elles sont résolues en faisant appel au code machine compilé de manière sélective).

Answer 2

La seule implémentation de Python qui dispose d'un JIT est PyPy . Byt - PyPy est à la fois une implémentation de Python 2 et une implémentation de Python 3.

Answer 3

Le projet Numba devrait fonctionner sur Python 3. Bien que ce ne soit pas exactement ce que vous avez demandé, vous pouvez l'essayer : https://github.com/numba/numba/blob/master/docs/source/doc/userguide.rst .

Il ne prend pas en charge toute la syntaxe Python pour le moment.

Answer 4

Vous pouvez essayer le branche pypy py3 qui est plus ou moins compatible avec python, mais l'implémentation officielle de CPython n'a pas de JIT.

Answer 5

La meilleure réponse à cette question sera donnée par les remarquables développeurs Python de ce site.

Je veux quand même faire un commentaire : Lorsque l'on parle de la vitesse des langages interprétés, j'aime bien pointer du doigt un projet hébergé à l'adresse suivante cet endroit : Jeu des niveaux de compétence en langage informatique

C'est un site dédié à l'exécution de benchmarks. Il y a des tâches spécifiques à effectuer. N'importe qui peut soumettre une solution dans sa langue préférée, puis les tests comparent le temps d'exécution de chaque solution. Les solutions peuvent faire l'objet d'un examen par les pairs, sont souvent améliorées par d'autres, et les résultats sont vérifiés par rapport aux spécifications. À long terme, il s'agit du système d'évaluation le plus équitable pour comparer différents langages.

Comme vous pouvez le voir dans des résumés indicatifs comme celui-ci les langages compilés sont assez rapides par rapport aux langages interprétés. Cependant, la différence ne réside probablement pas tant dans le type exact de compilation que dans le fait que Python (et les autres dans le graphe plus lent que python) sont entièrement dynamiques. Les objets peuvent être modifiés à la volée. Les types peuvent être modifiés à la volée. Ainsi, certaines vérifications de types doivent être reportées au moment de l'exécution, plutôt qu'au moment de la compilation.

Ainsi, même si vous pouvez discuter des avantages du compilateur, vous devez tenir compte du fait qu'il existe différentes fonctionnalités dans différents langages. Et ces fonctionnalités peuvent avoir un prix intrinsèque.

Enfin, en ce qui concerne la vitesse : le plus souvent, ce n'est pas la langue ou la lenteur perçue d'une langue qui pose problème, mais un mauvais algorithme. Je n'ai jamais eu à changer de langage parce que l'un d'entre eux était trop lent : quand il y a un problème de vitesse dans mon code, je corrige l'algorithme. Cependant, si votre code contient des boucles qui demandent beaucoup de temps et d'efforts de calcul, il est nécessaire de corriger l'algorithme. es Cela vaut généralement la peine de les recompiler. Les bibliothèques codées en C utilisées par les langages de script en sont un exemple frappant (les librairies XS de Perl, ou par exemple numpy/scipy pour Python, lapack/blas sont des exemples de librairies disponibles avec des liens pour de nombreux langages de script).