Python 开始准备让 GIL 变为可选了(PEP 703)

[huangzhe8263]

PEP 703 (Making the Global Interpreter Lock Optional in CPython) acceptance

Python 指导委员会宣布接受 PEP 703 （ Making the Global Interpreter Lock Optional ，让全局解释器锁成为可选），公布了实现 no-GIL （或称为自由线程） Python 详细的路线图。

CPython 的全局解释器锁（ GIL ）阻止了同时多线程执行代码，成为了在多核 CPU 上提高 Python 代码运行效率的一大障碍，消除这一障碍是好事，但这也有可能会破坏现有的扩展模块，或显著降低性能以及可维护性。

而第三方软件包生态系统是 Python 的一大优势，Python 项目在实现自由线程时需要谨慎，需要避免破坏这一优势。

推进 PEP 703 需要将其纳入主线，作为定期发布版本的一部分推出。Python 指导委员计划分成三个阶段：实验阶段，支持但不默认阶段，默认阶段。

来源: https://www.solidot.org/story?sid=76453

source: https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075

[jjx]

相当不以为然
放着 pypy 已经验证的 jit 可能显著的改变普通代码的性能不搞
搞这种东西

感觉决策的已经被绑架了

[proxytoworld]

@jjx 为什么 pypy 应用范围不如 cpython

[jjx]

@proxytoworld

cpython 的那帮人看不上所有的第三方实现, 没有资源来着

[CEBBCAT]

@jjx #1 我是 Python 菜鸟，社区也几乎不参与，不过我看到这个提案有一些讨论页面，推荐给你，也许现在提反对意见还不晚：

https://peps.python.org/pep-0703/
https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional/22606/9
https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075
https://medium.com/@karanpittie/pep-703-exploring-the-pros-and-cons-of-removing-the-global-interpreter-lock-gil-3b0d4e9d05e0

依次是：
提案
提案讨论
被接受后的讨论
Medium 社区总结

[Maerd]

@jjx 不是那么好改的，pypy 的内存管理方式会影响 C 语言拓展的兼容性，pypy 的实现和 cpython 本身就是不同的，C 语言拓展通常需要直接操作 Python 解释器的内存结构，如果换为 pypy 的方式，那么绝大多数的 c 语言拓展都要挂掉。

[jjx]

@Maerd


肯定不是抄了代码, 是抄方案

pypy 对 c 扩展也有解决方案,就是 hpy, 只是 cpython 那些人不推动,就做不起来的, 例如这个 nogil

pypy 已经有效的证明了 jit 可以改善普通 python 的代码从几倍到几十倍

实际开发这, 类似 xlwt/openpyxl/xhtml2pdf 这种纯 python 实现的, 能提速 n 倍

[huangzongzhuan]

😌 如果 Python 的原生性能问题能得到较好的解决，那 Python 真的挺无敌了

[sujin190]

@jjx 事实 pypy 毛病太多不流行是并不好用，内存消耗大非常多，预热很慢，扩展支持有问题，而且想自己编译十分麻烦，在生产环境用过很长时间，收益并没有想的那么高，还是又切会 cpython 了，十分友好的内存消耗和扩展支持才是 python 的优势，放弃了才是脑子有病，支持干掉 gil 但前提是不大范围提升内存要求和扩展支持要求，否则意义真不大

[jjx]

@sujin190

大家看法不同

我认为 jit 比引入 nogil 更急迫

[makelove]

原生性能这么差，上了这个多核也比不过 nodejs 单线程，且 nodejs 真单线程开发容易很多。业务要利用多核就用 worker thread

[adoal]

事实就是，对于社区驱动发展起来的草根语言，社区“官方”的“参考”实现是足够强势的，其它实现做得再好，有理念冲突的时候也掰不动“官方”的手腕

[bianhui]

我觉得 no-GIL 对现有生态肯定是毁灭性的打击。之前很多项目，很多第三方软件包，得益于 GIL 的关系，开发的很简单。如果没了，很难想象切换，迁移的成本，最主要很多逻辑是隐藏的，不是说改就能改的。

[duojiao]

@bianhui 支持，那么多库，关了 GIL 都不知道要废了多少，水位都是不知道的

[Huelse]

要不直接改为 python4 吧，来个像当年一样的不兼容更改，或许会更好？

[lambdaq]

@Huelse 直接 python 6

[guog]

@lambdaq Python8 2**3

[wizardyhnr]

CPython 的生态太香了，要么 CPython 上面缝缝补补，要重新另起炉灶重新构造生态，那还不如走 Mojo 路线纯追求性能。
非官方实现吸引不了开发者是不够香，怪官方也没什么意义吧，开发者都是用脚投票的。

[junkun]

@duojiao 我也觉得估计又要搞一次 2~3 了。这个 no gil 基本就是为了满足 pytorch 用户想多线程加载数据的。说实话，就性能而言，gil 真不如 jit 重要。

[TryBetterApp]

我对 no-GIL 也不感冒，Python 生态 & 基础设施库， 已经非常庞大了，做这个伤筋动骨的事，风险大于收益。（兼容性 & 测试成本 & 对齐成本）

Mojo 已经在路上，可能未来需要 no-GIL 的场景，切 Mojo 就可以（ 100% 兼容保证）。

不在意 GIL 的场景，写 Python 依然是最舒服的。

（不乐观瞎猜，这个计划会随着 Mojo 的持续发展而流产，失去存在必要）

[Maerd]

@TryBetterApp mojo 所谓的 100%兼容就是遇到 python 代码时在 mojo 里开一个 cpython 解释器，纯属脱裤子放屁的操作

[TryBetterApp]

@Maerd #20 mojo 只是当前版本依赖 cpython, 后续会内置一个 mojo 实现的 python 解释器.

是不是脱裤子放屁, 不重要.

脱裤子放屁, 性能更好. 也比不脱强.

[Maerd]

@TryBetterApp 实现解释器？很难想象他自己实现的 python 解释器如何兼容 c 拓展，即使是 cpython 都不能保证跨版本兼容，很明显只是个“兼容 python 语法”的新语言，和 python 比起来还差很远