去掉GIL不容易

翻译 2007年09月12日 21:44:00
昨天,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虚拟机在历史上还无法摆脱它。

原文链接

相关文章推荐

飞信mac版---不容易下到啊

  • 2012年05月16日 19:00
  • 7.54MB
  • 下载

android Contacts应用中不容易理解的点

1. withValueBackReference protected void createContactEntry() { ArrayList ops = n...

HDOJ 2045 不容易系列之(3)—— LELE的RPG难题

Problem Description 人称“AC女之杀手”的超级偶像LELE最近忽然玩起了深沉,这可急坏了众多“Cole”(LELE的粉丝,即”可乐”),经过多方打探,某资深Cole终于知道了原因...

"2013":爱你不容易

2013对我来说确实像年初时曾给自己定义的那样,真的是非常不平常的一年。依稀记得去年年终时,BOSS和我深聊了1多钟头,谈到职业规划、人生还有家庭的林林种种。春节在家时也仔细考虑过2013自己该如何规...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:去掉GIL不容易
举报原因:
原因补充:

(最多只允许输入30个字)