CPython peut être défini à la fois comme un interpréteur et un compilateur , car il compile le code Python en bytecode avant de l'interpréter. Il possède une interface de fonctions externes avec plusieurs langages, dont le C, pour lesquels il est nécessaire de définir explicitement les liaisons dans un langage autre que Python.
verrou global d'interpréteur (GIL), ce qui garantit que pour chaque processus d'interpréteur CPython , un seul thread peut traiter du bytecode à la fois. Cela ne signifie pas pour autant que le multithreading est inutile ; le scénario le plus courant est celui où les threads attendent principalement la fin de processus externes.Cela peut se produire lorsque plusieurs threads traitent des données de clients distincts. Un thread peut attendre la réponse d'un client, un autre l'exécution d'une requête de base de données , tandis que le troisième thread exécute du code Python.
Cependant, le GIL signifie que CPython n'est pas adapté aux processus qui implémentent des algorithmes gourmands en ressources CPU dans du code Python susceptible d'être distribué sur plusieurs cœurs.
Dans les applications concrètes, les situations où le GIL constitue un goulot d'étranglement important sont plutôt rares. En effet, Python est un langage intrinsèquement lent et n'est généralement pas utilisé pour des opérations gourmandes en ressources CPU ou sensibles au temps. Python est généralement utilisé au niveau supérieur et appelle des fonctions de bibliothèques pour effectuer des tâches spécialisées. Ces bibliothèques ne sont généralement pas écrites en Python, et du code Python peut être exécuté dans un autre thread pendant qu'un appel à l'un de ces processus sous-jacents a lieu. La bibliothèque non-Python appelée pour effectuer la tâche gourmande en ressources CPU n'est pas soumise au GIL et peut exécuter simultanément de nombreux threads sur plusieurs processeurs sans restriction.
L'exécution concurrente de code Python n'est possible qu'avec des processus d'interpréteur CPython distincts, gérés par un système d'exploitation multitâche . Cela complexifie la communication entre ces processus , même si le module multiprocessing atténue quelque peu ce problème ; ainsi, les applications qui tirent réellement parti de l'exécution concurrente de code Python peuvent être implémentées avec une surcharge limitée .
La présence du GIL simplifie l'implémentation de CPython et facilite la création d'applications multithread qui ne tirent pas profit de l'exécution concurrente de code Python. En revanche, sans GIL, les applications multiprocessus doivent s'assurer que tout le code partagé est thread-safe.
Bien que de nombreuses propositions aient été faites pour éliminer le GIL, il est généralement admis que, dans la plupart des cas, ses avantages l'emportent sur ses inconvénients. Dans les rares cas où le GIL constitue un goulot d'étranglement, l'application devrait être conçue autour d'une architecture multiprocessus. Afin de favoriser un plus grand parallélisme, une amélioration a été publiée en octobre 2023 permettant d'utiliser un GIL distinct par sous-interpréteur au sein d'un même processus Python ; ce système a été décrit comme des « threads avec partage optionnel ».
Après plusieurs débats, un projet a été lancé en 2023 pour proposer de rendre le GIL optionnel à partir de la version 3.13 de Python, qui a été publiée le 7 octobre 2024, dans Python 3.13.0.
Histoire
En 2021, un « interpréteur adaptatif spécialisé » (SAI) a été proposé. Ce dernier permettrait d'améliorer les performances de 10 à 60 % en spécialisant les instructions fréquemment exécutées, présentant une stabilité de type apparente , en instructions plus rapides et spécifiques à leur type. Il pourrait également déspécialiser les instructions si nécessaire. Le SAI a été intégré pour la première fois à Python 3.11, qui, selon la suite de tests « pyperformance », était en moyenne 25 % plus rapide que Python 3.10.
En 2024, un compilateur JIT expérimental a été intégré à la branche de développement principale de CPython. Ce compilateur JIT préliminaire repose sur LLVM et vise à accélérer l'exécution des portions de code fréquemment utilisées . Au moment de l'intégration, il n'était pas encore inclus dans les configurations de compilation par défaut de CPython et offrait des performances similaires à celles du SAI ; l'une des conditions pour son adoption généralisée était un gain de performance d'au moins 5 %. Il reste désactivé par défaut, mais les utilisateurs peuvent l'activer pour expérimenter et observer comment Python pourrait à terme rivaliser avec d'autres langages utilisant la compilation JIT.
Distribution
Les plateformes de niveau 1 officiellement prises en charge sont Linux pour Intel 64 bits avec une chaîne d'outils GCC, macOS pour Intel et ARM 64 bits, et Microsoft Windows pour Intel 32 et 64 bits. La prise en charge officielle de niveau 2 concerne Linux pour ARM 64 bits, wasm32 ( WebAssembly ) avec prise en charge de l'environnement d'exécution WASI, et Linux pour Intel 64 bits avec une chaîne d'outils clang. Les systèmes de niveau 3 officiellement pris en charge incluent Windows ARM 64 bits, iOS 64 bits, Raspberry Pi OS (Linux pour armv7 avec virgule flottante matérielle), Linux pour PowerPC 64 bits en mode little-endian, et Linux pour s390x .
D'autres plateformes disposent d'implémentations fonctionnelles, notamment :
- De type Unix
- Spécial et intégré
- Autre