La prochaine version de l'interpréteur Python standard, CPython, va s'accompagner d'améliorations significatives des performances ont annoncé les développeurs durant la PyCon
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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.