Python est un langage de programmation de haut niveau
La nouvelle a récemment annoncé que le comité directeur du projet Python avait annoncé son désir d’approuver la proposition d’extension de langage Python PEP-0703 , de rendre le verrouillage global de l’interpréteur facultatif dans CPython et de définir essentiellement l’intégration du mode de compilation CPython sans Global Interpreter Lock (GIL).
PEP-0703 définit l’arrêt de l’utilisation de GIL par défaut, mais ajoute l’option de construction “-sin-gil” pour le désactiver. En tant que tel, le nouveau mode est destiné à résoudre le problème de parallélisation des opérations sur les systèmes multicœurs, causé par le fait que le verrou global ne permet pas l’accès parallèle aux objets partagés à partir de différents threads.
Il est mentionné qu’à long terme (après 5 ans), l’interpréteur est prévu par défaut uniquement en mode de verrouillage non global , tout en cessant en même temps de prendre en charge la compilation avec GIL.
Merci à tous d’avoir répondu à l’enquête sur la proposition de non-GIL. Force est de constater que le sentiment général est positif, tant pour l’idée générale que pour la PEP 703 en particulier. Le conseil d’administration est également largement positif sur les deux. Nous avons l’intention d’accepter la PEP 703, bien que nous travaillions toujours sur les détails de l’acceptation.
Comme nous l’avons fait à quelques reprises dans le passé, nous voulons communiquer notre intention d’accepter le PEP ainsi que notre réflexion actuelle sur les détails liés à l’acceptation.
En plus de cela, il est mentionné que les changements qu’il est prévu d’effectuer seront effectués en trois étapes, qui sont à court, moyen et long terme. Puisque dans la première étape, désactiver GIL par défaut n’est pas pratiqueen raison de la surcharge associée aux modifications apportées au ramasse-miettes, au système de gestion de la mémoire et aux primitives d’organisation des verrous. Par exemple, en raison de l’utilisation du comptage de références pour l’isolation des threads, les performances des scripts à thread unique diminuent (de 10 % dans la suite de tests pyperformance). Parallèlement, il peut être nécessaire de désactiver le GIL en calcul scientifique, pour lequel le manque de parallélisation est un problème plus sérieux que la vitesse linéaire d’exécution du code.
La deuxième étape attendra essentiellement la confirmation et suffisamment de soutien de la part de la communauté pour rendre l’utilisation de “no-GIL viable” et s’assurer que la version non-GIL est prise en charge mais pas par défaut.
À la dernière étape, no-GIL sera déjà la valeur par défaut et tout vestige de GIL sera supprimé (sans casser inutilement la rétrocompatibilité).
Il est à noter que le travail pour s’éloigner de GIL sera fait avec beaucoup de soin afin de ne pas répéter l’erreur qui s’est produite lors de la promotion de Python 3 : une construction sans GIL devra assurer la compatibilité avec les anciennes versions de Python et tout changement de tiers- code de partie nécessaire pour travailler sur des versions non-GIL devrait également fonctionner sur des versions GIL.
Il n’est pas prévu de renuméroter les versions en Python 4 pour les versions non-GIL, car elles maintiendront la compatibilité ABI.
Tout au long du processus, nous (les principaux développeurs, pas seulement le SC) devrons réévaluer les progrès et les délais suggérés. Nous ne voulons pas que cela devienne un autre combat de dix ans pour la rétrocompatibilité, et nous voulons pouvoir annuler la PEP 703 et trouver une autre solution si cela semble devenir problématique, nous devons donc vérifier régulièrement que la poursuite du travail en vaut la peine.
Nous espérons que cela apporte des éclaircissements sur l’avenir du PEP alors que nous élaborons les détails exacts de l’acceptation. Le SC travaillera pour finaliser l’acceptation dans les semaines à venir.
Avant la transition complète vers les builds non-GIL, nous prévoyons d’obtenir un support communautaire complet pour ces builds, ainsi que de fournir des API C et Python supplémentaires pour permettre un multithreading sécurisé dans le code existant.
Enfin, comme déjà mentionné, il est prévu que la transition vers la troisième étape puisse se produire dans au moins 5 ans et la date probable pour PEP-0703 est la sortie de Python 3.13, prévue pour l’automne prochain.
Si vous souhaitez en savoir plus , vous pouvez consulter les détails dans le lien suivant.
