xChar

Python 中有一把著名的锁——全局解释器锁(Global Interpreter Lock,简写 GIL),它的作用是防止多个本地线程同时执行 Python 字节码,这会导致 Python 无法实现真正的多线程执行。(注:本文中 Python 解释器特指 CPython)

这把锁在 Python 的早期发展中具有积极的作用(单核 CPU 时代),然而,它阻碍了 Python 在多核 CPU 上的并行编程,引起了开发者们与日俱增的诟病。

GIL 影响的主要是 CPU 密集型任务,比如科学计算与数值计算任务。

在最近发布的 PEP-703 中,它概括了 GIL 对科学计算(主要是 AI/ML)造成的四类问题:

  • GIL 导致许多并行化操作难以表达(影响强化学习、DeepMind、医学治疗及生物研究等领域)
  • GIL 影响了 Python 库的可用性(例如 PyTorch、scikit-learn、NumPy)
  • GIL 导致无法充分利用 GPU 资源(例如计算机视觉任务)
  • GIL 导致难以部署 Python AI 模型(例如基于神经网络的 AI 模型)

社区中想要移除 GIL 的呼声以及尝试,此起彼伏,绵绵不绝,但这个话题一直悬而未决。

抱怨、质疑、不满、不甘、期盼等这些诸多的情绪,不是那么容易平息的。然而,从一个积重已久的庞大的项目中移除一个根基性的设计,又谈何容易?

2023 新年刚过,这个话题又一次热了起来,又一轮对 GIL 的挑战开始了。

这一次,事情似乎有了新的转机,这次也许能成功了呢?

新鲜出炉的 PEP-703

PEP-703 在今年 1 月 9 日新鲜出炉,虽然它目前仍是“草案”状态未被采纳,但是这份 PEP 的意义十分重大!

(注:每个 Python 学习者都应该基本了解 PEP,建议阅读《学习Python,怎能不懂点PEP呢? 》)

这个 PEP 的作者是 Sam Gross,他是 nogil 项目的作者。Python猫的老读者应该有印象,我们在 2021 年曾翻译过他与 Python 核心开发者们的一次研讨会的纪要,这份纪要里概括了 nogil 的主要设计思路,同时回答了核心开发者们最为关注的约 20 个问题。

经过一年多时间的沉淀,nogil 项目现在终于形成了正式的 PEP,这意味着它被采纳进 Python 主分支的可能性变大了一些啦!

PEP 的标题是《使 CPython 的 GIL 成为可选项》(Making the Global Interpreter Lock Optional in CPython),内容详实,正文超过 1 万字,这个体量的 PEP 绝对够得上排在所有 PEP 的前十了。

简单而言,这份提案提议给 CPython 增加一个构建时配置项--disable-gil ,作用是构建出一个线程安全的无 GIL 的解释器。

为了实现无 GIL 的解释器,Python 底层的部分设计必须作出变更,内容可以概括成四类:

  • 引用计数
  • 内存管理
  • 容器线程安全
  • 锁和原子 API

如果这份 PEP 被采纳实现的话,它会带来一个不容忽视的问题:Python 将发布两个不同版本的解释器,而第三方库也要相应地开发/维护/发布两个版本的软件包。

PEP-703 的作者也考虑到了这个问题,他提出的解决方案是与 Anaconda 一起发布无 GIL 的 Python,同时在 conda 里集中发布管理那些兼容了新 Python 的库。

考虑到 Anaconda 在科学计算与数值计算领域的强大影响力,此举既能较好地发挥 nogil Python 的用处,又能减少用户及三方库开发者面对两种发行版时的割裂感。

值得注意的是,nogil 的 Python 还有一个更大的问题,那就是会影响单线程程序的性能。

基于 Python 3.11 版本,实现了有偏见的引用计数及永生对象后,Python 单线程性能会变慢 10%。

尽管这个数值在最新的 nogil 原型版本上可以降低到 5%,但是,另外至少还有两项难以规避的性能下降点:

  • 2% - 全局的自由列表(主要是元组和浮点数自由列表)
  • 1.5% - 集合中每个对象的互斥锁(字典、列表、队列)

单线程的代码才是最广泛的使用场景,可以说这会影响到每一个 Python 用户。任何试图移除 GIL 的项目都不可避免要面临这项挑战。

尽管存在着以上的两大问题,但 PEP-703 还是很有可取之处的。

比如,相比于 2015 年提出的著名的 Gilectomy 项目(由 GIL ectomy 两个单词组合而成,ectomy 是一个医学上的术语“切除术”),nogil 在单线程的性能上要快得多,同时可扩展性也更好。

比如,相比于 2021 年火热的“香农计划”的作者 Eric Snow 提出的 PEP-684 方案(给每个子解释器创建 GIL),后者一方面需要实现作为前提的多个 PEP(如 PEP-554、PEP-683),另一方面需要用户处理多子解释器间共享变量的麻烦。

PEP-684 给每个子解释器创建 GIL

在香农计划的《Python 3.12 目标》中,PEP-554 与 PEP-684 已经囊括在内了,版本目标是充分利用 Python 的子解释器,让子解释器使用各自的 GIL,从而实现多线程的并行。

好消息是,3.12 的计划跟本文的主角 PEP-703 并不冲突。事实上,它们的很多设计细节是一致的,也就是说,这两套对于 GIL 的改造方案是可以共存的,它们相互促进,事半功倍!

香农计划有 Python 之父 Guido van Rossum 站台,还有财大气粗的微软支持着一支豪华的团队投入开发(含 Guido 和 Eric Snow),因此,多解释器多 GIL 的方案很可能会更快落地。

Łukasz Langa 的倾力支持

而 PEP-703 有 PSF 首位全职开发者 Łukasz Langa 的倾力支持,社区的反响也不错,我觉得它今后落地的希望也挺大!

无论如何,这次香农计划和 PEP-703 掀起的对 GIL 的挑战,比以往所有的尝试都更猛烈,更有成功的可能,让人不由得心生欢欣之喜~~

但愿它们实现的一天不会太远吧。

Loading comments...