Python 3.2 - GIL - 好/坏？

Question

Python 3.2 ALPHA 已经发布.

从更改日志中,看起来GIL已完全重写.

几个问题:

更新:

我对Python很新.所以这一切对我来说都是新的,但至少我明白用CPython存在GIL是一件大事.

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

Answer 1

我已经看到GIL糟透了的最佳解释是:

同一个人在这里有关于新GIL的演示:

如果这就完成了它仍然很糟糕 - 只是没那么糟糕.多线程会表现得更好.使用单个python应用程序,多核仍然无法为您做任何事情.

...但是多处理对细粒度并行性没有好处. (10认同)
...除非你使用多处理模块,这很容易做到. (6认同)
@Gabe:但"细粒度"的并行性经常被高估.操作系统级进程并行操作通常只能正常工作. (3认同)
@Basic请原谅我,我曾在更多的大公司工作过数百万行的资源,这些资源曾经被称为"只要尝试,如果有效",还有许多项目的初级人员,以及像我上面所述的大量错误.是.我的方法是,因为编写好的多线程代码是HARD(不是最低级别的能力),所以最好的做法是保持简单,IF(!!!)你打算使用超过一周的代码. (3认同)
@Paul Basic提到了合并排序,它是糟糕的细粒度并行性的好例子.编写mergesort很容易.编写安全高效的并行化mergesort既困难又复杂.细粒度的并行性总是需要一个好的专家.维护很难.错误提高,并得到修复.调试很难.线程总是痛苦而沉默.所以线程工作应该简单而且万无一失.对数据进行排序,查询数据和显示数据是不同的任务 - 使它们能够并行运行. (2认同)

Answer 2

有GIL好还是坏？(以及为什么).

既不 - 或两者兼而有之.线程同步是必要的.

新的GIL更好吗？如果是这样,怎么样？

你有没有运行任何基准测试？如果没有,那么也许您应该(1)运行基准,(2)在问题中发布基准,(3)询问有关基准结果的具体问题.

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

但是,在您的基准测试的特定环境中讨论GIL可以为您的性能问题提供解决方案.

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

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

其次,较新的Perl解释器具有此功能.

Perl ithreads和旧的5.005样式线程之间的最大区别,或者对于大多数其他线程系统而言,默认情况下,没有共享数据.创建新的Perl线程时,与当前线程关联的所有数据都将复制到新线程,并随后专用于该新线程!

由于Perl(仅共享特定数据)模型不同于Python(所有数据共享)模型,因此复制Perl解释器将从根本上破坏Python的线程.Perl线程模型根本不同.