Python 3.2 - GIL -好还是坏？

Question

Python3.2Alpha

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

几个问题：

1. 吃的是好是坏？(为什么)
2. 是新的吉尔更好吗？如果是，怎么做？

更新

我对Python相当陌生。所以所有这些对我来说都是新的，但我至少明白，使用CPython的GIL的存在是一件很大的事情。

但是，为什么CPython不像Perl那样复制解释器以消除对GIL的需求？

Answer 1

我所见过的关于为什么吉尔很糟糕的最好解释是在这里：

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

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

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

如果已经做的就是这些，那还是很糟糕的--只是没那么糟糕。多个线程会表现得更好。使用单一的python应用程序，多核仍然不会对你有任何帮助。

Answer 2

吃的是好是坏？(以及为什么)。

也不是-或者两者都是。这是线程同步所必需的。

是新的吉尔更好吗？如果是这样的话，是怎么做的？

你运行过基准吗？如果不是，那么您可能应该(1)运行一个基准测试，(2)在问题中发布基准，(3)询问特定的关于基准测试结果的问题。

用模棱两可、挥手的方式讨论GIL在很大程度上是浪费时间。

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

然而，

的问题是，为什么CPython不像Perl那样复制解释器以消除对GIL的需求？

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

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

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

与旧的5.005风格线程之间最大的区别是，对于大多数其他线程系统来说，默认情况下不共享任何数据。当创建一个新的Perl线程时，与当前线程关联的所有数据都被复制到新线程中，并随后成为该新线程的私有数据！

由于Perl (只有特定的数据是共享的)模型不同于Python的(所有数据都是共享的)模型，所以复制Perl解释器将从根本上破坏Python的线程。Perl线程模型从根本上讲是不同的。

Answer 3

是新的吉尔更好吗？如果是这样的话，是怎么做的？

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

为什么CPython不像Perl那样复制解释器以消除对GIL的需求？

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

至于perl，perl是( a)死的，b)太老了。Google的工作人员正在致力于将LLVM的好处引入CPython，这将改善GIL的行为(还没有完全删除http://code.google.com/p/unladen-swallow/ )：http://code.google.com/p/unladen-swallow/。