Au revoir GIL

Aug 04, 2023

La réponse évidente est : tout dépend de ce que vous entendez par « rapide ». Cela améliorera certaines choses et aggravera inévitablement certaines choses. Mais après de longues souffrances, le sort du GIL est scellé.

Tout d’abord un mot sur ce qu’est le Global Interpreter Lock (GIL). C'est un verrou qui empêche l'interpréteur Python d'être exécuté par plusieurs threads à la fois. Cela signifie que si vous écrivez un programme multithread en Python, un seul des threads peut exécuter Python à un moment donné. À l'époque des processeurs monocœur, ce n'était pas un gros problème, mais aujourd'hui, avec des processeurs multicœurs capables d'exécuter plus d'un thread en même temps, ce n'est probablement toujours pas un gros problème...

Ce n'est pas une opinion populaire, mais le fait est que la grande majorité des programmes Python ne seront pas accélérés en supprimant le GIL. Vous pouvez affirmer que ce n’est pas le programme courant qui est la cible de ce changement, mais les grandes extensions et applications Python comme Numpy. Si Numpy pouvait fonctionner simultanément, de nombreux programmes de calcul fonctionneraient plus rapidement et il serait intéressant de se débarrasser du GIL. L’erreur est que la plupart des extensions qui doivent se débarrasser du GIL ont déjà trouvé un moyen de le contourner. Rien n'empêche une extension C de libérer le GIL et de devenir multithread et c'est ce que Numpy a fait.

Si vous vous en tenez au Python pur, alors le GIL a un certain impact sur vous – mais seulement si vous souhaitez écrire un programme en utilisant des threads Python. Si vous écrivez un programme pour calculer Pi, par exemple, l'utilisation de deux threads pour l'exécuter n'augmentera pas du tout la vitesse. Toutefois, si vous divisez le programme en deux processus, il s'exécutera deux fois plus vite. Les processus Python signifient que vous contournez déjà le GIL au prix d'un peu plus de mémoire pour résoudre le problème. Ensuite, il y a l'asyncio à considérer. L'idée générale d'asyncio est que pour les E/S, vous n'avez pas vraiment besoin d'une véritable concurrence et un seul thread fera l'affaire.

En mettant tout cela ensemble, il est difficile de voir à qui profite l’abandon du GIL, mais j’admets que certaines personnes le feront, mais pas beaucoup. Et avant d’argumenter, notez qu’il n’existe pas de véritables statistiques sur la question.

L’avantage de conserver le GIL est qu’il permet un portage facile des programmes C vers Python en tant qu’extensions C. On prétend souvent que c'est l'une des principales raisons pour lesquelles Python est devenu populaire - même si je ne suis pas du tout sûr non plus de cette légende urbaine. Au fil du temps, les extensions C ont trouvé leur propre manière de gérer le GIL ou l'ont simplement accepté.

Mais pour un ensemble étrange de raisons, principalement parce que cela s'inscrit dans le mouvement "Make Python Faster", les Pythonistas semblent déterminés à supprimer le GIL de CPython - l'implémentation de référence de Python. Notez que le GIL ne fait pas partie du langage Python, seulement son implémentation, et qu'il existe d'autres implémentations qui ne l'utilisent pas.

Après une réflexion approfondie, un vote des principaux développeurs a eu lieu et les résultats ont été concluants pour la GILectomie :

Vous pourriez penser qu’il s’agit d’un petit sondage, mais rappelez-vous que ce sont les personnes dont vous pouvez vous attendre à avoir des opinions valables sur le sujet. Je n'en suis pas si sûr - les développeurs principaux sont enthousiasmés par la mise en œuvre mais pas tellement par son utilisation. C'est donc un peu comme demander à un spécialiste du matériel si la machine a besoin d'une mise à niveau - la réponse est généralement oui, même si le logiciel fonctionne très bien.

Après le résultat, le Conseil directeur a émis ce qui suit :

Merci à tous d'avoir répondu au sondage sur la proposition sans GIL. Il est clair que le sentiment général est positif, à la fois pour l'idée générale et pour le PEP 703 en particulier. Le Conseil directeur est également largement positif sur ces deux points. Nous avons l'intention d'accepter le PEP 703, même si nous travaillons toujours sur les détails de l'acceptation.

Ils estiment que les travaux prendront plus de cinq ans et qu'il n'y a donc pas lieu de paniquer pour l'instant. Et ils déclarent qu'ils s'engagent sur une version unique de Python avec la rétrocompatibilité, apaisant ainsi l'accusation selon laquelle ce sera Python 4 avec tous les terribles bouleversements que cela pourrait générer.