Qu'est-ce que le GIL de python ? Introduction à GIL en python

Le contenu de cet article porte sur ce qu'est le GIL de python ? L'introduction de GIL en python a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer, j'espère que cela vous sera utile.

Qu'est-ce que GIL

GIL (Global Interpreter Lock) n'est pas une fonctionnalité de python, mais un concept introduit par l'interpréteur Python Cpython. L'interpréteur de python n'est pas seulement Cpython. Si l'interpréteur est Jpython, alors python n'a pas de GIL.

Jetons un coup d'œil à l'explication officielle :

Dans CPython, le verrou global de l'interpréteur, ou GIL, est un mutex qui empêche plusieurs threads natifs d'exécuter des bytecodes Python Ce verrou est nécessaire principalement parce que La gestion de la mémoire de CPython n'est pas thread-safe. (Cependant, depuis que le GIL existe, d'autres fonctionnalités dépendent des garanties qu'il applique.)

Un Mutex (verrouillage mutex) qui empêche plusieurs threads d'exécuter du code machine simultanément La raison est la suivante : la gestion de la mémoire de Cpython n'est pas thread-safe

Pourquoi y a-t-il GIL

Parce qu'en raison de problèmes physiques. limitations, la concurrence entre les fabricants de processeurs en termes de fréquence de cœur a été remplacée par le multicœur. Afin d'utiliser plus efficacement les performances des processeurs multicœurs, la programmation multithread est apparue, ce qui entraîne la difficulté de cohérence des données et de synchronisation des statuts entre les threads. Même le cache à l'intérieur du CPU ne fait pas exception. Afin de résoudre efficacement le problème de synchronisation des données entre plusieurs caches, différents fabricants ont déployé beaucoup d'efforts, ce qui entraîne inévitablement une certaine perte de performances.

Bien sûr, Python ne peut pas s'échapper. Afin de profiter de plusieurs cœurs, Python a commencé à prendre en charge le multi-threading. Le moyen le plus simple de résoudre l'intégrité des données et la synchronisation des statuts entre plusieurs threads est naturellement de verrouiller. Il y a donc le super gros verrou de GIL, et lorsque de plus en plus de développeurs de base de code acceptent ce paramètre, ils commencent à s'appuyer fortement sur cette fonctionnalité (c'est-à-dire que les objets internes Python par défaut sont thread-safe, et il n'est pas nécessaire de le faire). La mise en œuvre prend en compte les verrous de mémoire supplémentaires et les opérations de synchronisation).

Lentement, cette méthode de mise en œuvre s'est révélée douloureuse et inefficace. Mais lorsque tout le monde a essayé de diviser et de supprimer le GIL, ils ont constaté qu'un grand nombre de développeurs de codes de bibliothèque s'appuyaient fortement sur le GIL et qu'il était très difficile de le supprimer. Est-ce difficile ? Pour donner une analogie, un "petit projet" comme MySQL a passé près de 5 ans dans plusieurs versions majeures de 5.5 à 5.6 à 5.7 afin de diviser le gros verrou de Buffer Pool Mutex en plusieurs petits verrous, et c'est toujours Continue. MySQL, un produit bénéficiant du support de l'entreprise et d'une équipe de développement fixe derrière lui, traverse une période si difficile, sans parler d'une équipe hautement communautaire de développeurs principaux et de contributeurs de code comme Python ?

Donc pour parler simplement, l'existence de GIL est plutôt pour des raisons historiques. Si c’était à refaire, nous serions toujours confrontés au problème du multi-threading, mais au moins ce serait plus élégant que l’approche GIL actuelle.

L'impact de GIL

D'après l'introduction ci-dessus et la définition officielle, GIL est sans aucun doute un verrou exclusif mondial. Il ne fait aucun doute que l'existence de verrous globaux aura un grand impact sur l'efficacité du multi-threading. C'est presque comme si Python était un programme monothread. Les lecteurs diront alors que tant que le verrouillage global sera libéré, l'efficacité ne sera pas mauvaise. Tant que le GIL peut être libéré lors de l'exécution d'opérations d'E/S chronophages, l'efficacité opérationnelle peut encore être améliorée. En d'autres termes, peu importe à quel point c'est grave, ce ne sera pas pire que l'efficacité d'un seul thread. C'est vrai en théorie, mais en pratique ? Python est pire que vous ne le pensez.

Comparons l'efficacité de Python en multi-threading et en mono-threading. La méthode de test est très simple, une fonction de compteur qui boucle 100 millions de fois. L’un est exécuté deux fois via un seul thread et l’autre est exécuté via plusieurs threads. Comparez enfin le temps d’exécution total. L'environnement de test est un Mac pro dual-core. Remarque : Afin de réduire l'impact de la perte de performances de la bibliothèque de threads elle-même sur les résultats des tests, le code monothread utilise également ici des threads. Exécutez-le simplement deux fois de manière séquentielle pour simuler un seul thread.

Un seul thread exécuté séquentiellement (single_thread.py)

#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
t.join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()

Deux threads simultanés exécutés simultanément (multi_thread.py)

#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
thread_array[tid] = t
for i in range(2):
thread_array[i].join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()

Vous pouvez voir que python est en fait 45 % plus lent qu'un monothread en mode multithread. Selon l'analyse précédente, même avec l'existence du verrou global GIL, le multithreading sérialisé devrait avoir la même efficacité que le monothreading. Alors comment a-t-il pu y avoir un si mauvais résultat ?

Analysons les raisons de cela à travers le principe de mise en œuvre du GIL.

Défauts de la conception actuelle du GIL

Méthode de planification basée sur le nombre de pcodes

Selon la communauté Python, la planification des threads du système d'exploitation lui-même est déjà très mature et stable, et il n'est pas nécessaire de le faire vous-même. Créez un ensemble. Par conséquent, un thread Python est un pthread en langage C et est planifié via l'algorithme de planification du système d'exploitation (par exemple, Linux est CFS). Afin de permettre à chaque thread d'utiliser le temps CPU de manière égale, Python calculera le nombre de microcodes actuellement exécutés et forcera la libération du GIL lorsqu'il atteint un certain seuil. À ce moment-là, la planification des threads du système d'exploitation sera également déclenchée (bien entendu, le fait que le changement de contexte soit réellement effectué est déterminé par le système d'exploitation).

Pseudocode

while True:
acquire GIL
for i in 1000:
do something
release GIL
/* Give Operating System a chance to do thread scheduling */

这种模式在只有一个CPU核心的情况下毫无问题。任何一个线程被唤起时都能成功获得到GIL（因为只有释放了GIL才会引发线程调度）。但当CPU有多个核心的时候，问题就来了。从伪代码可以看到，从release GIL到acquire GIL之间几乎是没有间隙的。所以当其他在其他核心上的线程被唤醒时，大部分情况下主线程已经又再一次获取到GIL了。这个时候被唤醒执行的线程只能白白的浪费CPU时间，看着另一个线程拿着GIL欢快的执行着。然后达到切换时间后进入待调度状态，再被唤醒，再等待，以此往复恶性循环。

PS：当然这种实现方式是原始而丑陋的，Python的每个版本中也在逐渐改进GIL和线程调度之间的互动关系。例如先尝试持有GIL在做线程上下文切换，在IO等待时释放GIL等尝试。但是无法改变的是GIL的存在使得操作系统线程调度的这个本来就昂贵的操作变得更奢侈了。

为了直观的理解GIL对于多线程带来的性能影响，这里直接借用的一张测试结果图（见下图）。图中表示的是两个线程在双核CPU上得执行情况。两个线程均为CPU密集型运算线程。绿色部分表示该线程在运行，且在执行有用的计算，红色部分为线程被调度唤醒，但是无法获取GIL导致无法进行有效运算等待的时间。

由图可见，GIL的存在导致多线程无法很好的立即多核CPU的并发处理能力。

那么Python的IO密集型线程能否从多线程中受益呢？我们来看下面这张测试结果。颜色代表的含义和上图一致。白色部分表示IO线程处于等待。可见，当IO线程收到数据包引起终端切换后，仍然由于一个CPU密集型线程的存在，导致无法获取GIL锁，从而进行无尽的循环等待。

简单的总结下就是：Python的多线程在多核CPU上，只对于IO密集型计算产生正面效果；而当有至少有一个CPU密集型线程存在，那么多线程效率会由于GIL而大幅下降。

如何避免受到GIL的影响

用multiprocessing替代Thread

multiprocessing库的出现很大程度上是为了弥补thread库因为GIL而低效的缺陷。它完整的复制了一套thread所提供的接口方便迁移。唯一的不同就是它使用了多进程而不是多线程。每个进程有自己的独立的GIL，因此也不会出现进程之间的GIL争抢。

当然multiprocessing也不是万能良药。它的引入会增加程序实现时线程间数据通讯和同步的困难。就拿计数器来举例子，如果我们要多个线程累加同一个变量，对于thread来说，申明一个global变量，用thread.Lock的context包裹住三行就搞定了。而multiprocessing由于进程之间无法看到对方的数据，只能通过在主线程申明一个Queue，put再get或者用share memory的方法。这个额外的实现成本使得本来就非常痛苦的多线程程序编码，变得更加痛苦了。

用其他解析器

之前也提到了既然GIL只是CPython的产物，那么其他解析器是不是更好呢？没错，像JPython和IronPython这样的解析器由于实现语言的特性，他们不需要GIL的帮助。然而由于用了Java/C#用于解析器实现，他们也失去了利用社区众多C语言模块有用特性的机会。所以这些解析器也因此一直都比较小众。毕竟功能和性能大家在初期都会选择前者，Done is better than perfect。

总结

Python GIL其实是功能和性能之间权衡后的产物，它尤其存在的合理性，也有较难改变的客观因素。从本分的分析中，我们可以做以下一些简单的总结：

• 因为GIL的存在，只有IO Bound场景下得多线程会得到较好的性能

• 如果对并行计算性能较高的程序可以考虑把核心部分也成C模块，或者索性用其他语言实现

• GIL在较长一段时间内将会继续存在，但是会不断对其进行改进

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!