2 pièce(s) jointe(s)
Les créateurs de Python dévoilent leurs plans d'accélération pour Python en le rendant 2 à 5 fois plus rapide
Les créateurs de Python dévoilent leurs plans d'accélération pour Python,
Qui promettent de le rendre 2 à 5 fois plus rapide sans casser aucun code existant
Le langage de programmation Python dispose déjà de nombreux moyens de s'exécuter plus rapidement, qu'il s'agisse des runtimes d'exécution alternatifs comme PyPy ou de modules écrits en C/C++. Mais presque aucune de ces méthodes n'implique l'accélération de CPython lui-même – l'implémentation de référence de Python, écrite en C, qui est la version la plus largement utilisée du langage. Lors du Python Language Summit qui s'est tenu au PyCon 2021 la semaine dernière, le créateur du langage Python, Guido van Rossum, a dévoilé des plans à court et à long terme pour rendre Python plus rapide – d’un facteur de deux à cinq fois plus rapide, voire plus, tout en restant compatibles avec le code existant.
Le langage de programmation est relativement lent dans son implémentation CPython par défaut, bien qu'il existe de nombreux moyens de le rendre plus rapide, notamment des alternatives axées sur les performances comme PyPy. Historiquement, van Rossum ne semblait pas se soucier des performances de Python, privilégiant la simplicité d'un compilateur moins bien optimisé. Mais le créateur du populaire langage de programmation Python a fait part de ses ambitions de le rendre 2 à 5 fois plus rapide, en remédiant à l'une des principales faiblesses de Python par rapport à des langages plus rapides comme le C++.
Son manque de performance explique en partie pourquoi Python a gravité vers la science des données et l'apprentissage automatique, où de nombreuses charges de travail sont confiées aux GPU. L'autre raison de son essor dans ces domaines est la richesse des bibliothèques spécifiques, de NumPy au framework d'apprentissage automatique TensorFlow, soutenu par Google.
Dans le cadre d'une contribution au US PyCon Language Summit 2021, van Rossum a publié un document sur GitHub, propriété de Microsoft, dans lequel il détaille certaines de ses ambitions pour faire de Python un langage plus rapide, promettant de doubler sa vitesse à partir de Python 3.11 – l'une des trois branches de Python qui sortiront l'année prochaine, et actuellement en cours de développement officiel en tant que projet de niveau préalpha.
Le créateur de Python a été embauché en novembre dernier par Microsoft, une entreprise favorable aux logiciels libres, qui l'a fait sortir de sa retraite après un passage chez Dropbox. « Je m'ennuyais à rester assis à la maison pendant ma retraite », a fait savoir van Rossum dans sa présentation, un document PDF. « J'ai postulé chez Microsoft et j'ai été embauché. On m'a donné la liberté de choisir un projet. J'ai choisi de revenir à mes racines. C'est la façon dont Microsoft rend la pareille à Python ».
Microsoft a soutenu Python de diverses manières, notamment par des cours gratuits de Python qui servent de rampe d'accès à ses services d'intelligence artificielle dans Azure Cloud, par le soutien de son extension VS Code Python et par la présence de Python dans Windows 10. Microsoft est également sponsor de la Python Software Foundation (PSF) depuis 2006 et lui a versé 150 000 dollars cette année.
Le projet est une « petite équipe financée par Microsoft », selon van Rossum, afin de « prendre en charge l'amélioration des performances » du langage interprété. Microsoft compte actuellement cinq développeurs principaux qui contribuent au développement de CPython, dont Brett Cannon, Steve Dower, Guido van Rossum, Eric Snow et Barry Warsaw – tous des vétérans de la communauté des développeurs principaux de Python.
Comme Microsoft l'a indiqué dans une note en avril, Snow a travaillé sur les performances multithread en Python via des sous-interpréteurs. Dower sert en tant que build manager et est un expert de CPython pour Windows depuis la version 3.5 de Python. Warsaw contribue au conseil de direction de Python, à l'équipe de réponse à la sécurité de Python et à la liste des gestionnaires de versions de Python. Le projet dispose d'un dépôt GitHub qui comprend un fork de CPython ainsi qu'un "issue tracker" pour les idées et les outils d'analyse des performances.
Les moyens de rendre Python plus rapide et les contraintes pour rester compatibles avec le code existant
Dans la présentation faite lors du Language Summit, van Rossum a décrit comment le plan actuel visant à accélérer Python doit être soumis à de sévères contraintes. Les modifications apportées à CPython ne doivent pas casser l'ABI (application binary interface) du runtime, de sorte que les extensions Python écrites en C continuent de fonctionner telles quelles. Les modifications doivent être incrémentielles et gérables, conformément aux objectifs généraux de CPython, à savoir préserver la maintenabilité et une base de code simple et compréhensible. Et toutes les modifications doivent être open source ; il ne peut y avoir d'extensions propriétaires, de "boîtes noires" à Cpython.
« Ne pas casser la compatibilité stable de l'ABI ; ne pas casser la compatibilité limitée de l'API ; ne pas casser ou ne pas ralentir les cas extrêmes », a promis van Rossum. « Garder un code maintenable », a-t-il ajouté.
Les changements incrémentiels sont une question sensible pour les développeurs Python, qui ont été confrontés à une tâche gigantesque lors du passage du code de Python 2.x à Python 3, qui a pris plus de dix ans. « Pas de forks/branches à longue durée de vie, pas de surprise de 6 000 lignes [pull requests] », a écrit van Rossum. « Nous nous occuperons également de la maintenance et du support... Toutes les discussions dans les trackers sur les dépôts GitHub ouverts », ajoute-t-il.
Dans le cadre de ces contraintes, van Rossum et ses collègues ont identifié quelques parties de Python qui pouvaient être modifiées librement. Le système de bytecode, le compilateur et l'interpréteur de Python ont tous été désignés comme cibles, car ils ont tendance à changer entre les versions. Le bytecode en particulier n'offre aucune garantie de compatibilité entre les versions majeures, il pourrait donc être modifié de façon radicale si nécessaire.
Le plan à court terme consiste à ajouter au moins un ensemble important d'améliorations des performances à Python 3.11. Les premières propositions visant Python 3.11 comprennent un « interpréteur de bytecode adaptatif et spécialisé », comme indiqué dans PEP 659. Les instructions de bytecode qui font référence à un type de données spécifique dans une section particulière du code pourraient être remplacées en ligne par une version "spécialisée" de ce bytecode pour ce type particulier de données, ce qui engendrerait un gain de vitesse, d’après l’équipe. Les développeurs estiment une amélioration potentielle des performances d'environ 50 % dans les meilleurs cas.
D'autres suggestions d'amélioration de la vitesse comprennent l'optimisation de la pile de trames, la modification de la façon dont les appels de fonction sont effectués, la mise en œuvre d'un traitement plus efficace des exceptions, l'ajout d'optimisations qui accélèrent le temps de démarrage et la modification du format de fichier cache du bytecode .pyc.
Tous ces changements ne sont pas à la hauteur de l'une des améliorations les plus couramment suggérées pour Python : la génération de code machine au moment de l'exécution, ou compilation juste à temps ("JIT"). Dans son exposé, van Rossum a suggéré que de tels plans seraient envisagés après Python 3.11, parce qu'il était logique d'obtenir d'abord les améliorations de performance possibles avec des changements plus ciblés.
Mais le projet Python de base sera-t-il réellement capable de doubler la vitesse des versions actuelles de Python ? Le discours de van Rossum suggère qu'il ne veut pas être tenu responsable d'un projet aussi ambitieux. « Nous sommes loin d'être certains d'atteindre 2x ! », a-t-il écrit. « Mais nous sommes optimistes et curieux ».
Néanmoins, il a évoqué l'idée d'une vitesse multipliée par cinq après Python 3.11, notant que « nous devrons être créatifs ». Selon lui, les principaux bénéficiaires des changements à venir dans Python seront ceux qui exécutent du « code Python pur à forte intensité de CPU » et les utilisateurs de sites Web avec Python intégré. Il n'y aura cependant pas beaucoup d'avantages pour le code déjà écrit en C, comme NumPy et TensorFlow, le code lié aux E/S, le code multithreading et le code algorithmiquement inefficace.
La sortie de Python 3.10, actuellement en version bêta, est prévue pour octobre de cette année. Le calendrier de publication étant à peu près annuel, on peut s'attendre à une version 3.11 en octobre 2022.
Sources : Présentation Python Language Summit, Dépôt faster-cypthon
Et vous ?
:fleche: Que pensez-vous des ambitions d’accélération de Python par un facteur de 2 à 5 fois plus rapide, voire plus ?
:fleche: Le projet promet d'accélérer Python tout en restant compatible avec le code existant. Quel est votre avis à ce sujet ?
:fleche: Que pensez-vous des parties de Python que van Rossum et son équipe ont choisies pour être modifiées librement ?
Voir aussi :
:fleche: Guido van Rossum, le créateur du langage de programmation Python, rejoint Microsoft, déclarant que la retraite est "ennuyeuse"
:fleche: Python 3.9 est disponible et s'accompagne de l'ajout des opérateurs "|" et "| =" aux dictionnaires, ainsi que de la possibilité de construire des types génériques dans les collections standard
:fleche: https://python.developpez.com/actu/3...x-navigateurs/
:fleche: Microsoft a intégré Python 3.7 par défaut dans la MàJ Windows 10 mai 2019, de son système d'exploitation
Le plus proche c'est Perl
Citation:
Envoyé par
stef-13013
Très intéressant,
Juste deux points :
"Le créateur de Python a été embauché en novembre dernier par Microsoft, une entreprise favorable aux logiciels libres"
hahahahaha, très bon...
Et s'il faut comparer la vitesse de Python, ce n'est pas par rapport à du compilé mais plutôt à des langages style PHP (et dans une moindre mesure Java, etc.)
J'avais fait des tests sur un tri à bulle. En Perl, 16 secondes, en Python 25 secondes. En C, une fraction de seconde sur un tableau 10 fois plus grand. Et en bash, 100 fois plus lent que Perl ou Python, mais ce n'est pas ce qu'on demande, n'est-ce pas ?
Allez voir du côté de Nim
La syntaxe est hyper proche de Python et l'exe compilé à la vitesse du C et se déploie comme un exe...
