Python est un langage de programmation de haut niveau.
La nouvelle a récemment éclaté que le Le comité de pilotage du projet Python a annoncé sa volonté d'approuver le Proposition d'extension du langage Python "PEP-0703″, rendant le verrou d'interpréteur global facultatif dans CPython et qui définit essentiellement l'intégration du mode de compilation de CPython sans Global Interpreter Lock (GIL).
PEP-0703 définit pour arrêter d'utiliser GIL par défaut, mais ajoutez l'option de construction "-sin-gil" pour la désactiver. Comment allez-vousl Le nouveau mode devrait résoudre le problème de parallélisation des opérations sur les systèmes multicœurs, causées 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), shell est prévu pour être modifié par défaut uniquement en mode global non verrouillable, tout en abandonnant la prise en charge de 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.
Par ailleurs, Il est mentionné que les changements qu'il est prévu d'effectuer en trois étapes, qui sont à court, moyen et long terme. Car dans un premier temps, désactiver GIL par défaut n'est pas pratique en 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.
Dans la deuxième étape, essentiellement la confirmation sera attendue. et qu'il y a suffisamment de soutien de la part de la communauté pour que l'utilisation de "non-GIL est viable" et assurez-vous que la construction sans GIL est prise en charge mais pas par défaut.
Dans la dernière étape, no-GIL sera déjà la valeur par défaut et tous les vestiges de GIL seront supprimés (sans rompre inutilement la rétrocompatibilité).
On observe que le travail pour s'éloigner de GIL sera fait avec beaucoup de soin pour ne pas répéter l'erreur que s'est-il passé lors de la promotion Python 3 : Une version non-GIL devra garantir la compatibilité avec les anciennes versions de Python, et toute modification de code tierce requise pour fonctionner sur les versions non-GIL devrait également fonctionner sur les 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 versions non GIL, nous prévoyons d'obtenir un support communautaire complet pour ces versions, 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 intéressé à en savoir plus, vous pouvez vérifier les détails dans le lien suivant.