gh-116167 : autoriser la désactivation du GIL

 (github.com/python)
1 points par GN⁺ 2024-03-12 | 1 commentaires | Partager sur WhatsApp
  • La PR CPython #116338 a fusionné dans python:main une modification permettant de désactiver le GIL dans une build free-threaded avec PYTHON_GIL=0 ou -X gil=0
  • Pour conserver la possibilité de réactiver le GIL à l’exécution, les structures de données liées au GIL sont initialisées comme d’habitude, et la désactivation est gérée en définissant un flag au démarrage afin que take_gil() et drop_gil() retournent immédiatement
  • Lors des premières vérifications, avec PYTHON_GIL=0, certains tests et petits programmes n’utilisant pas de threads ont fonctionné normalement, et des programmes multithread très basiques ont parfois marché, mais l’ensemble de la suite de tests a rapidement crashé dans test_asyncio
  • Pendant la revue, des tests pour PYTHON_GIL, la documentation, l’option -X gil et sa prise en compte dans sys.flags ont été ajoutés, et le traitement de la configuration a aussi été corrigé pour que PYTHON_GIL=1 force bien l’activation du GIL
  • Les travaux de suivi ont été séparés entre la réactivation du GIL lors du chargement d’extensions incompatibles et la désactivation du GIL par défaut, et cette modification ajoute une surface de contrôle du GIL dans la build free-threaded de Python 3.13

Modification fusionnée

  • La PR CPython #116338 traite du changement gh-116167: Allow disabling the GIL with PYTHON_GIL=0 or -X gil=0
  • colesbury l’a fusionnée dans python:main le 11 mars 2024
  • L’ampleur du changement est indiquée comme 12 fichiers, 163 lignes ajoutées et 1 ligne supprimée
  • La fonctionnalité visée est une option d’exécution permettant de désactiver le GIL dans une build free-threaded, et non dans une build classique

Mode de désactivation du GIL

  • Dans une build free-threaded, le GIL peut être désactivé avec la configuration suivante
    • PYTHON_GIL=0
    • -X gil=0
  • Afin de pouvoir réactiver le GIL à l’exécution, toutes les structures de données liées au GIL sont initialisées comme d’habitude
  • La désactivation effective repose sur la définition d’un flag au démarrage
    • À cause de ce flag, take_gil() et drop_gil() retournent immédiatement
  • Pendant la revue, un commit corrigeant la configuration de enable_gil lorsque PYTHON_GIL=1 a aussi été ajouté

Tests et limites actuelles

  • Certains tests et petits programmes ont été vérifiés avec PYTHON_GIL=0
    • Les tests et petits programmes n’utilisant pas de threads ont été confirmés comme fonctionnant normalement
    • Des programmes multithread très basiques fonctionnaient parfois
  • L’ensemble de la suite de tests a crashé rapidement, l’emplacement signalé étant test_asyncio
  • Des tests de builders liés à NoGIL ont été planifiés à plusieurs reprises avec la commande !buildbot nogil
    • x86-64 MacOS Intel ASAN NoGIL PR
    • x86-64 MacOS Intel NoGIL PR
    • ARM64 MacOS M1 Refleaks NoGIL PR
    • ARM64 MacOS M1 NoGIL PR
    • AMD64 Ubuntu NoGIL Refleaks PR
    • AMD64 Ubuntu NoGIL PR
    • AMD64 Windows Server 2022 NoGIL PR

Portée ajoutée pendant la revue

  • corona10 a suggéré qu’il serait utile d’ajouter des tests de variable d’environnement dans Lib/test/test_cmd_line.py
  • Les commits suivants ont ensuite été ajoutés
    • Add test for PYTHON_GIL in test_cmd_line
    • Set enable_gil properly when PYTHON_GIL=1
    • Don't add 'enable_gil' to test_embed in normal builds
  • colesbury a estimé qu’il valait mieux documenter la variable d’environnement au moment de son ajout
    • En s’appuyant sur le fait que le flag de configuration --disable-gil était déjà documenté
    • Il a précisé que la documentation devait inclure le fait qu’elle n’est utilisable que dans les builds free-threaded, que 0 force la désactivation du GIL, que 1 force l’activation du GIL, et qu’il s’agit d’une nouveauté de Python 3.13
  • Le commit Document PYTHON_GIL environment variable a ensuite été ajouté

Ajout de l’option -X gil et fusion finale

  • Après une discussion sur Discord, il a été décidé d’ajouter aussi une option -X utilisable avec la variable d’environnement
  • Le titre de la PR a été modifié, passant d’une formulation ne traitant que de PYTHON_GIL=0 à une formulation incluant PYTHON_GIL=0 or -X gil=0
  • Les commits ajoutés comprennent les éléments suivants
    • Add -X gil option, add to sys.flags, modify test to cover env var… and option
    • Fix link to -X gil
    • Fix PYTHON_GIL versionchanged line
    • Clarify test_flags in normal builds
  • ericsnowcurrently, erlend-aasland, corona10 et colesbury ont approuvé la modification
  • Le commit de fusion est 2731913 et, après la fusion, vstinner a réagi en disant que ce changement était « intéressant et très effrayant »

Travaux de suivi

  • Deux tâches ont été séparées dans des issues de suivi
    • #116322 : réactiver le GIL lors du chargement d’extensions incompatibles
    • #116329 : désactiver le GIL par défaut
  • La PR actuelle ne modifie pas la valeur par défaut du GIL ; elle permet aux utilisateurs de contrôler l’état du GIL dans une build free-threaded via une variable d’environnement ou une option -X

À lire aussi

1 commentaires

 
GN⁺ 2024-03-12
Commentaires Hacker News

  • Pour ceux que le travail sur no-GIL intéresse, voici quelques liens supplémentaires : [0], [1]
    [0] Multithreaded Python without the GIL
    https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
    [1] Dépôt Github
    https://github.com/colesbury/nogil

  • J’ai hâte de voir à quel point le Python de base pourra encore être accéléré. La proposition de valeur de Python est aussi mise au défi par la multiplication des outils qui tentent d’atténuer ce problème
    Parmi les outils d’accélération, Mojo, pytorch, triton, numba et taichi me viennent à l’esprit. Il y a tellement de tentatives pour résoudre ce problème que, la dernière fois que j’ai voulu en essayer un, j’ai été submergé par le nombre d’options. J’ai finalement choisi taichi ; c’était assez amusant et facile à utiliser, mais son champ d’application restait quelque peu limité

  • Je me demande pourquoi l’approche de comptage de références biaisé décrite dans https://peps.python.org/pep-0703/ ne conserve une affinité que pour un seul thread, et exige des incréments/décréments atomiques dès qu’un autre thread y accède
    Dans d’autres implémentations, par exemple plusieurs crates Rust qui implémentent le comptage de références biaisé, j’ai vu une approche où l’on n’incrémente atomiquement que lors du déplacement vers un nouveau thread ; ce thread effectue ensuite des incréments/décréments non atomiques jusqu’à revenir à 0, puis effectue un décrément atomique final. Je me demande si c’est parce qu’il s’agit d’un ajout à un système existant, avec un seul PyObject, et qu’on ne peut pas le remplacer pour pointer vers un nouvel objet local au thread

    • CPython pourrait implémenter un transfert de propriété à l’avenir, mais c’est un peu plus délicat
      En Rust, le « move » pour transférer la propriété fait partie du langage, mais en C ou en Python il n’existe pas de concept équivalent, ce qui rend difficile de déterminer quand transférer la propriété et quel thread doit devenir le nouveau propriétaire. On pourrait utiliser des heuristiques. Par exemple, quand un objet est placé dans une queue.SimpleQueue, on pourrait abandonner ou transférer sa propriété, mais même dans ce cas il est difficile de savoir à l’avance quel thread fera le « get » de l’objet dans la file
      Le gain de performance serait probablement faible. Beaucoup d’objets ne sont accédés que depuis un seul thread, certains objets sont accédés depuis plusieurs threads, mais les objets qui sont accédés exclusivement par un thread puis, plus tard, exclusivement par un autre thread sont rares

  • J’ai d’abord lu la nouvelle sur tranched bread, et maintenant ça ? Quelle époque incroyable
    J’avais été un peu déçu quand le projet Unladen Swallow [1] s’est essoufflé. C’est agréable de voir Python revenir sur une trajectoire d’optimisation de fond
    [1] https://en.wikipedia.org/wiki/CPython#Unladen_Swallow

  • J’aimerais qu’on me l’explique comme si j’avais cinq ans
    Je comprends conceptuellement ce qu’est le GIL. Mais quel est l’impact de ce changement ? Faut-il s’attendre à une amélioration générale des performances, tandis que des packages vont désormais casser ?

    • Autrefois, à cause du GIL, on n’écrivait quasiment pas de Python multithread en pratique. Les threads servaient surtout à gérer plusieurs tâches susceptibles d’être bloquées sur des entrées-sorties indépendantes ; c’est évidemment courant et utile, mais cela n’aidait pas les performances du code Python centré sur le CPU
      Même sans tâches CPU très intensives, ce changement peut être utile. De nos jours, beaucoup de code est écrit avec les fonctionnalités natives asyncio de Python. Comme NodeJS, cela fonctionne sur un seul thread en cédant l’exécution via async/await, et un seul thread peut déjà atteindre un débit assez bon, de l’ordre de milliers de requêtes par seconde
      Mais le gros problème est que dès qu’une tâche CPU s’exécute, elle bloque toutes les autres coroutines, ce qui provoque toutes sortes de problèmes obscurs et dégrade le nombre de requêtes par seconde. Par exemple, on peut observer des timeouts d’E/S aléatoires dans une coroutine, alors que la vraie cause est qu’une toute autre coroutine a accaparé le CPU pendant un court instant. Il est aussi très difficile d’observer pourquoi cela se produit. asyncio fournit la fonction asyncio.to_thread() [1], qui aide à déplacer les tâches bloquantes hors du thread principal, mais à cause du GIL elle ne permet pas réellement d’isoler les tâches centrées sur le CPU de façon à ce qu’elles n’interfèrent pas avec les autres coroutines
      [1] https://docs.python.org/3/library/asyncio-task.html#asyncio....
    • Si un package dépend du GIL, le GIL est activé. Les packages ne cassent pas

  • Pour ceux que ça intéresse, GIL signifie Global Interpreter Lock

  • Y a-t-il une bonne ressource qui résume la situation d’ensemble ?

  • J’attends enfin avec impatience les benchmarks des différents outils