Python 3.11 est actuellement dans la première phase bêta de sa Preview avant sa version stable plus tard cette année. Le développeur de Core Python (CPython), Mark Shannon, a partagé des détails sur le projet visant à rendre Python plus rapide lors de la conférence PyCon 2022, pendant laquelle les développeurs ont également montré des progrès sur l'objectif d'exécuter du code Python dans le navigateur. L'année dernière, Microsoft a financé un projet pour la Python Software Foundation (PSF), dirigé par le créateur de Python Guido van Rossum et Shannon, pour rendre Python deux fois plus rapide que la série 3.10 stable actuelle. L'objectif est de pousser Python vers les performances de C.Microsoft a embauché van Rossum en 2020 et lui a donné carte blanche pour choisir n'importe quel projet. Lors de la conférence PyCon 2021 de l'année dernière, il a déclaré qu'il a choisi de « revenir à mes racines » et qu'il travaillerait sur le manque de performances de Python.
La prochaine version de l'interpréteur Python standard, CPython, est attendue en octobre. Elle s'accompagnera d'améliorations significatives des performances et d'une prise en charge de l'exécution dans le navigateur.
La semaine dernière, le premier sommet sur le langage Python depuis 2019 a eu lieu à Salt Lake City. Lors de l'événement, l'équipe de développement du langage a annoncé divers changements pour la prochaine version du langage, ainsi que son avenir proche.
Il existe plusieurs éditions de Python, y compris des interpréteurs pour JVM et .NET CLR, ainsi que des compilateurs, mais l'implémentation principale du langage est l'interpréteur CPython. Cela présente certaines limitations bien connues, notamment le Global Interpreter Lock ou GIL, qui empêche le langage de tirer pleinement parti des processeurs multicœurs.
Il a longtemps été possible qu'un même processus contienne plusieurs interpréteurs, mais ils interfèrent les uns avec les autres, car ils doivent tous partager le même GIL. L'effort d'Eric Snow pour résoudre ce problème est le GIL par interprète : donner à chaque interprète son propre GIL.
Une solution plus large consisterait à supprimer complètement le GIL. Un effort précédent pour ce faire, la GILectomie de Larry Hastings, a été bloqué, mais un nouveau est déjà allé plus loin et pourrait encore réussir. La nouvelle fonctionnalité s'appelle simplement nogil et est en cours d'élaboration par le développeur Meta Sam Gross.
Ce n'est pas la première fois que le propriétaire de Facebook (Meta) apporte des changements plus rapides. Apparemment, Instagram, propriété de Meta, utilise très fortement Python et fonctionne sur une version interne appelée Cinder, mais celle-ci est spécialisée pour les besoins de l'entreprise et n'est pas destinée à la consommation générale. Le nouvel effort devrait être plus largement applicable.
Ces changements peuvent être en petite partie dus à un autre poids lourd de l'industrie. En 2018, Guido van Rossum, le Python Benevolent Dictator For Life, a pris sa retraite, mais quelques années plus tard, il a changé d'avis et est retourné travailler - chez Microsoft. Cette dernière entreprise verse un salaire à des personnes comme Van Rossum et Mark Shannon (qui travaillent à plein temps sur l'accélération de CPython et dirigent l'équipe Microsoft). Jusqu'à présent, la version bêta de CPython 3.11 est en moyenne environ 25 % plus rapide en matière d'analyse comparative.
Le projet d'accélération a également une feuille de route des changements futurs, et le blog de la Python Software Foundation explique les plans plus en détail.
La perspective de la Python Software Foundation
Python 3.11, si vous ne l'avez pas entendu, est rapide. Au cours de l'année écoulée, Microsoft a financé une équipe - dirigée par les principaux développeurs Mark Shannon et Guido van Rossum - pour travailler à plein temps sur l'accélération de CPython. Avec un financement supplémentaire de Bloomberg et l'aide d'un large éventail d'autres contributeurs de la communauté, les résultats ont porté leurs fruits. Sur les benchmarks pyperformance au moment de la sortie de la version bêta, Python 3.11 était environ 1,25 fois plus rapide que Python 3.10, une réalisation phénoménale.
Mais il reste encore beaucoup à faire. Lors du Python Language Summit 2022, Mark Shannon a présenté la prochaine étape du projet Faster CPython. L'avenir est rapide.
Le premier problème soulevé par Shannon était un problème de mesures. Afin de savoir comment rendre Python plus rapide, nous devons savoir à quel point Python est actuellement lent. Mais lent à faire quoi, exactement ? Et à quel point ?
De bons benchmarks sont essentiels pour un projet qui vise à optimiser Python pour une utilisation générale. Pour cela, l'équipe Faster CPython a besoin de l'aide de la communauté dans son ensemble. Le projet « a besoin de plus de repères », a déclaré Shannon - il doit comprendre plus précisément pourquoi la base d'utilisateurs dans son ensemble utilise Python, comment ils le font et ce qui le rend lent pour le moment (si c'est lent !) .
Une référence, a expliqué Shannon, est « juste un programme que nous pouvons chronométrer ». Toute personne ayant une référence - ou même simplement une suggestion de référence ! – qu'elle pense être représentatif d'un projet plus vaste sur lequel elle travaille est invitée à les soumettre au suivi des problèmes du référentiel python/pyperformance sur GitHub.
Néanmoins, l'équipe Faster CPython a de quoi s'occuper entre-temps.
Une grande partie du travail d'optimisation dans 3.11 a été réalisée grâce à la mise en œuvre de PEP 659, un « interpréteur adaptatif spécialisé ». L'interpréteur adaptatif que Shannon et son équipe ont introduit suit les bytecodes individuels à différents moments de l'exécution d'un programme. Lorsqu'il repère une opportunité, un bytecode peut être « accéléré » : cela signifie qu'un bytecode lent, qui peut faire beaucoup de choses, est remplacé par l'interpréteur par un bytecode plus spécialisé qui est très bon pour faire une chose spécifique. Le travail sur la PEP 659 est maintenant en grande partie fait, mais des parties importantes, telles que les spécialisations dynamiques des boucles for et les opérations binaires, doivent encore être achevées.
Shannon a noté que Python a également essentiellement la même consommation de mémoire en 3.11 qu'en 3.10. C'est quelque chose sur lequel il aimerait travailler : une surcharge de mémoire plus petite signifie généralement moins d'opérations de comptage de références dans la machine virtuelle, une surcharge de collecte de mémoire plus faible et des performances plus fluides en conséquence.
Une autre grande piste d'optimisation restante est la question des extensions C. L'interface simple de CPython avec C est son principal avantage par rapport aux autres implémentations Python telles que PyPy, où les incompatibilités avec les extensions C sont l'un des plus grands obstacles à l'adoption par les utilisateurs. Le travail d'optimisation qui a été fait dans CPython 3.11 a largement ignoré la question des modules d'extension, mais Shannon veut maintenant ouvrir la possibilité d'exposer des API de fonction de bas niveau à la machine virtuelle, réduisant ainsi le temps de communication entre le code Python et Code C.
Est-ce un JIT que je vois à l'horizon ?
Enfin, mais non des moindres, Shannon a déclaré : « tout le monde veut un compilateur JIT... même si cela n'a pas encore de sens ».
Un compilateur JIT ("just-in-time"
est le nom donné à un compilateur qui détecte dynamiquement où les goulots d'étranglement de performances existent dans un programme pendant que le programme est en cours d'exécution. Une fois ces goulots d'étranglement identifiés, le JIT compile ces parties du programme à la volée en code machine natif afin d'accélérer les choses. C'est une idée semblable à la PEP 659 de Shannon, mais qui va beaucoup plus loin, puisque l'interpréteur adaptatif spécialisé ne dépasse jamais le niveau du bytecode.L'idée d'utiliser un compilateur JIT pour Python n'est pas nouvelle. Le compilateur JIT de PyPy est la principale source des gains de performances importants du projet par rapport à CPython dans certains domaines. Des projets tiers, tels que pyjion et numba, apportent une compilation juste à temps à CPython qui n'est qu'à un pip d'installation. Cependant, intégrer un JIT au cœur de CPython serait sensiblement différent.
Shannon a toujours exprimé son scepticisme quant à la sagesse d'introduire un compilateur JIT dans CPython lui-même, et a déclaré que le travail sur l'introduction d'un compilateur est encore loin. Un JIT, selon Shannon, n'arrivera probablement pas avant la version 3.13 au plus tôt, étant donné la quantité de fruits à portée de main qui reste à travailler. La première étape vers un JIT, a-t-il expliqué, serait de mettre en œuvre un interpréteur de traces, ce qui permettrait de mieux tester les concepts et de jeter les bases de futurs changements.
Bien jouer avec les autres projets Python
Les gains réalisés par l'équipe de Shannon sont extrêmement impressionnants et susceptibles de profiter profondément à la communauté dans son ensemble. Mais divers problèmes pointent à l'horizon. La proposition de Sam Gross pour une version de CPython sans le Global Interpreter Lock (le fork nogil) a le potentiel d'accélérer le code Python multithread de manière très différente du travail de l'équipe Faster CPython - mais cela pourrait aussi être problématique pour certaines des optimisations qui ont déjà été mises en œuvre, dont beaucoup supposent que le GIL existe. Le rêve d'Eric Snow de réaliser plusieurs sous-interprètes au sein d'un même processus, quant à lui, aura un impact moindre sur les performances du code à un seul thread par rapport à nogil, mais pourrait encore créer quelques complications mineures pour l'équipe de Shannon.
Sources : Plan de mise en œuvre pour accélérer CPython, Python Software Foundation