La suppression du GIL et le projet CPython plus rapide

• Le Python Steering Council ayant indiqué son intention d’accepter PEP 703, la suppression du GIL de CPython entre dans un long processus progressif, allant d’un build expérimental au passage en mode par défaut
• La suppression du GIL peut ouvrir la voie à de meilleures performances multithread, mais elle peut aussi avoir un coût pour les performances monothread, qui concernent l’essentiel de l’écosystème existant, ainsi que pour la compatibilité des extensions C
• L’équipe Faster CPython estime que l’interpréteur adaptatif spécialisé fondé sur PEP 659 s’appuie sur le GIL, et qu’en environnement no-GIL il faudra réévaluer les stratégies d’optimisation et la charge de maintenance
• Meta a déclaré qu’en cas d’acceptation de PEP 703, l’entreprise consacrerait 3 engineer-years d’ici fin 2025, tandis qu’Anaconda a promis de soutenir les travaux de packaging autour de pip, cibuildwheel, conda-forge, etc.
• La transition vise à éviter la rupture connue lors du passage de Python 2 à Python 3, et pourra être abandonnée avant la déclaration du mode par défaut si les perturbations liées au no-GIL sont jugées supérieures aux bénéfices

---

Le débat sur la suppression du GIL de Python reprend vraiment

• Le Global Interpreter Lock (GIL) de Python sérialise l’accès à la machine virtuelle de l’interpréteur afin qu’un seul thread à la fois puisse exécuter du code Python
• Le GIL, qui empêche depuis longtemps les gains de performance via l’utilisation de plusieurs threads, est souvent cité comme l’un des vieux points faibles de Python
• En octobre 2021, Sam Gross a publié une version de démonstration no-GIL de Python, mais après l’intérêt initial, les progrès sont restés limités pendant plus d’un an
• Par la suite, le Python Steering Council a annoncé son intention d’accepter la fonctionnalité no-GIL
  • Il faudra du temps avant qu’elle n’arrive dans une version publiée
  • Il reste possible que le travail soit annulé à un moment donné
  • Le soutien de plusieurs entreprises augmente les chances de réussite

Faster CPython et la tension autour des performances monothread

• Lors du Python Language Summit 2022, Gross a présenté son fork no-GIL et a cherché à obtenir un accord implicite pour poursuivre le travail, mais les conséquences détaillées n’étaient pas suffisamment connues et aucun consensus n’a émergé
• À la même période, le projet Faster CPython se concentrait sur l’amélioration des performances monothread de l’interpréteur
• Mark Shannon a rédigé PEP 659 « Specialized Adaptive Interpreter », dont une partie des changements a été intégrée à Python 3.10 et 3.11
• À PyCon, Brandt Bucher, de l’équipe Faster CPython, a présenté les instructions adaptatives, tandis que Shannon a présenté des améliorations de disposition mémoire et d’autres techniques d’optimisation
• Les programmes Python existants étant presque tous écrits en monothread à cause du GIL, les améliorations des performances monothread ont un impact direct sur les performances perçues dans tout l’écosystème Python

La proposition PEP 703 et les premières inquiétudes

• En janvier 2023, Łukasz Langa a publié la première version de PEP 703 « Making the Global Interpreter Lock Optional in CPython », rédigée par Gross
• Parallèlement aux attentes autour du no-GIL, les modules d’extension Python écrits en C sont apparus comme une préoccupation majeure
  • Le GIL a joué un rôle de protection contre de nombreux problèmes de concurrence dans le code d’extension C
  • Sa suppression peut créer de nouveaux bugs dans ce code
• Il existait un consensus sur la nécessité d’éviter une transition en flag day comme lors du passage de Python 2 à Python 3
  • La transition vers la suppression du GIL doit fonctionner en douceur avec le code qui n’est pas encore prêt
• Shannon a demandé quel niveau de dégradation des performances serait acceptable pour le code monothread ; sa propre estimation se situait entre 15 et 20 %, et pouvait être plus élevée selon l’impact sur PEP 659
• Eric Snow, auteur de PEP 684 « Per-Interpreter GIL » et de PEP 683 « Immortal Objects », a publié une longue analyse et estimé que le no-GIL et l’approche par sous-interpréteurs n’étaient pas nécessairement incompatibles

Coûts et bénéfices pour les extensions C

• Gross a répondu que l’impact sur les extensions C n’était pas entièrement négatif
• La PEP inclut des citations de mainteneurs d’extensions C API très utilisées sur la complexité rencontrée pour contourner le GIL
• Zachary DeVito, core developer de PyTorch, a indiqué qu’au cours des derniers mois, il avait passé à trois reprises un ordre de grandeur de temps supplémentaire à comprendre comment contourner les limites du GIL plutôt qu’à résoudre le problème réel
• Le no-GIL peut créer de nouveaux problèmes de concurrence pour les mainteneurs de modules d’extension, mais il peut aussi réduire la complexité nécessaire pour éviter le GIL

PEP mise à jour et controverse sur les performances

• Début mai 2023, Gross a publié une implémentation de PEP 703 basée sur la version de développement de Python 3.12, ainsi qu’une PEP mise à jour
• Le 12 mai, il a demandé au Steering Council de statuer sur la PEP, mais les discussions se sont poursuivies avant toute décision
• Le 2 juin, Shannon a évalué l’impact de la PEP sur les performances et présenté une fourchette de 11 à 30 %, déclenchant une controverse
• Shannon estime que l’interpréteur à spécialisation adaptative dépend du GIL, et qu’en cas d’acceptation du no-GIL, la stratégie d’optimisation devra être repensée
  • Les efforts consacrés à cette refonte et à son implémentation ne pourront pas être investis dans le travail d’optimisation proprement dit
• Langa a publié des chiffres de benchmark montrant un impact bien inférieur aux estimations de Shannon, et les résultats supplémentaires étaient plus proches de ceux rapportés par Gross dans la PEP

Les leçons de la transition Python 2→3

• Guido van Rossum estime que la transition aurait été facilitée si le code Python 2 et Python 3 avait pu coexister dans le même interpréteur
• Il a souligné que si le no-GIL avance, les modules d’extension nécessitant le GIL devraient pouvoir être importés dans un interpréteur no-GIL sans travail supplémentaire
  • Le code applicatif ne devrait pas avoir besoin d’être modifié
  • Les modules d’extension ne devraient pas non plus avoir besoin d’être modifiés
• Gregory P. Smith, membre du Steering Council, a indiqué que le périmètre d’impact de PEP 703 était très large et que le conseil n’était pas prêt à prendre une décision immédiate
• Smith a reconnu l’existence d’une demande, tout en estimant qu’il fallait prendre en compte l’ensemble de l’écosystème et trouver une façon de mener la transition sans casser le monde
• Gross a répondu que retarder la décision sans critères d’acceptation ni calendrier clairs revenait, dans les faits, à dire « non »

Les trois options vues par l’équipe Faster CPython

• Dans la discussion « A fast, free threading Python », Shannon a résumé les choix possibles en trois options
  • Poursuivre le plan existant : un interpréteur monothread rapide
  • Poursuivre un interpréteur free-threading no-GIL, avec un impact inconnu mais non nul sur les performances monothread
  • Poursuivre les deux à la fois
• Shannon estime qu’il faut choisir quoi limiter entre performance, parallélisme et mutabilité
  • Il a formulé cela non pas comme « Performance, parallelism, mutability: pick two », mais plutôt comme « pick one to restrict »
• Il a averti que rendre Python rapide dans un environnement free-threading nécessiterait une recherche originale, avec des coûts et des risques plus élevés
• Sa préférence allait à la troisième option, mais il estime qu’il ne faut pas choisir uniquement le no-GIL en espérant que « quelqu’un résoudra les problèmes de performance »
• van Rossum considère lui aussi que le mieux serait d’obtenir à la fois le free threading et de bonnes performances par thread, mais a souligné qu’il faudrait davantage de ressources

Soutien des entreprises et opinion des développeurs principaux

• van Rossum a indiqué que Microsoft continuerait à soutenir l’équipe Faster CPython, et que le rôle de cette équipe ne se limite pas au travail sur les performances monothread
• L’objectif présenté est d’adapter les travaux de spécialisation et d’optimisation au monde no-GIL, afin de faire à terme du no-GIL l’unique mode de build, sans dégradation des performances monothread
• Carl Meyer, de Meta, a déclaré que si PEP 703 était acceptée, Meta y consacrerait 3 engineer-years d’ici fin 2025
  • Des ingénieurs ayant de l’expérience des internals de CPython collaboreraient avec l’équipe core dev
  • L’implémentation de PEP 703 serait intégrée en douceur à CPython
  • La compatibilité et les performances de CPython no-GIL continueraient d’être améliorées
• Stan Seibert, d’Anaconda, a indiqué qu’il soutiendrait les problèmes de packaging liés à l’adoption de PEP 703
  • Y compris les travaux liés à pip, cibuildwheel et conda-forge
  • Y compris les travaux nécessaires pour livrer à la communauté Python des paquets compatibles no-GIL
• Dans un sondage auprès des core developers, 87 % des 46 répondants ont déclaré qu’il fallait promouvoir activement un Python free-threaded, et 63 % des 38 répondants ont indiqué être prêts à contribuer au support et à la maintenance d’un Python no-GIL basé sur PEP 703

La décision du Steering Council et la transition progressive

• Le 28 juillet, Thomas Wouters a annoncé que le Steering Council avait décidé d’accepter PEP 703, mais que les détails de l’acceptation étaient encore en cours d’élaboration
• L’approche consiste à introduire d’abord un interpréteur no-GIL afin d’identifier les manques, puis à combler le travail nécessaire avant que le no-GIL devienne la valeur par défaut et, finalement, l’unique version
• La période de transition est estimée à environ 5 ans
• Le Council ne souhaite pas revivre une situation à la Python 3, et considère que les modifications nécessaires au code tiers pour s’adapter au build no-GIL doivent continuer à fonctionner telles quelles avec le build with-GIL
• À court terme, un build no-GIL expérimental est envisagé, peut-être à l’époque de Python 3.13
  • Python 3.13 est prévu pour octobre 2024
  • Un build avec lequel les core developers et d’autres pourront expérimenter
• À moyen terme, le no-GIL deviendra une option prise en charge, mais non la valeur par défaut
  • Le calendrier dépendra fortement de la vitesse à laquelle la communauté adoptera et prendra en charge les builds no-GIL
• À long terme, le no-GIL deviendra le build par défaut et le GIL sera entièrement supprimé
  • Cela devra se faire sans casser inutilement la compatibilité descendante

Un travail encore loin d’être terminé

• Wouters estime que la suppression du GIL est un chantier bien plus vaste que l’acceptation d’une seule PEP
• Les core developers doivent acquérir de l’expérience avec Python no-GIL, puis s’en servir pour guider le reste de la communauté
• Le processus de clarification de la thread-safety du code existant pourrait nécessiter de nouvelles API C et Python
• Tout au long du processus, l’avancement et le calendrier devront être réévalués régulièrement
  • Il ne faut pas que cela se transforme en une nouvelle bataille de compatibilité descendante de dix ans
  • Si PEP 703 semble devenir problématique, il doit être possible de l’arrêter et de chercher une autre solution
• Il reste beaucoup de recherche, de code, de tests, d’expérimentation et de documentation avant d’arriver à un Python uniquement no-GIL ; octobre 2028, date possible de Python 3.17, est cité comme exemple

[GN⁺]

Avis de Hacker News

• L’article est bien écrit et résume bien tout le processus, mais il penche plutôt du côté opposé à la suppression du GIL et insiste davantage sur les risques d’échec
  Il faut aussi mettre suffisamment en avant l’autre camp. La qualité du travail de Sam Gross est très élevée, et il a aussi intégré des améliorations de performance sans lien direct avec le no-GIL afin de réduire les pertes de performances. Il a également très bien fonctionné selon une logique open source et a fait preuve de patience, alors même que la réaction du comité de pilotage était si lente que, sans la pression de la communauté, le sujet serait resté longtemps en suspens. Les sous-interpréteurs ont encore rarement démontré leur utilité en Python, surtout avec des métriques sérieuses, et cette initiative est proche de la première tentative bien définie et mesurée. La réaction de la communauté a aussi montré un grand intérêt pour ce projet, et le comité de pilotage a conclu qu’il « avait l’intention d’accepter la PEP 703 et travaillait à préciser les conditions détaillées de son acceptation ». Je ne suis pas un fervent défenseur du no-GIL, cela ne me dérangerait pas qu’il ne soit finalement pas supprimé et je pense qu’il faudrait d’abord essayer les sous-interpréteurs, mais il faut regarder les choses équitablement

  • Du côté des sous-interpréteurs aussi, beaucoup de travail est en cours, et le GIL par interpréteur arrive dans Python 3.12
    Les résultats sont aussi assez impressionnants : https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. Cela semble aussi bon qu’on pouvait l’espérer. Le travail sur les sous-interpréteurs devrait avancer en parallèle du travail sur le free-threading, et les deux répondent à des cas d’usage différents
  • Ce qui m’agace personnellement le plus en Python, c’est la PEP 582, « Python local packages directory » : https://peps.python.org/pep-0582/
    À ma connaissance, PDM la prend encore en charge. Je n’aime pas utiliser virtualenv pour le build et le déploiement, et j’aimerais que Python puisse fonctionner comme JavaScript. Il a déjà été prouvé que c’était possible. Le fil de discussion se trouve sur https://discuss.python.org/t/pep-582-python-local-packages-d.... Il est aussi frustrant de voir « il n’y a qu’une seule bonne façon de faire » utilisé comme motif de rejet, alors que je n’ai jamais eu l’impression que cette phrase soit vraie en Python
  • J’aimerais voir uniquement les patchs de performance, sans la partie no-GIL
  • Je me demande pourquoi les gens s’opposent à la suppression du GIL

• C’est un excellent article de LWN, qui valait vraiment la lecture. Quand le NoGIL de Sam Gross a été publié pour la première fois, j’étais enthousiaste, mais en lisant l’article et en repensant à mon expérience personnelle, j’ai commencé à changer d’avis
  J’ai construit des systèmes backend dans plusieurs langages, et il n’y en avait globalement que deux types. Le premier ouvre des endpoints réseau, reçoit des requêtes, effectue des calculs et d’autres requêtes réseau, puis renvoie une réponse. Le second lit des messages depuis une file, une base de données, le polling d’une autre API, etc., effectue des calculs et des appels réseau, puis envoie le résultat vers une autre file. Dans le premier cas, la latence est importante ; dans le second, c’est le débit. Pour le premier type, NoGIL est utile parce qu’on veut lancer un thread par requête, éviter qu’un endpoint gourmand en calcul bloque les autres requêtes, et partager un pool de connexions à la base de données. Pour le second type, même dans des langages sans GIL, je ne me souviens presque jamais avoir utilisé du parallélisme ou de la concurrence au sein d’un même processus avec des ressources partagées : cela devient trop difficile à comprendre. L’optimisation passait généralement par un traitement par lots intelligent, et le parallélisme consistait à lancer plusieurs processus indépendants sur plusieurs machines. Si NoGIL devait compromettre la qualité des systèmes du second type, ce serait assez décevant, et en pratique la majeure partie de mon énergie mentale sert actuellement à améliorer ce second type

  • Dans le cas de mon application Captain’s Log, le no-GIL est aussi intéressant pour une application GUI
    Aujourd’hui, j’implémente JournalParser avec QThread : ce parseur lit en continu les fichiers de journal joueur générés par Elite: Dangerous et Odyssey, puis émet des QSignal personnalisés pour chaque événement, traités par les slots qui écoutent ces signaux. Dans d’autres parties de l’application aussi, l’absence de GIL pourrait être assez utile. https://captainslog.scarygliders.net/captains-log-2/
  • En tant qu’utilisateur de Python pour le loisir, je n’utiliserai probablement pas directement la concurrence, mais avec le temps, il est très probable que la bibliothèque standard et les bibliothèques externes populaires en tirent parti
    Cela pourrait améliorer le code de tout le monde
  • Il n’est pas nécessaire d’utiliser soi-même directement le parallélisme pour profiter des avantages de NoGIL. Par exemple, un serveur web ou un exécuteur de tâches asynchrones peut partager le contexte plus efficacement entre les threads
  • Le GIL devient un goulot d’étranglement dans les applications liées au CPU, comme le machine learning ; il est donc naturel que NoGIL n’intéresse pas énormément les personnes qui écrivent des applications serveur
    Bien sûr, on pourrait dire qu’il ne faut pas écrire de programmes centrés sur le CPU en Python pour commencer, mais c’est une autre question
  • Je suis justement en train de construire un tel système, et j’ai dû abandonner la stratégie multiprocessus à cause d’une grosse ressource partagée
    Si la ressource partagée est en lecture seule, je ne vois pas très bien en quoi ce serait déroutant

• Je doute que la phrase du fil lié — « il est très peu probable que la suppression du GIL casse une base de code écrite uniquement en Python » — soit réellement correcte
  Certains codes Python multithread peuvent s’attendre, grâce au GIL, à ce que certaines opérations soient implicitement thread-safe. Par exemple, si deux threads ajoutent des éléments à la même liste sans que celle-ci soit corrompue, c’est parce que le GIL empêche les deux threads d’exécuter cette opération en parallèle. Si l’on supprime le GIL, ce genre de code pourrait soudainement être sanctionné, comme lorsqu’on modifie simultanément un std::vector en C++. Je n’en suis pas certain, mais cette phrase me paraît suspecte. https://discuss.python.org/t/pep-703-making-the-global-inter...

  • Exact. C’est une zone que le GIL protégeait de façon triviale. Il existe un cas similaire en Go, où modifier simultanément la même map provoque un panic
    La section sécurité des conteneurs vis-à-vis des threads de la PEP 703 traite ce problème. Elle propose d’ajouter à chaque list, dictionary et set un verrou léger propre à l’objet ; toutes les opérations qui modifient l’objet devraient prendre ce verrou, et la plupart des opérations de lecture aussi. Les détails sont ici : https://peps.python.org/pep-0703/#container-thread-safety
  • C’est effectivement le cas, et il ne semble pas y avoir beaucoup de solutions évidentes, à part protéger toutes les opérations sur les structures de données intégrées par un mutex, comme les premières structures de données de Java, Hashtable et Vector
    Cela dit, il reste alors la question de savoir quoi faire quand on a besoin d’un [] non synchronisé
  • L’append sur les listes sera probablement protégé par un verrou par instance. C’est du moins ce que font certains codes conceptuels nogil
  • Une solution naïve serait peut-être d’avoir un indicateur qui active le GIL par défaut, et qui affiche un avertissement lorsqu’on le désactive

• Il est difficile d’imaginer une mise à l’épreuve plus ardue pour l’open source
  La décision elle-même est raisonnable. Avancer en mode test, traiter les multi-interpréteurs comme une expérimentation intermédiaire, tout en gardant pour objectif un Python capable d’exécution concurrente. Mais la contrainte consistant à faire tourner l’ancien et le nouveau code dans la même machine virtuelle est énorme. Il est surprenant que le résumé de LWN aborde à peine les tests : la question des tests est encore loin d’être résolue, et pourrait mener à des versions contenant des bugs inconnus mais graves. Microsoft, Facebook/Meta et Conda fournissent des ressources, et l’écrasante majorité des contributeurs principaux veulent avancer, mais on ne sait pas ce qui se passera si les choses deviennent plus difficiles et qu’il faut davantage de monde. Dans le même temps, d’immenses projets académiques et industriels, des sites web au big data en passant par l’IA, dépendent de Python, et le coût reporté sur les développeurs Python pourrait se mesurer en points de PIB. Comme les problèmes ne semblent même pas encore tous connus, il vaudrait mieux, pendant les trois prochaines années au moins, se concentrer sur l’approche Faster CPython, qui apporte des améliorations prévisibles, tandis que les partisans d’un Python concurrent devraient aller au-delà du simple prototype et analyser quels problèmes peuvent survenir, comment les détecter et ce qu’il est possible de faire. Il serait plus juste que des personnes ayant de l’expérience dans la preuve de garanties de concurrence examinent le sujet, et que les questions soient soumises au comité de pilotage une fois que les inconnues auront au moins été identifiées. L’open source n’a pas souvent eu à prendre des décisions à l’échelle de la gestion de programme ; il y a eu beaucoup de décisions relativement simples, orientant le marché, comme avec Apache, Eclipse ou Linux, mais ici il existe de véritables inconnues techniques. En même temps, j’ai le sentiment qu’il faut aussi traiter l’ABI entre langages. Le gros problème est de s’aligner sur le modèle d’exécution attendu par C ; l’interface de fonctions et de mémoire étrangères de Java est en incubation depuis des années, et Swift s’améliore aussi pour encapsuler C et C++, mais la FFI est notoirement difficile, et probablement inutilement difficile

  • Si le coût reporté sur les développeurs Python peut se mesurer en points de PIB, les bénéfices aussi

• À titre personnel, je pense que supprimer le GIL est une erreur. Peu d’applications en tireront un fort bénéfice, et la plupart subiront une pénalité de performance
  Ce travail va absorber des années d’attention et d’efforts, qui auraient pu être utilisés plus intelligemment. Python semble entretenir une forme d’angoisse ou de complexe d’infériorité à propos du GIL. À mon avis, il vaudrait mieux assumer pleinement un modèle monothread, comme JavaScript. Certaines applications resteraient difficiles ou impossibles, mais je ne pense pas que Python soit un bon choix pour les applications qui exigent de très hautes performances ou une très grande scalabilité. Être relativement spécialisé et ne pas couvrir tous les cas d’usage n’est pas forcément une mauvaise chose

  • Il est trop tard pour limiter aussi artificiellement le périmètre de Python. Il est déjà très utilisé en science des données et en machine learning
    Les gens ont besoin de performances pour ce qu’ils font déjà aujourd’hui avec Python. On ne peut pas revenir à l’époque où ce n’était pas le cas. C’est désormais l’un des cas d’usage les plus courants de Python, et des gens y ont bâti leur carrière
  • La PEP détaille la motivation et les limites du modèle monothread : https://peps.python.org/pep-0703/#motivation
    Les gens essaient déjà de faire du parallélisme avec Python. Les forcer à utiliser un autre langage n’aide pas beaucoup
  • À une époque où les multiprocesseurs sont courants depuis plus de dix ans, il est temps de l’accepter. D’autant plus si, grâce à d’excellents ingénieurs d’interpréteurs, le coût est nul ou faible ; personnellement, je m’en réjouis
  • Cela aurait été bien d’avoir la prise en charge d’Unicode dès le départ, mais ce qui est fait est fait. Je suis content que ce chantier soit pris en main
  • J’ai toujours pensé qu’un JIT robuste, compatible avec Cython et avec les grands projets d’extensions C comme numpy et scipy, serait un effort plus précieux
    Une grande partie des traitements intensifs en données peut être facilement exécutée en processus parallèles depuis Python, donc je ne suis pas sûr que la suppression du GIL apporte un si grand bénéfice

• Les performances en monothread sont beaucoup plus difficiles à améliorer simplement en y mettant plus d’argent, elles devraient donc être prioritaires
  Pour les performances multithread, on peut ajouter un cœur de plus afin de compenser le surcoût de la parallélisation basée sur des processus. Je pense que la dichotomie GIL contre no-GIL est elle-même erronée. Le plus gros problème de multiprocessing, c’est l’impossibilité de partager la mémoire. Il suffirait donc d’ajouter des processus virtuels dotés d’un mécanisme explicite de partage mémoire. Ainsi, les objets resteraient dans un seul thread, ce qui permettrait de conserver des optimisations monothread comme le comptage de références sans barrière.

  • L’erreur ici est de supposer qu’il s’agit d’un compromis nécessaire
    On peut obtenir de bonnes performances monothread sans GIL. Rust a la notion d’abstractions sans coût et gère aussi très bien les threads. Java s’en sort aussi bien sur les tâches monothread. Il y a beaucoup d’autres langages, ce n’est pas de la science-fiction. Les verrous peuvent disparaître grâce à l’optimisation, on peut aussi choisir du code entièrement sans verrou, et la concurrence fine ou structurée est possible. Ce qui est thread-safe relève fondamentalement du contrat d’API. Le verrouillage optimiste existe aussi. Il n’y a pas de bonne raison pour que Python ne puisse pas faire quelque chose de similaire, mais il faut d’abord supprimer le GIL. La baisse de performances de Python sans GIL ressemble en grande partie à de la dette technique non résolue, qui pourra être corrigée avec le temps. Ajouter beaucoup de verrous est une solution de fortune et ralentit les choses, mais la vraie solution consistera probablement à repenser le fonctionnement interne ou à disposer de contrats d’API documentant ce qui est thread-safe ou non. Un runtime et un compilateur Python plus rapides pourraient aussi permettre de réimplémenter en Python beaucoup de choses qui dépendent aujourd’hui de bibliothèques natives. L’interaction avec le code natif est précisément l’un des endroits où des verrous sont souvent nécessaires, et si cette approche ne change pas, le problème persistera. L’enjeu de la suppression du GIL est de trouver et corriger systématiquement ces points, et cela s’améliorera avec le temps.
  • D’accord. Si l’on a besoin de concurrence aujourd’hui, on est probablement déjà passé à multiprocessing, donc le multithreading sans GIL a peu d’utilité
    Le seul vrai problème de Python/multiprocessing, c’est qu’il arrive qu’on ait besoin d’un état mutable partagé plutôt que de files. Aujourd’hui, placer des objets Python en mémoire partagée est complexe, limité et inefficace. C’est cela qu’il faut corriger, et Python a besoin d’un meilleur support pour placer des instances natives en mémoire partagée.

• À la question « quelle dégradation des performances du code monothread serait acceptable », Shannon a estimé environ 15 à 20 %, mais la question est globalement restée sans réponse
  Donc certaines personnes du projet qui vise à « rendre CPython plus rapide » considèrent acceptable de ralentir du jour au lendemain la majeure partie du code Python existant de 15 à 20 % ? À mon avis, la limite se situe plutôt autour de 5 %. Et encore, seulement si la suppression du GIL aide d’autres optimisations futures. Or il semble au contraire que ce changement complique et retarde d’autres optimisations. Par ailleurs, en 2020, Shannon avait proposé à titre personnel une levée de fonds pour rendre CPython 5 fois plus rapide ; désormais, une équipe entière, bien mieux soutenue par des entreprises, travaille à accélérer CPython, mais l’objectif paraît beaucoup plus modeste.

  • Pour environ 99 % du code Python actuel, les hautes performances du pur Python ne sont peut-être pas la préoccupation principale
    Quand les performances comptent vraiment, obtenir un facteur 20 sans devoir réécrire dans un autre langage a beaucoup de valeur.
  • Une partie des améliorations récentes de performance vient du camp no-GIL, qui voulait montrer qu’il reste une grande marge de progression même en supprimant le GIL
    Si les autres optimisations ne sont pas stoppées mais prennent simplement un peu plus de temps, cela peut être acceptable.
  • Je pense que le projet Faster CPython a été survendu
    Si l’on compare du vrai code comportant des opérations numériques et sur chaînes, sans accès réseau ni disque, la bêta de 3.12 ne prend qu’environ 20 à 25 % de temps en moins que 3.8. C’est du niveau de 2.7. On dirait que de vieux acteurs centraux cherchent désespérément des fonctionnalités à mettre en bullet points pour les sponsors d’entreprise à la prochaine release. Ils utilisent donc le travail de Sam Gross, mais avec le temps, le mérite leur reviendra probablement peu à peu.

• Une excellente synthèse, comme on peut s’y attendre de LWN
  J’aime la communauté Python. C’est un exemple de premier plan du logiciel open source, et elle montre ce que peuvent accomplir la transparence et une bonne gouvernance. Le temps d’ingénierie investi par Meta, Microsoft et d’autres est appréciable, mais il reste extrêmement modeste par rapport à la valeur que l’ensemble de l’industrie tech et des domaines plus larges, dont la data science, tirent de Python et des logiciels open source.

  • On peut changer cela au sein de sa propre organisation
    Il y a 8 ans, chez JPMorgan, j’ai convaincu l’équipe de direction technique de sponsoriser PyCon UK, d’y tenir un stand de recrutement et de financer la participation de développeurs juniors de JPMorgan venus de tout le Royaume-Uni. J’ai quitté JPM il y a 5 ans, mais l’entreprise est toujours sponsor principal de PyCon UK. Au regard des immenses bénéfices tirés de Python et de l’écosystème open source, c’était un coût totalement négligeable.
  • Je pense qu’ils font seulement semblant d’être transparents, alors que les vraies décisions se prennent toutes en coulisses
    Les listes de diffusion sont censurées, et le cercle intérieur ne peut pas être critiqué. Les vrais contributeurs sont exploités par des personnes qui appartiennent aux bonnes entreprises, font peu de choses, mais occupent des postes d’autorité administrative. Les articles de LWN sont très favorables et mentionnent toujours comme il faut les noms des décideurs, il ne faut donc pas se laisser abuser. Cela ressemble plutôt à une couverture sélective.

• La manière dont Sam Gross a fait avancer les choses est assez impressionnante. Après avoir reçu du comité de pilotage une réaction positive mais sans engagement ferme, il aurait pu rester assis à attendre que les choses progressent ; le fait qu’il ait contesté et mis la pression mérite beaucoup de respect.

• Très intéressant. Quand Sam Gross a dit « nous n’avons pas besoin d’un yes/no tout de suite, mais nous devons savoir à quoi ressemblerait une acceptation, et cette question est restée en suspens beaucoup trop longtemps », c’était une initiative très audacieuse : https://github.com/python/steering-council/issues/188#issuec...
  Cette interaction aurait pu prendre plusieurs directions, mais il me semble que c’était exactement le coup de pouce dont le comité de pilotage avait besoin. La route vers un Python sans GIL reste longue et sinueuse, et demandera probablement un nombre d’années-ingénieur à deux chiffres, mais au moins il semble désormais y avoir une vraie voie. La partie la plus difficile sera de garantir l’exactitude des bases de code existantes. Dire qu’on ne veut pas revivre le passage de Python 2 à 3 est une chose ; éviter réellement une mise à niveau par peur des bugs, même si l’on affirme qu’il n’y aura pas de changements cassants, en est une tout autre. Même si l’on ne garde GIL/no-GIL que comme option à la compilation, le coût de maintenance augmentera clairement. Malgré tout, je pense qu’à long terme cet effort en vaudra la peine. Le GIL est une sorte de paratonnerre pour les critiques de Python, comme on le voit dans n’importe quel fil HN sur Python et le parallélisme. C’est sans doute parce que les gens peuvent le désigner directement comme « la raison pour laquelle Python ne peut pas être plus rapide », sans comprendre des décennies de contexte. En ce sens, c’est presque le boss final de la clôture de Chesterton.

  • Je ne serais pas aussi optimiste. La décision du comité de pilotage paraît indécise.
    Même avec les nouvelles directives, il reste possible que l’effort pluriannuel pour supprimer le GIL soit finalement rejeté.