Redian新闻
>
Python社区变天:可去除全局解释器锁GIL,真正多线程要来了

Python社区变天:可去除全局解释器锁GIL,真正多线程要来了

公众号新闻

机器之心报道

编辑:杜伟、陈萍
这次,Python 将不再是人们所说的伪多线程了。

「Python 中的 GIL 将不复存在,这是人工智能生态系统领域中的巨大胜利。」PyTorch 核心维护者 Dmytro Dzhulgakov 感慨道。


GIL 是什么?GIL 的全称是 Global Interpreter Lock(全局解释器锁),它不是 Python 独有的,而是在实现 CPython(Python 解释器)时引入的一个概念。我们可以将 GIL 理解为一个互斥锁,用来保护 Python 里的对象,防止同一时刻多个线程执行 Python 的字节码,从而确保线程安全。

图源:https://realpython.com/python-gil/

然而,GIL 存在一个弊端,即在同一时刻只能有一个线程在一个 CPU 上执行,无法将多个线程映射到多个 CPU 上,使得 Python 并不能实现真正的多线程并发,从而降低了执行效率。

现在,Python 团队已经正式接受了删除 GIL 的这个提议,并将其设置为可选模式,可谓是利好广大开发者。

做出这一贡献的是一位来自 Meta 的名叫 Sam Gross 的软件工程师,他花费了四年多的时间才完成这一工程。

在得知这一消息后,大家纷纷叫好,深度学习三巨头之一的 Yann LeCun 发文祝贺:没有了 GIL,现在,Python 代码可以自由的执行多线程了。


「Python 中终于没有 GIL 了!」


「这是一个里程碑式的决定,是编码社区所热切期待的。」


具体细节如何,我们接着看下文。

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 场景)。但是我们也不能急于求成。我们认为这一过程将需要花费五年的时间。

当然在整个过程中,我们整个开发团队将需要实时评估进程并对时间线进行调整。

评论区的小伙伴们,你们对 GIL 成为可选是什么看法呢?

参考链接:
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


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:[email protected]

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。
相关阅读
Python吞噬世界,GPT吞噬Python!ChatGPT 上线最强应用:分析数据、生成代码都精通Python 吞噬世界,GPT 吞噬 Python!ChatGPT 上线最强应用:分析数据、生成代码都精通比Python快3.5万倍的Mojo融资7亿,LLVM之父:不会威胁到Python,该恐惧的应该是C++GitHub热榜登顶:开源版GPT-4代码解释器,可安装任意Python库,本地终端运行ChatGPT代码解释器与Jupyter Notebook合体,编码能力更强了OpenAI王炸!「代码解释器」下周正式上线,GPT-4 API全面开放爆火ChatGPT代码解释器食用指南,来了Python团队官宣下线GIL:可选择性关闭nǚ hóng?nǚ gōng今天,ChatGPT「代码解释器」正式解禁!30秒图片变视频,动嘴做表 | 十大惊人魔法全集Python社区大变天!可去除全局解释器锁GIL,真正多线程要来了!大隐隐于市!越南一家人在San Jose开的小店全是越南客人——Phở Cường 2“让 Python 快 5 倍”最新计划:优化解释器和内存管理面试难题:多线程事务怎么回滚?说用 @Transactional 可以回去等通知了!LPython:最新的高性能Python实现、速度极快且支持多后端Python指导委员会计划接受PEP 703提案,让全局解释器锁成为可选Python之父“摇人”来搞掉GIL,Meta果断出手木心,陈丹青及王朔狂揽13k star,开源版代码解释器登顶GitHub热榜,可本地运行、可访问互联网Python 之父“摇人”来搞掉 GIL,Meta 果断出手花儿无限量访问GPT-4!ChatGPT企业版来了,可扩展32k上下文,代码解释器随便用Python 吞噬世界,GPT 吞噬 Python!ChatGPT 上线最强应用Spring在多线程环境下如何确保事务一致性血色紅杉 - 你帶來了美國人民的深情LPython:最新的高性能 Python 实现、速度极快且支持多后端比Python快68000倍!Mojo正式发布,网友:Python生态系统最重要的升级来了详解Python文件: .py、.ipynb、.pyi、.pyc、​.pyd !比 Python 快 3.5 万倍的 Mojo 融资七亿,LLVM之父:不会威胁到 Python,该恐惧的应该是 C++开源版 GPT-4 代码解释器,可安装任意 Python 库,本地终端运行换机油Python 社区变天:可去除全局解释器锁 GIL,真正多线程要来了Excel变天!微软把Python「塞」进去了,直接可搞机器学习上下文1.6万token的编程大模型来了!与Stable Diffusion出自同门,一次吃5个Python文件不费劲《紅杉樹》
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。