V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐学习书目
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
huangzhe8263
V2EX  ›  Python

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

  •  
  •   huangzhe8263 ·
    onlyacat · 2023-10-27 10:31:55 +08:00 · 2983 次点击
    这是一个创建于 391 天前的主题,其中的信息可能已经有所发展或是发生改变。

    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

    22 条回复    2023-12-20 11:31:50 +08:00
    jjx
        1
    jjx  
       2023-10-27 10:34:56 +08:00
    相当不以为然
    放着 pypy 已经验证的 jit 可能显著的改变普通代码的性能不搞
    搞这种东西

    感觉决策的已经被绑架了
    proxytoworld
        2
    proxytoworld  
       2023-10-27 10:40:11 +08:00
    @jjx 为什么 pypy 应用范围不如 cpython
    jjx
        3
    jjx  
       2023-10-27 10:42:38 +08:00
    @proxytoworld

    cpython 的那帮人看不上所有的第三方实现, 没有资源来着
    CEBBCAT
        4
    CEBBCAT  
       2023-10-27 10:54:48 +08:00
    Maerd
        5
    Maerd  
       2023-10-27 11:03:16 +08:00
    @jjx 不是那么好改的,pypy 的内存管理方式会影响 C 语言拓展的兼容性,pypy 的实现和 cpython 本身就是不同的,C 语言拓展通常需要直接操作 Python 解释器的内存结构,如果换为 pypy 的方式,那么绝大多数的 c 语言拓展都要挂掉。
    jjx
        6
    jjx  
       2023-10-27 11:07:47 +08:00
    @Maerd


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

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

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

    实际开发这, 类似 xlwt/openpyxl/xhtml2pdf 这种纯 python 实现的, 能提速 n 倍
    o562dsRcFqYl375i
        7
    o562dsRcFqYl375i  
       2023-10-27 12:02:05 +08:00
    😌 如果 Python 的原生性能问题能得到较好的解决,那 Python 真的挺无敌了
    sujin190
        8
    sujin190  
       2023-10-27 12:09:58 +08:00 via Android
    @jjx 事实 pypy 毛病太多不流行是并不好用,内存消耗大非常多,预热很慢,扩展支持有问题,而且想自己编译十分麻烦,在生产环境用过很长时间,收益并没有想的那么高,还是又切会 cpython 了,十分友好的内存消耗和扩展支持才是 python 的优势,放弃了才是脑子有病,支持干掉 gil 但前提是不大范围提升内存要求和扩展支持要求,否则意义真不大
    jjx
        9
    jjx  
       2023-10-27 12:20:28 +08:00
    @sujin190

    大家看法不同

    我认为 jit 比引入 nogil 更急迫
    makelove
        10
    makelove  
       2023-10-27 12:53:47 +08:00
    原生性能这么差,上了这个多核也比不过 nodejs 单线程,且 nodejs 真单线程开发容易很多。业务要利用多核就用 worker thread
    adoal
        11
    adoal  
       2023-10-27 12:59:26 +08:00
    事实就是,对于社区驱动发展起来的草根语言,社区“官方”的“参考”实现是足够强势的,其它实现做得再好,有理念冲突的时候也掰不动“官方”的手腕
    bianhui
        12
    bianhui  
       2023-10-27 13:24:19 +08:00
    我觉得 no-GIL 对现有生态肯定是毁灭性的打击。之前很多项目,很多第三方软件包,得益于 GIL 的关系,开发的很简单。如果没了,很难想象切换,迁移的成本,最主要很多逻辑是隐藏的,不是说改就能改的。
    duojiao
        13
    duojiao  
       2023-10-27 13:29:52 +08:00
    @bianhui 支持,那么多库,关了 GIL 都不知道要废了多少,水位都是不知道的
    Huelse
        14
    Huelse  
       2023-10-27 13:34:55 +08:00
    要不直接改为 python4 吧,来个像当年一样的不兼容更改,或许会更好?
    lambdaq
        15
    lambdaq  
       2023-10-27 13:40:01 +08:00
    @Huelse 直接 python 6
    guog
        16
    guog  
       2023-10-27 13:50:55 +08:00 via Android
    @lambdaq Python8 2**3
    wizardyhnr
        17
    wizardyhnr  
       2023-10-28 00:34:19 +08:00
    CPython 的生态太香了,要么 CPython 上面缝缝补补,要重新另起炉灶重新构造生态,那还不如走 Mojo 路线纯追求性能。
    非官方实现吸引不了开发者是不够香,怪官方也没什么意义吧,开发者都是用脚投票的。
    junkun
        18
    junkun  
       2023-10-29 01:24:32 +08:00
    @duojiao 我也觉得估计又要搞一次 2~3 了。这个 no gil 基本就是为了满足 pytorch 用户想多线程加载数据的。说实话,就性能而言,gil 真不如 jit 重要。
    TryBetterApp
        19
    TryBetterApp  
       2023-10-31 15:25:49 +08:00
    我对 no-GIL 也不感冒,Python 生态 & 基础设施库, 已经非常庞大了,做这个伤筋动骨的事,风险大于收益。(兼容性 & 测试成本 & 对齐成本)

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

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

    (不乐观瞎猜,这个计划会随着 Mojo 的持续发展而流产,失去存在必要)
    Maerd
        20
    Maerd  
       2023-11-02 09:24:27 +08:00
    @TryBetterApp mojo 所谓的 100%兼容就是遇到 python 代码时在 mojo 里开一个 cpython 解释器,纯属脱裤子放屁的操作
    TryBetterApp
        21
    TryBetterApp  
       356 天前
    @Maerd #20 mojo 只是当前版本依赖 cpython, 后续会内置一个 mojo 实现的 python 解释器.

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

    脱裤子放屁, 性能更好. 也比不脱强.
    Maerd
        22
    Maerd  
       337 天前
    @TryBetterApp 实现解释器?很难想象他自己实现的 python 解释器如何兼容 c 拓展,即使是 cpython 都不能保证跨版本兼容,很明显只是个“兼容 python 语法”的新语言,和 python 比起来还差很远
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1414 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 17:23 · PVG 01:23 · LAX 09:23 · JFK 12:23
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.