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 指导委员计划分成三个阶段:实验阶段,支持但不默认阶段,默认阶段。
1
jjx 2023-10-27 10:34:56 +08:00
相当不以为然
放着 pypy 已经验证的 jit 可能显著的改变普通代码的性能不搞 搞这种东西 感觉决策的已经被绑架了 |
2
proxytoworld 2023-10-27 10:40:11 +08:00
@jjx 为什么 pypy 应用范围不如 cpython
|
3
jjx 2023-10-27 10:42:38 +08:00
|
4
CEBBCAT 2023-10-27 10:54:48 +08:00
@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 社区总结 |
5
Maerd 2023-10-27 11:03:16 +08:00
@jjx 不是那么好改的,pypy 的内存管理方式会影响 C 语言拓展的兼容性,pypy 的实现和 cpython 本身就是不同的,C 语言拓展通常需要直接操作 Python 解释器的内存结构,如果换为 pypy 的方式,那么绝大多数的 c 语言拓展都要挂掉。
|
6
jjx 2023-10-27 11:07:47 +08:00
@Maerd
肯定不是抄了代码, 是抄方案 pypy 对 c 扩展也有解决方案,就是 hpy, 只是 cpython 那些人不推动,就做不起来的, 例如这个 nogil pypy 已经有效的证明了 jit 可以改善普通 python 的代码从几倍到几十倍 实际开发这, 类似 xlwt/openpyxl/xhtml2pdf 这种纯 python 实现的, 能提速 n 倍 |
7
o562dsRcFqYl375i 2023-10-27 12:02:05 +08:00
😌 如果 Python 的原生性能问题能得到较好的解决,那 Python 真的挺无敌了
|
8
sujin190 2023-10-27 12:09:58 +08:00 via Android
@jjx 事实 pypy 毛病太多不流行是并不好用,内存消耗大非常多,预热很慢,扩展支持有问题,而且想自己编译十分麻烦,在生产环境用过很长时间,收益并没有想的那么高,还是又切会 cpython 了,十分友好的内存消耗和扩展支持才是 python 的优势,放弃了才是脑子有病,支持干掉 gil 但前提是不大范围提升内存要求和扩展支持要求,否则意义真不大
|
10
makelove 2023-10-27 12:53:47 +08:00
原生性能这么差,上了这个多核也比不过 nodejs 单线程,且 nodejs 真单线程开发容易很多。业务要利用多核就用 worker thread
|
11
adoal 2023-10-27 12:59:26 +08:00
事实就是,对于社区驱动发展起来的草根语言,社区“官方”的“参考”实现是足够强势的,其它实现做得再好,有理念冲突的时候也掰不动“官方”的手腕
|
12
bianhui 2023-10-27 13:24:19 +08:00
我觉得 no-GIL 对现有生态肯定是毁灭性的打击。之前很多项目,很多第三方软件包,得益于 GIL 的关系,开发的很简单。如果没了,很难想象切换,迁移的成本,最主要很多逻辑是隐藏的,不是说改就能改的。
|
14
Huelse 2023-10-27 13:34:55 +08:00
要不直接改为 python4 吧,来个像当年一样的不兼容更改,或许会更好?
|
17
wizardyhnr 2023-10-28 00:34:19 +08:00
CPython 的生态太香了,要么 CPython 上面缝缝补补,要重新另起炉灶重新构造生态,那还不如走 Mojo 路线纯追求性能。
非官方实现吸引不了开发者是不够香,怪官方也没什么意义吧,开发者都是用脚投票的。 |
18
junkun 2023-10-29 01:24:32 +08:00
@duojiao 我也觉得估计又要搞一次 2~3 了。这个 no gil 基本就是为了满足 pytorch 用户想多线程加载数据的。说实话,就性能而言,gil 真不如 jit 重要。
|
19
TryBetterApp 2023-10-31 15:25:49 +08:00
我对 no-GIL 也不感冒,Python 生态 & 基础设施库, 已经非常庞大了,做这个伤筋动骨的事,风险大于收益。(兼容性 & 测试成本 & 对齐成本)
Mojo 已经在路上,可能未来需要 no-GIL 的场景,切 Mojo 就可以( 100% 兼容保证)。 不在意 GIL 的场景,写 Python 依然是最舒服的。 (不乐观瞎猜,这个计划会随着 Mojo 的持续发展而流产,失去存在必要) |
20
Maerd 2023-11-02 09:24:27 +08:00
@TryBetterApp mojo 所谓的 100%兼容就是遇到 python 代码时在 mojo 里开一个 cpython 解释器,纯属脱裤子放屁的操作
|
21
TryBetterApp 340 天前
|
22
Maerd 321 天前
@TryBetterApp 实现解释器?很难想象他自己实现的 python 解释器如何兼容 c 拓展,即使是 cpython 都不能保证跨版本兼容,很明显只是个“兼容 python 语法”的新语言,和 python 比起来还差很远
|