[讨论]如何看待Python将移除GIL
本帖最后由 hrh123 于 2023-8-10 14:56 编辑近日,Python指导委员会打算批准提案PEP 703,内容大概为在Cpython中使GIL成为可选项(也就是打算移除GIL),我想和各位开发者讨论讨论各自的看法
我先说我的观点:
官方人员说完全改变大概需要5年,我觉得不太现实.有人说,很多C扩展有其他语言的绑定,所以是线程安全的,再加上即使有GIL,Python也支持多线程,因此这些库都是可重入安全的,而对于那些可重入安全但不线程安全的库来说,只需要加一个类似于GIL的功能就行了,因此使这些库在No-GIL时运行是比较轻松的(最多牺牲点并行性).但我的观点是:这项工作需要所有的Python开发者都去修复他们的C共享库以及Python库,想在5年内完成显然过于乐观.为什么这么说?比如,按照有人说的对于可重入安全但不线程安全的库,只需要加入一个全局锁,但忽略了可能会带来的死锁问题,更何况加上一个全局锁可能会破坏C库原本设计的逻辑或语义,因为如果C库本身就不支持多线程访问,那么强行加上一个锁可能会导致一些意想不到的后果.就算它5年吧,想想,有5年要存在GIL和NOGIL 2个版本的Python,官方还说不想重演Python2-3的悲剧.再者,没有GIL意味着Python运行时本身也必须是线程安全的,这就需要对Python对象.内存管理,异常处理,信号处理等方面进行大量的修改和优化.而且,对于那些从C端回调到Python运行时的库,还要考虑如何保证回调函数也是线程安全的.其次,即使说完成了,又有多少人会注意到?再说所有库都从没有过多进程用例,我敢说,bug一定会出现,也必将出现很多开发者的退出,尤其是一些大型的库.因此这个改变就是打着性能的旗号带来了更多数据安全和死锁的问题.再说必要性,移除GIL真的能提高Python的速度吗?当我们有asnycio和multiprocessing这样的库时,谁还需要no-GIL?有人说asnycio本身是单线程单核,GIL也是单核的,multiprocessing虽是多核,但每个进程性能会更差,还会增加内存消耗,而No-GIL相对于它们肯定更快.我的意见是:尽管如此,也尽管官方采用了计数线程安全的方式并声称不会降低单线程程序的性能,但是显然地,一个No-GIL Python会牺牲单线程的速度来换取多线程的效率,我之前说了一些库可能需要自己实现一个类似功能,如果每个库都执行自己DIY的GIL而不是原本全局的GIL,程序会变得更慢,也会带来更多的报错,或许一些需要用多线程的人开心了,但对于大部分人来说,这是浪费了计算资源,是不划算的,也就是说这个改变不能让所有人都受益,即使要解决性能问题,我认为的最佳解决方案应该是实现无并发原语开销的单线程执行.
欢迎各位坛友一起讨论交流,说出你的想法! {:301_983:}观点全打在一行里面了么。。。 容易看花眼。。。 我来帮楼主排一下版:
官方人员说完全改变大概需要5年, 我觉得不太现实.
有人说, 很多C扩展有其他语言的绑定, 所以是线程安全的, 再加上即使有GIL, Python也支持多线程, 因此这些库都是可重入安全的, 而对于那些可重入安全但不线程安全的库来说, 只需要加一个类似于GIL的功能就行了, 因此使这些库在No-GIL时运行是比较轻松的(最多牺牲点并行性).
但我的观点是: 这项工作需要所有的Python开发者都去修复他们的C共享库以及Python库, 想在5年内完成显然过于乐观.
为什么这么说? 比如, 按照有人说的对于可重入安全但不线程安全的库, 只需要加入一个全局锁, 但忽略了可能会带来的死锁问题, 更何况加上一个全局锁可能会破坏C库原本设计的逻辑或语义, 因为如果C库本身就不支持多线程访问, 那么强行加上一个锁可能会导致一些意想不到的后果.
就算它5年吧, 想想, 有5年要存在GIL和NOGIL 2个版本的Python, 官方还说不想重演Python2-3的悲剧. 再者, 没有GIL意味着Python运行时本身也必须是线程安全的, 这就需要对Python对象. 内存管理, 异常处理, 信号处理等方面进行大量的修改和优化. 而且, 对于那些从C端回调到Python运行时的库, 还要考虑如何保证回调函数也是线程安全的.
其次, 即使说完成了, 又有多少人会注意到?再说所有库都从没有过多进程用例, 我敢说, bug一定会出现, 也必将出现很多开发者的退出, 尤其是一些大型的库. 因此这个改变就是打着性能的旗号带来了更多数据安全和死锁的问题.
再说必要性, 移除GIL真的能提高Python的速度吗? 当我们有asnycio和multiprocessing这样的库时, 谁还需要no-GIL? 有人说asnycio本身是单线程单核, GIL也是单核的, multiprocessing虽是多核, 但每个进程性能会更差, 还会增加内存消耗, 而No-GIL相对于它们肯定更快.
我的意见是: 尽管如此, 也尽管官方采用了计数线程安全的方式并声称不会降低单线程程序的性能, 但是显然地, 一个No-GIL Python会牺牲单线程的速度来换取多线程的效率, 我之前说了一些库可能需要自己实现一个类似功能, 如果每个库都执行自己DIY的GIL而不是原本全局的GIL, 程序会变得更慢, 也会带来更多的报错, 或许一些需要用多线程的人开心了, 但对于大部分人来说, 这是浪费了计算资源, 是不划算的, 也就是说这个改变不能让所有人都受益, 即使要解决性能问题, 我认为的最佳解决方案应该是实现无并发原语开销的单线程执行. 说一言道一万，还不如搞好anconda。。。把第三方库尽可能纳入，
把纳入开源库全都升级到最新版本且解决互不兼容的问题 pjy612 发表于 2023-8-10 17:34
观点全打在一行里面了么。。。 容易看花眼。。。
抱歉,码字的时候没考虑这些{:301_1007:} aoyu321 发表于 2023-8-10 17:41
我来帮楼主排一下版:
官方人员说完全改变大概需要5年, 我觉得不太现实.
感谢帮忙哈{:301_1003:} sai609 发表于 2023-8-10 17:44
说一言道一万，还不如搞好anconda。。。把第三方库尽可能纳入，
把纳入开源库全都升级到最新版本且解决互 ...
这个听起来比移除GIL还难实现,兼容性咋办啊.{:301_1008:}
我希望他们能做出一些能让所有人受益的事,比如之前把Unicode的问题解决了.现在的情况是只有极少的用例能从中获利,既然已经到这个局面,只能想开点,祈祷能够做好反向兼容吧 本帖最后由 hrh123 于 2023-8-10 19:07 编辑
wzzpojie 发表于 2023-8-10 18:46
随着计算机性能提升，感觉多CPU、多核是现代编程必须要考虑的，移除GIL无可厚非，但5年是不是有点太久了， ...
也没办法,只能社区一起努力把移除前的艰苦工作做好{:301_1005:} python4 ,, 又不是第一次 低情商：nogil
高情商：python4
页:
[1]
2