L’expérimentation de CPython free-threaded est prête

• CPython free-threaded constitue un changement majeur permettant d’exécuter plusieurs threads en parallèle au sein du même interpréteur
• Fourni comme fonctionnalité expérimentale dans CPython 3.13
• Grâce à la PEP 703, il devient possible de l’exécuter avec le GIL désactivé
• C’est important pour améliorer les performances, en particulier les performances multithread
• Cela permet d’utiliser efficacement plusieurs cœurs CPU

Impressionnant, mais quels problèmes ?

• L’implémentation du free-threading dans CPython lui-même représente un effort considérable
• Deux problèmes majeurs : la sûreté des threads et la compatibilité ABI
  • Sûreté des threads : le code Python pur fonctionne sans modification, mais ce n’est pas forcément le cas du code écrit dans d’autres langages ou de celui qui utilise l’API C de CPython
  • Compatibilité ABI : l’interpréteur free-threaded a une ABI différente, donc chaque package avec des modules d’extension doit construire une roue supplémentaire
• Les problèmes de sûreté des threads sont difficiles à comprendre, à améliorer et à tester
• Exemples : échecs intermittents observés dans numpy#26690, pywavelets#758, etc.

Plans à venir et travail de l’équipe

• Il faudra plusieurs années avant que CPython free-threaded ne devienne la valeur par défaut
• L’espoir est que, dans Python 3.13, de nombreux projets travaillent sur la compatibilité et publient des roues cp313t sur PyPI
• L’équipe a commencé il y a plusieurs mois en partant de la base de la stack PyData
• Une approche similaire est utilisée pour chaque package :
  1. Ajouter une première tâche CI
  2. Corriger les problèmes de sûreté des threads et d’état partagé/global
  3. Ajouter la prise en charge free-threaded aux tâches CI de build des roues
  4. Effectuer des stress tests en local et surveiller les tâches CI
  5. Marquer les modules d’extension pour qu’ils puissent s’exécuter sans GIL
  6. Passer au package suivant

Récapitulatif de GN⁺

• CPython free-threaded est un changement important qui peut fortement améliorer les performances multithread
• La résolution des problèmes de sûreté des threads et de compatibilité ABI constitue le principal défi
• L’espoir est que, dans Python 3.13, de nombreux projets puissent travailler sur la compatibilité et expérimenter
• Des packages majeurs comme PyTorch, ainsi que de nombreux petits packages, devront adopter ce changement
• Parmi les projets liés figurent PyO3 et PyTorch

[GN⁺]

Avis Hacker News

• La suppression du GIL de Python crée pour de nombreuses organisations et de nombreux projets une opportunité d’améliorer fortement les performances avec très peu d’efforts supplémentaires

  • Si les anciennes bibliothèques ne s’adaptent pas à temps à ce changement, de nouveaux projets pourraient gagner des parts de marché
  • Cela permet d’éviter la complexité et les bugs du multiprocessing et d’utiliser des threads simples pour exploiter tous les cœurs des grosses machines

• Partage d’une expérience d’installation et d’utilisation d’un Python sans GIL sur macOS

  • Un court script a été écrit pour expliquer le processus d’installation et les différences
  • Lien

• Un utilisateur qui apprécie la simplicité d’écriture et la logique de Python espère que l’approche sans GIL restera proche de la manière habituelle d’écrire du Python

  • Il mentionne ne pas avoir approfondi le multithreading, qu’il trouve difficile

• Résumé de l’avancement de Python 3

  • [x] Async
  • [x] Typage statique optionnel
  • [x] Threading
  • [ ] JIT
  • [ ] Gestion efficace des dépendances

• Souvenir du moment où le traitement parallèle est devenu indispensable, vers 2007

  • Il est mentionné que Rust prend l’avantage en vitesse et en traitement parallèle

• Explication de la manière dont, dans le PEP703, l’opération append sur les listes conserve sa sûreté vis-à-vis des threads après la suppression du GIL

  • Un verrou par liste a été ajouté
  • Il est mentionné qu’une simple opération d’incrémentation d’entier est actuellement thread-safe grâce au GIL

• Attente de voir comment la suppression du GIL changera la nature de l’entraînement et de l’inférence en ML

  • Cela pourrait réduire la complexité liée au passage de mémoire et à la coordination entre processus
  • L’espoir est que des bibliothèques comme PyTorch puissent être optimisées

• Inquiétude face au risque que des programmeurs n’ayant jamais réellement pratiqué le multithreading introduisent de nouveaux bugs subtils

• Question sur le degré de gravité de la baisse des performances en single-thread

  • Aucun benchmark n’a été trouvé, seulement des assurances générales

• Curiosité sur la manière dont cela fonctionnera avec l’async

  • Il existe une barrière naturelle entre le code I/O-bound et CPU-bound
  • Le souhait est de voir un modèle plus flexible
  • Question sur la possibilité d’un JIT lorsqu’on fait un "gather" sur des coroutines CPU-bound
  • L’idée d’un modèle de programmation flexible permettant de basculer rapidement avec une interface similaire semble intéressante