推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
Python 开始准备让 GIL 变为可选了(PEP 703)
huangzhe8263 · onlyacat · 2023-10-27 10:31:55 +08:00 · 3037 次点击这是一个创建于 431 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 2023-12-01 22:16:31 +08:00
|
|
22
Maerd 2023-12-20 11:31:50 +08:00
@TryBetterApp 实现解释器？很难想象他自己实现的 python 解释器如何兼容 c 拓展，即使是 cpython 都不能保证跨版本兼容，很明显只是个“兼容 python 语法”的新语言，和 python 比起来还差很远
|
Select Language