Python 全局解释器锁 GIL 的重大新闻!
共 2786字,需浏览 6分钟
·
2023-08-02 20:35
花下猫语:在最新一期 Python 周刊中( 点击阅读 ),我分享了一则关于无 GIL 提案(PEP-703)的最新消息,这则消息已经引爆技术社区了!这里分享一篇文章,主要内容是对官方公告的翻译,可以一探后续的发展规划:
来源:机器之心
![ee35fbbbcb41e3ab04520759874bd2b3.webp](https://filescdn.proginn.com/945d9abeed7bab42a4f75c591ff6b84a/ee35fbbbcb41e3ab04520759874bd2b3.webp)
图源:https://realpython.com/python-gil/
然而,GIL 存在 一个弊端,即在同一时刻只能有一个线程在一个 CPU 上执行,无法将多个线程映射到多个 CPU 上,使得 Python 并不能实现真正的多线程并发,从而降低了执行效率。 现在,Python 团队已经正式接受了删除 GIL 的这个提议,并将其设置为可选模式,可谓是利好广大开发者。 做出这一贡献的是一位来自 Meta 的名叫 Sam Gross 的软件工程师,他花费了四年多的时间才完成这一工程。 在得知这一消息后,大家纷纷叫好,深度学习三巨头之一的 Yann LeCun 发文祝贺:没有了 GIL,现在,Python 代码可以自由的执行多线程了。![c05f77b1c179a85385a9791674fbf310.webp](https://filescdn.proginn.com/d5a2aef49449890ca9683ea6b97eb24a/c05f77b1c179a85385a9791674fbf310.webp)
![e73c934de9b83ce7d85afe803f4d53d4.webp](https://filescdn.proginn.com/762692a8877f09dd8959c05aead962a3/e73c934de9b83ce7d85afe803f4d53d4.webp)
![5294b3b2623544bb8e53951e828f8687.webp](https://filescdn.proginn.com/9d3db0f904f8230bb33860b9f7a97073/5294b3b2623544bb8e53951e828f8687.webp)
CPython 核心开发者 Thomas Wouters 撰文描述了 Python 中的无 GIL 细节,并对未来发展做了展望。 非常感谢所有人对无 GIL 提议的反馈,整体上都持积极的支持态度。指导委员会打算接受无 GIL 提议,并就以下具体细节与大家分享。 我们的基本设想是:
- 长期来看(大约 5 年以上),no-GIL 构建应是唯一的构建;
- 我们希望非常谨慎地对待向后兼容。我们不希望出现另一个 Python 3 的情况,所有适应 no-GIL 构建所需的第三方代码更改应只适用于 with-GIL 构建(尽管仍要解决更老 Python 版本的向后兼容性问题)。这不适用于 Python 4。我们仍在考虑对这两个构建的 ABI 兼容性和其他细节的要求,以及对向后兼容性的影响;
- 在我们承诺完全转向 no-GIL 之前,希望看到社区的支持。我们不能只是更改默认设置,更希望社区弄清自己做什么工作来给予我们支持。我们核心开发团队需要获得新构建模式及相关所有内容的经验。我们要整理现有代码中的线程安全性,需要弄明白新的 C API 和 Python API。我们在获得这些洞见时还需要传达给 Python 社区的其他人,并确保自身想要做出的更改以及希望其他人做出的更改是可取的;
-
在我们默认 no-GIL 设置之前的任何时候,如果事实证明了,它的破坏性太大导致收益太少,我们希望能够改变主意。这也就意味着我们会回滚所有工作,因此在我们确定要将 no-GIL 设为默认方式之前,特定于 no-GIL 的代码在某种程度上应是可识别的。
- 短期内,我们会将 no-GIL 构建作为一种实验性构建模式,大概会在 3.13 版本(也有可能推迟到 3.14 版本)可用。之所以是实验性的,是因为我们核心开发团队虽然支持这一构建模式,但不期望整个社区都会支持它。我们需要时间理清自己要做什么,至少在 API 设计以及打包和分发方面,从而得到社区的支持。我们也不鼓励 distributor 将实验性 no-GIL 构建作为默认解释器发布。
- 中期来看,在我们确信得到足够的社区支持并使 no-GIL 的生产使用可行后,我们将支持 no-GIL 构建,但不是默认方式,而是在某个目标日期或某个 Python 版本中使它成为默认方式。具体的时间将取决于很多因素,比如 API 更改最终的兼容性如何、社区认为他们仍然需要做多少工作等。我们预计这至少需要一至两年的时间。一旦我们宣布支持,预计将有一些 distributor 会开始默认发布 no-GIL。
-
长期来看,我们希望 no-GIL 成为默认方式,并删除 GIL 的所有痕迹(但不会不必要地破坏向后兼容性)。我们不希望等太长时间,毕竟两种常用的构建模式同时存在会给社区造成很大的负担(比如需要双倍测试资源和 debug 场景)。但是我们也不能急于求成。我们认为这一过程将需要花费五年的时间。
参考链接:
https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474
https://twitter.com/dzhulgakov/status/1685667015800066048![c18ce6c2364252f8f208c8ab9962ddae.webp](https://filescdn.proginn.com/d2299936cef4e865852d283d171bcf0e/c18ce6c2364252f8f208c8ab9962ddae.webp)
还不过瘾?试试它们
▲Python 潮流周刊#13:Jupyter Notebook 7 发布了,无 GIL 提案传来大好消息!