关闭

去掉GIL不容易

标签: 多线程数据结构python扩展windows虚拟机
10115人阅读 评论(0) 收藏 举报
分类:
昨天,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虚拟机在历史上还无法摆脱它。

原文链接
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:131098次
    • 积分:1477
    • 等级:
    • 排名:千里之外
    • 原创:1篇
    • 转载:1篇
    • 译文:11篇
    • 评论:64条
    文章分类
    最新评论
    Guido的信息