Discussion :

[Anthony]

Le plan de travail pour la future version 3.13 de Python a été dévoilé, et vise la réduction d'au moins 50 % du temps passé dans l'interpréteur ainsi qu'une meilleure gestion de la mémoire

Les développeurs Mark Shannon et Michael Droettboom viennent d'annoncer leur plan de travail pour Python 3.13. Ce plan comprend notamment des travaux sur la gestion de la mémoire, sur l'activation des sous-interprètes à partir de Python et sur la réduction du temps passé dans l'interpréteur.

Vue d'ensemble

Le plan pour la 3.13 est similaire aux premiers plans pour la 3.12.

La grande différence est que nous avons maintenant terminé le travail de base dont nous avons besoin :

• La surveillance à faible impact (PEP 669) est implémentée.
• Le compilateur de bytecode est en bien meilleur état.
• Le générateur d'interprètes fonctionne.
• Les expériences sur la machine à registres sont terminées.
• Nous disposons d'une approche viable pour créer un générateur de code machine facile à maintenir, à faible surcharge et basé sur le copy-and-patch.

Nous prévoyons trois travaux parallélisables pour la version 3.13 :

• L'optimiseur Tier 2
• Activation des sous-interprètes à partir du code Python (PEP 554).
• Gestion de la mémoire

L'optimiseur Tier 2

Voir Optimiseur Tier 2 pour une explication de ce qu'est l'optimiseur de niveau 2.

Le plan de travail est à peu près le suivant :

• Faire fonctionner l'interpréteur de niveau 2
• Générer des superblocs (de mauvaise qualité)
• Mise en œuvre d'une gestion de base des superblocs
• En parallèle :
• Ajouter le support de la désoptimisation aux superblocs
• Améliorer le code de création des superblocs
• Mise en œuvre du spécialisateur
• Implémentation de l'évaluateur partiel
• Implémentation du générateur de code machine copy-and-patch
  
  • Intégration build-time
  • Génération de code de niveau 2

Notre objectif pour la version 3.13 est de réduire d'au moins 50 % le temps passé dans l'interpréteur.

Plan détaillé.
Plan détaillé pour copy-and-patch.

Activation des sous-interprètes à partir de Python

Contrairement aux autres tâches, qui sont principalement axées sur les performances d'un seul thread, ce travail s'appuie sur le travail GIL par interprète qui a été livré dans Python 3.12 pour permettre aux programmeurs Python de tirer parti d'un meilleur parallélisme dans les sous-interprètes à partir du code Python (sans avoir besoin d'écrire une extension C).

Un projet de PEP 554 existe déjà pour ce travail. La première étape consistera à le mettre à jour et à demander une approbation rapide, afin que nous puissions changer de cap si nécessaire.

Plan détaillé.

Meilleure gestion de la mémoire

Les données de profilage montrent qu'un temps assez important est consacré à la gestion de la mémoire et au cycle GC. Cette fraction ne fera qu'augmenter au fur et à mesure que nous accélérerons le reste de la VM.

Contrairement aux tâches précédentes, nous sommes moins sûrs des solutions appropriées, c'est pourquoi il faut d'abord poursuivre la recherche et l'expérimentation. Nous prévoyons d'en faire un projet secondaire basé sur ce que nous avons appris du travail de niveau 2 ci-dessus.

Nous voulons

• Réduire le nombre d'allocations en améliorant les structures de données. Nous espérons également que l'évaluation partielle réduira le nombre d'objets temporaires, mais cela fait partie du champ d'application de l'optimiseur de niveau 2, et non de la gestion de la mémoire.
• Passer moins de temps à faire des GC de cycle. Cela peut être aussi simple que de faire moins de collections, ou aussi complexe que d'implémenter un nouveau chercheur de cycle incrémental.

Source : GitHub

Et vous ?

Qu'en pensez-vous ?

Quelles fonctionnalités attendez-vous de cette future version de Python ?

Voir aussi

Python 3.12.0b1, la première des quatre versions bêta de la 3.12, a été publiée, et apporte de nouvelles fonctionnalités ainsi que des corrections de bogues

Une nouvelle version alpha de Python 3.12, plus rapide et plus légère, est désormais disponible, et apporte plusieurs améliorations au niveau du multitraitement et de la gestion des erreurs

Python 3.11 est disponible et s'accompagne d'une amélioration de la vitesse, de meilleures gestions des erreurs, du type self ainsi que des notes d'exception

[Mathis Lucas]

Python 3.13 ajoute un compilateur JIT qui pourrait améliorer les performances du langage d'environ 9 %
mais l'annonce suscite des réactions mitigées

Python 3.13, la prochaine mouture du langage de programmation, devrait être livrée avec un compilateur JIT (Just in Time). Cet ajout, réalisé à la fin de l'année dernière par le développeur principal de CPython, Brandt Bucher, constitue une modification substantielle de l'interpréteur CPython. Les premiers benchmarks montrent une amélioration des performances de 2 à 9 %. Bien que cela puisse sembler modeste, cela jette les bases d'optimisations plus importantes à l'avenir. Cette mise à jour du langage ne vise pas seulement à obtenir des gains de performance immédiats, mais aussi à jeter les bases de futures avancées dans l'efficacité de Python.

Python 3.13 devrait être livré avec un compilateur JIT de type "copy-and-patch"

Un compilateur JIT est un compilateur qui compile le code au moment de de l'exécution. Cela signifie que le code n'est pas compilé avant d'être exécuté, mais qu'il est compilé au fur et à mesure des besoins. Les compilateurs JIT sont souvent utilisés pour les langages interprétés - comme Perl, Ruby, PHP et JavaScript - car ils peuvent améliorer les performances du langage. Ces langages sont largement utilisés dans le développement Web, l'écriture de scripts et les tâches d'automatisation en raison de leur facilité d'utilisation et de leur processus de développement rapide. Python, qui est un langage interprété, ne disposait pas d'un compilateur JIT jusqu'ici.

En décembre 2023, Brandt Bucher a soumis une demande de fusion proposant d'ajouter un compilateur JIT à Python. Si cette proposition est acceptée, il s'agira de l'un des grands changements apportés à l'interpréteur CPython depuis l'interpréteur adaptatif spécialisé ajouté à Python 3.11. (Cet ajout a été réalisé par Mark Shannon et Brandt Bucher.) Le comportement d'un compilateur JIT diffère de celui d'un compilateur AOT (Ahead of Time) - comme le compilateur GNU C (GCC) ou Rustc de Rust. Ce dernier génère le code machine une fois et le distribue en tant qu'exécutable binaire. Le compilateur JIT proposée pour Python 3.13 est de type "copy-and-patch".

La compilation de type "copy-and-patch" est une technique de compilation simple destinée à la compilation juste à temps. Elle utilise la correspondance de motifs pour faire correspondre des modèles prégénérés à des parties d'un arbre syntaxique abstrait ou d'un flux de bytecode et émet un code précrit correspondant qui est ensuite collé pour insérer des adresses de mémoire, des adresses de registre, des constantes et d'autres paramètres afin de produire un code exécutable. Le code qui ne correspond pas aux modèles peut être soit interprété de manière normale, soit créé pour appeler directement le code de l'interpréteur.

En d'autres termes, un JIT de type "copy-and-patch" consiste à copier les instructions pour chaque commande et à remplir les blancs pour les arguments du bytecode. Le compilateur JIT de type "copy-and-patch" aurait été choisi pour sa simplicité et son efficacité par rapport à un compilateur JIT complet. Il évite la complexité et les ressources nécessaires à la compilation des bytecodes de haut niveau dans un langage intermédiaire, puis dans le code machine. Cette approche est particulièrement bénéfique pour le langage Python, qui fonctionne sur différentes architectures de CPU. Le "copy-and-patch" est une technique de compilation très jeune.

Le concept du "copy-and-patch" a été décrit pour la première fois par Fredrik Kjolstad et Haoran Xu dans un article datant de 2021. Une implémentation du "copy-and-patch" basée sur le bytecode est utilisée pour le compilateur JIT de Python 3.13. Selon un billet de blogue sur le sujet, les premiers benchmarks ont révélé que cette technique améliore les performances de 2 à 9 %. Bien que cela puisse sembler modeste, cela jette les bases d'optimisations plus importantes à l'avenir. Cette mise à jour ne vise pas seulement à obtenir des gains de performance immédiats, mais aussi à jeter les bases de futures avancées dans l'efficacité de Python.

L'ajout d'un compilateur JIT à Python suscite des réactions mitigées sur la toile

L'impact réel du compilateur JIT de Python sera déterminé par les optimisations futures qu'il permettra d'effectuer. Certains utilisateurs du langage sont ravis par cet ajout et affirment que cela ouvre la voie à de nouvelles possibilités à l'avenir et aidera à combler certaines lacunes. Cependant, certains critiques trouvent que cet ajout ne constitue pas un apport significatif au langage et que les ressources consacrées à ce développement pouvaient servir à soutenir des projets comme PyPy. D'autres estiment que Python sans JIT est déjà assez rapide dans la plupart des cas et que cet ajout semble destiné aux cas d'utilisation de calcul haute performance.

« Je pense que Python sans JIT est déjà assez rapide dans la plupart des cas. Je ne fais pas de science des données », note un critique. Un autre a écrit : « je ne vois tout simplement pas comment un compilateur JIT va faire une si grande différence. Nous avons déjà PyPy pour ceux qui ont besoin de performances purement Python et Numba pour certains types de besoins numériques ». On peut lire également : « CPython n'était-il pas censé rester très simple dans sa base de code, l'optimisation lourde étant laissée à d'autres implémentations ? J'aimerais que l'argent puisse être dépensé pour PyPy, résoudre les problèmes et le rendre plus performant ».

L'on peut relever quelques raisons pour lesquelles Python n'avait pas un compilateur JIT. Tout d'abord, Python est conçu pour être un langage portable. Cela signifie qu'il est conçu pour fonctionner sur une variété de plateformes différentes, dont Windows, Mac et Linux. Les compilateurs JIT peuvent être spécifiques à une plateforme, ce qui peut rendre difficile le portage d'un langage utilisant un compilateur JIT sur une nouvelle plateforme. Ensuite, Python est conçu pour être facile à apprendre et à utiliser. Les compilateurs JIT peuvent ajouter de la complexité à un langage, ce qui peut rendre son apprentissage et son utilisation beaucoup plus difficiles.

Enfin, Python est déjà un langage "très rapide". Même sans compilateur JIT, Python est souvent plus rapide que d'autres langages interprétés, tels que JavaScript. Bien que Python ne dispose pas d'un compilateur JIT, il existe un certain nombre de moyens d'améliorer les performances du code Python. L'une d'entre elles consiste à utiliser un accélérateur Python - comme PyPy et Nuitka. Les accélérateurs Python sont des compilateurs qui compilent le code Python en code machine natif. Cela peut améliorer considérablement les performances du code Python. Un autre moyen d'améliorer les performances du code Python est d'utiliser un profileur.

Un profileur est un outil qui vous permet d'analyser l'exécution d'un programme afin d'identifier les parties du code qui consomment le plus de ressources en matière de temps CPU, de mémoire, ou d'autres métriques de performance. En d'autres termes, il vous aide à identifier les parties de votre code qui sont lentes. Une fois que vous avez identifié ces parties, vous pouvez les optimiser pour améliorer les performances. Enfin, vous pouvez aussi améliorer les performances du code Python en utilisant un bon EDI. Un bon EDI peut vous aider à écrire un code efficace et peut également vous aider à identifier et à résoudre les problèmes de performance.

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'ajout d'un compilateur JIT de type "copy-and-patch" à Python ?
Était-il nécessaire ? En quoi l'ajout d'un compilateur JIT pourrait-il impacter l'avenir de Python ?
Que pensez-vous des avis selon lesquels les ressources auraient pu être consacrées à d'autres projets ?

Voir aussi

Le plan de travail pour la future version 3.13 de Python a été dévoilé et vise la réduction d'au moins 50 % du temps passé dans l'interpréteur ainsi qu'une meilleure gestion de la mémoire

PyPy quitte Mercurial pour GitHub et affirme que "l'open source est devenu synonyme de GitHub", le projet s'attend à une meilleure visibilité et à plus d'engagements avec ce changement

Popularité des langages sur GitHub : Python, Go et JavaScript en progression, tandis que Java et C++ sont en légère baisse mais restent dans le Top 5, d'après GitHut 2.0