去掉GIL不容易

昨天,Juergen Brendel在他的博客中 详细列出GIL的诸多不足。他声称这是我做的一个架构决策,而此决策限制了他的生产率。

我并不期待这个回复或其它任何回复能停止去除GIL的请求,尽管关于此问题已经有一个理由充分的 FAQ条目。但我也不期望它能消失,直到其他人通过努力去除它,并且显示GIL的去除不会减慢单线程Python代码的效率。

这在以前已经试过了,结果令人失望,这也是为什么我自已不愿意花太多精力的原因。在1999年Greg Stein(和Mark Hammond?)创建了一个去掉GIL(我相信是1.5)的分支,在所有可变数据结构上把GIL替换为细粒度锁。他也提交了补丁,可以去掉在全局可变数据结构上的许多信赖(reliance),我接受了。然而,做过了基准测试之后,它显示即使是在有着最快速的锁原语的平台上(当时是Windows)它减慢了单线程的执行效率将近2倍,意味着,与一颗CPU有GIL相比,不用GIL需要2颗CPU才能快一些。(参见Greg关于性能的 记录。)

我很欢迎如果有人按照Greg补丁(我在网上没有找到)的方法做了另外的试验,并且我也原意向Py3k引入一系列的补丁,但要保证对于单线程程序(和多线程但是I/O约束的程序)的性能不会降低。

我也会很高兴如果有人自告奋勇地维护一个无GIL的Python分支,假使单线程性能目标不能达到但是对于多线程CPU约束的应用有巨大的价值。我们甚至可以永久地终止部分代码基线的修改,仅仅允许根据编译的请求来生效。

然而,我想提醒一下,去掉GIL有许多的问题。它会使扩展模块变得复杂,不能再指望它们是在被GIL保护的“安全区”中被调用--一旦扩展有任何的全局可变数据,将不得不为多线程并发调用做好准备。也可能需要对Python/C API进行改动,它们是为了在一系列的调用中需要对某种对象加锁所需要的。

尽管这是我个人的意见,基于以上的考虑,去掉GIL没有太大的价值而不必花太多精力,但对于试图显示那个时代已经过去了的努力,我会欢迎和给予支持。然而,只是恳求是没有必要的--Python是开源的,并且我正在努力产生一个高质量的3.0语法的定义并且按计划实现。我想再一次指出并不是语言本身需要它--它只是由于CPython虚拟机在历史上还无法摆脱它。

原文链接
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值