Python 3.2-GIL-好/坏？

Question

Python3.2阿尔法is out。

从变更日志来看，GIL似乎已经完全重写。

几个问题：

1. 有一个吉尔是好是坏？（和 为什么）。
2. 新的吉尔好点了吗？如果是，怎么做？

更新：

我对Python还不太熟悉。所以所有这些对我来说都是新的，但我至少明白，与CPython一起存在GIL是一件大事。

但问题是，为什么CPython不只是像Perl那样克隆解释器，试图消除对GIL的需求？

Answer 1

Is having a GIL good or bad? (and why).

两者都不是——或者两者都不是。线程同步是必要的。

Is the new GIL better? If so, how?

你做过基准测试吗？如果没有，那么您可能应该（1）运行一个基准，（2）在问题中发布基准，（3）对基准结果提出具体的问题。

用模糊的、手工的方式讨论GIL在很大程度上是浪费时间。

然而，在基准测试的特定上下文中讨论GIL可以导致性能问题的解决方案。

Question though, why does CPython not just clone the interpreter like Perl does in an attempt to remove the need for the GIL?

读这个：http://perldoc.perl.org/perlthrtut.html

首先，Perl根本不支持线程。旧的Perl解释器有一个错误模块，无法正常工作。

其次，较新的Perl解释器具有这一特性。

The biggest difference between Perl ithreads and the old 5.005 style threading, or for that matter, to most other threading systems out there, is that by default, no data is shared. When a new Perl thread is created, all the data associated with the current thread is copied to the new thread, and is subsequently private to that new thread!

由于Perl（只有特定的数据是共享的）模型与Python（所有数据都是共享的）模型不同，复制Perl解释器将从根本上中断Python的线程。Perl线程模型有本质的不同。

Answer 2

Is the new GIL better? If so, how?

好吧，它至少取代了操作计数切换到正确的时间计数。这不会提高整体性能（甚至可能会因为更频繁的切换而损害整体性能），但这会使线程更具响应性，并消除当所有线程都被锁定时，如果其中一个线程使用计算量很大的单操作代码（如调用不释放GIL的外部函数）的情况。

why does CPython not just clone the interpreter like Perl does in an attempt to remove the need for the GIL?

吉尔是一个复杂的问题，它不应该被视为终极邪恶。它给我们带来了线程安全。

至于perl，perl是a）死了，b）太老了。谷歌的人正致力于把LLVM的好东西带到CPython上，这将改善GIL的行为（还没有完全移除GIL，tho）：http://code.google.com/p/unladen-swallow/

Answer 3

我看到的最好的解释就是为什么吉尔很差劲：

http://www.dabeaz.com/python/GIL.pdf

同一个人在这里做了一个关于新吉尔的报告：

http://www.dabeaz.com/python/NewGIL.pdf

如果已经做了那么多，它仍然很糟糕-只是没有那么糟糕。多线程的性能会更好。多核在使用一个python应用程序时仍然毫无用处。