V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
deepreader
V2EX  ›  程序员

历史总是相似?- Python & PHP

  •  
  •   deepreader · 2017-04-10 07:18:49 +08:00 · 7294 次点击
    这是一个创建于 2545 天前的主题,其中的信息可能已经有所发展或是发生改变。

    先前 PHP 性能不太行, Facebook 搞出了 HipHop PHP (HPHPc), transpile 到 C++代码。最终演化成 Hack & HHVM 。

    现在 Python 性能也不太行( CPU-bound ),科学计算的工程师们搞出了 Cython , transpile 到 C/C++代码。不知道最后会演化到什么?当然现在 Cython 还是依赖 Python interpreter memory management and GIL 。

    历史总是相似?对于 CPU-bound 的运算,果然众多动态语言最后都会演变成静态语言, C/C++成为最后归宿?

    个人想法而已,我什么都不确定。。。

    42 条回复    2017-06-07 11:10:23 +08:00
    janxin
        1
    janxin  
       2017-04-10 07:58:04 +08:00 via iPhone
    cython 历史比 hhvm 久吧…而且也不是为了科学运算
    cchange
        2
    cchange  
       2017-04-10 08:01:48 +08:00 via iPhone
    C++能发挥硬件性能是真的
    但实在是太难驾驭了 不是说 c 用不好会砸到自己的脚 C++用不好能废掉整个一条腿
    j5shi
        3
    j5shi  
       2017-04-10 08:04:19 +08:00 via iPhone
    首先, Cython 不是什么科学分析师搞出来的, python 的最早是用 C 实现的,为了区分 Jython , IronPython 和 PyPy ,所以叫 Cython 。其次 Python 的最终归宿不会是静态语言,否则很多动态语言的特性都会丢失,要不然也没必要发明 Python 了,你理解的静态只是底层的实现语言而已。
    XIVN1987
        4
    XIVN1987  
       2017-04-10 08:13:06 +08:00 via Android   ❤️ 3
    @j5shi
    你把 Cython 和 CPython 搞混了
    j5shi
        5
    j5shi  
       2017-04-10 08:16:13 +08:00 via iPhone
    @XIVN1987 不好意思是的
    jianmingforpc
        6
    jianmingforpc  
       2017-04-10 08:17:52 +08:00 via iPhone
    cython 是不是被放弃交给社区维护那个?
    levn
        7
    levn  
       2017-04-10 08:25:50 +08:00 via iPad
    处理不确定性也是刚需
    BingoXuan
        8
    BingoXuan  
       2017-04-10 08:34:41 +08:00 via Android
    python 一开始就是用 c 写出来的。其实性能不够,大多机器来凑。
    pyufftj
        9
    pyufftj  
       2017-04-10 08:52:55 +08:00
    @BingoXuan 而且大数情况下性能劣势根本显现不出来,瓶颈都在网络还有 IO 上。
    clino
        10
    clino  
       2017-04-10 08:53:43 +08:00 via Android   ❤️ 1
    python 的运行效率一直都是比较低的
    这也说明 py 的使用范围扩展到了 cpu 密集型的领域,或者这些领域的人用静态语言已经用烦了
    xyjtou
        11
    xyjtou  
       2017-04-10 08:54:49 +08:00
    据说 Python 转成 pypy 来运行,平均提升的效率也只有 2~4 倍。对于绝大多数场景,扩容 2~4 倍硬件就能解决的事情,都没必要在转码了。

    遇到用超级计算机都还要考虑到性能优化的活,那还是不要用 Python 写吧。
    cy18
        12
    cy18  
       2017-04-10 09:02:20 +08:00 via Android
    PHP 这块不是很清楚, Python 最开始的定位就有点胶水语言的意思,其优点就是容易跟 C 集成, Python 很多模块都是用 C 写的。 Cython 只是进一步简化了这个过程。
    lalalakakaka
        13
    lalalakakaka  
       2017-04-10 09:14:10 +08:00   ❤️ 1
    python 1991~
    php 1995~

    明明 python 资格更老来着,为什么需要借鉴 php 的历史?
    Zzzzzzzzz
        14
    Zzzzzzzzz  
       2017-04-10 09:17:12 +08:00
    Cython 衍生自 Pyrex, 后者流行时 FB 还没开张呢....
    rogerchen
        15
    rogerchen  
       2017-04-10 09:19:08 +08:00
    真正要性能的时候 python 就是个超级 wrapper 罢了。
    deepreader
        16
    deepreader  
    OP
       2017-04-10 11:54:57 +08:00
    @janxin 好像是 Cython 历史更早。现在主要是为了科学吧?最早是来拿干什么呢。

    @cchange C/C++难度不是一般,但是用到后面的大牛们都回归 C/C++, Google, Facebook 大面积的 C/C++。

    @levn 好逻辑!

    @BingoXuan 虽然 C 写的,但是比如 python a + b 因为 dynamic type 就内含了太多 Python 内部 C 的 operations 了,就慢了。

    @pyufftj 主要还是说 CPU-bound. IO-bound py3.6 coroutines 挺好用的,还有 uvloop 。

    @clino 好逻辑!

    @xyjtou Cython 主要是写 C-extenion ,并不是用来 replace PyPy

    @cy18 同意。

    @lalalakakaka 哈哈,可能是 php 借鉴 python 吧。

    @Zzzzzzzzz 好像是 Pyrex 资历要老点., 2002.

    @rogerchen 巨 Wrapper.
    wangxn
        17
    wangxn  
       2017-04-10 12:07:21 +08:00 via Android
    Python 做个胶水语言也挺好的。内在的弱点使得它很难上 JIT 。
    di94sh
        18
    di94sh  
       2017-04-10 12:15:40 +08:00 via Android
    io 密集型 用 python
    deepreader
        19
    deepreader  
    OP
       2017-04-10 12:24:50 +08:00
    @wangxn 动态语言的病根

    @di94sh 是呀。但是各种科学计算还是 CPU-bound 的。
    sagaxu
        20
    sagaxu  
       2017-04-10 13:34:43 +08:00
    @wangxn 是 CPython 的 JIT 不好做, pypy 早就做了, Jython 也是天生带 JIT
    sagaxu
        21
    sagaxu  
       2017-04-10 13:35:39 +08:00
    @clino python 在科学计算的时候,应尽量使用 numpy 之类的库
    abcbuzhiming
        22
    abcbuzhiming  
       2017-04-10 15:03:22 +08:00
    我们需要的语言,其实和动态静态无关,我们需要的其实应该是有编译前类型检查,带 GC ,最好还能热更新的现代语言,只是目前满足这几点的都是静态语言而已
    abcbuzhiming
        23
    abcbuzhiming  
       2017-04-10 15:04:18 +08:00
    @sagaxu 其实不管是 pypy 还是 HVVM 都算不上成功,目前 jit 这条路就 node 这一个比较成功的例子
    sagaxu
        24
    sagaxu  
       2017-04-10 15:22:20 +08:00
    @abcbuzhiming node 是因为没有历史包袱。 pypy 技术上 OK 的,但是一堆为 CPython 写的 C 扩展不兼容,没有办法的。如果一开始就是 pypy ,没有 CPython 这个包袱,扩展都用兼容的方式写,就跟 node 一样了。
    wangxn
        25
    wangxn  
       2017-04-10 15:27:05 +08:00 via Android
    @sagaxu 确实。但这些非官方实现也是小打小闹了,兼容性全无。 Python 的威力就在于 CPython 包罗万有的软件库。这些库都依赖于引用计数为基础的 GC 系统,所以,基本不可能上 JIT 了。
    allinwonder
        26
    allinwonder  
       2017-04-10 16:08:03 +08:00 via Android
    Nim
    laxenade
        27
    laxenade  
       2017-04-10 16:46:19 +08:00
    不如先把 GIL 处理处理来的实在
    niseshiki
        28
    niseshiki  
       2017-04-10 16:54:40 +08:00
    按我的印象, Python 社区根本不想把 Python 的性能提升起来。我不止一次地被人说, GIL 根本不是问题,因为计算机的性能是过剩的,性能瓶颈是很少的,少数瓶颈用 C 解决就好,多进程比多线程好,多线程是 Windows 没有 COW 的进程而折腾出来的不必要的东西。对,我在 Python 的官网上也能看到这些。
    这些都未必没有道理。
    只是,你不承认问题,你就没有办法解决问题。
    sagaxu
        29
    sagaxu  
       2017-04-10 17:24:14 +08:00
    @wangxn

    也不是完全不兼容,事实上大部分给 CPython 写的库,在 pypy 下也是可以用的。

    pip 下载量 top 1000 的库,绝大部分是兼容 pypy 的,也有一些公司生产环境中已经在用 pypy 了。

    http://packages.pypy.org/
    sagaxu
        30
    sagaxu  
       2017-04-10 17:37:25 +08:00
    @niseshiki

    GIL 不是最大的问题,最大的问题是单线程执行的时候性能也不行,被 PHP7 吊打。虽然可以换 pypy ,或者通过引入 numpy 这类 C 扩展,或者用 cython 写扩展解决局部瓶颈。如果能像 PHP7 一样,用户不用做任何事情,直接带来数倍性能提升,当然就更好了。

    其实有时候吐槽 python 性能瓶颈,一天的 PV 可能也就几百万或者一两千万,那都是无病呻吟。
    QAPTEAWH
        31
    QAPTEAWH  
       2017-04-10 17:41:24 +08:00
    不是 C/C++快,而是解释开销太大。直接 Python 编译到 ASM 难度太大,先编译到 C 中转一下。
    neoblackcap
        32
    neoblackcap  
       2017-04-10 17:46:45 +08:00
    Python 不是 JIT 不能做,那是做 JIT 很大可能就要破坏现有的接口,动 C API ,那么就一大堆 C 扩展不能用,这个才是最大的问题。
    而且 GC 改成 tracing gc 我觉得其实是挺好的,引用计数会有很多问题的,现代的 GC 大多是 tracing GC
    yanzixuan
        33
    yanzixuan  
       2017-04-10 17:49:07 +08:00
    python 就是调用 C 就行了嘛。要说效率不行, tensorflow 用 Python 不一样好好的。
    niseshiki
        34
    niseshiki  
       2017-04-10 18:43:02 +08:00
    @neoblackcap 为什么一做 JIT 就破坏现有接口?因为接口暴露了太多实现细节。
    另外 Python 的 GC 据我所知是既 count 也 trace 的。
    lilydjwg
        35
    lilydjwg  
       2017-04-10 18:53:34 +08:00
    为什么你会认为 Cython 和 HHVM 是同类? Cython 是为了给 C ABI 的库做 CPython binding 而弄的,既不是 VM 也不是帮你提速的。
    hareandlion
        36
    hareandlion  
       2017-04-10 19:02:10 +08:00 via iPhone
    计算机科学发展到现在,为什么要求一门语言所有方面都完美无缺呢?明明有更快的轮子,又不是只为学习,何必破坏语言设计,自己造一个注定不会被所有人接受的新轮子
    neoblackcap
        37
    neoblackcap  
       2017-04-10 19:59:52 +08:00
    @neoblackcap 这是因为本身 CPython 代码质量高,二来 C API 暴露的底层细节太多了,很多东西都得在 runtime 时候才能知道,没法优化,知乎上面的 R 大曾经发过多篇文章说这方面。

    然后就是 GC 的问题了,既然 tracing GC 能回收垃圾,那么为什么还要用引用计数?要知道引用计数其实是将每次回收的成本摊分,有人做过比较,除非是内存很紧张,否则朴素 mark-swap 的效率都比引用计数好。毕竟在两个回收周期里面不管 heap 上的对象怎么变化, GC 只管开头结果两个状态。还有就是这个 GC 由引起 GIL 的问题,如果不是引用计数的话, GIL 压根可以不存在,多线程提高多核利用率也可以做。而且社区还是很抵制这些改变,这也是一个问题。 Pycon 2016 US 就有人做演讲在做移除 GIL 的事情, Guido 对他的工作要求是,移除是可以的,但是不要降低单进程下的效率。真是要求很高啊。
    loryyang
        38
    loryyang  
       2017-04-10 20:12:44 +08:00
    存在不代表是一个趋势, cython 存在很久了,这仅仅只代表存在这部分的需求
    大部分 python 并不需要 cython 这种东西
    deepreader
        39
    deepreader  
    OP
       2017-04-11 00:15:15 +08:00
    @lilydjwg 我指 Cython 和 HipHop PHP 。 HHVM 是后话。
    abcbuzhiming
        40
    abcbuzhiming  
       2017-04-11 09:22:27 +08:00
    @niseshiki 在中国这个巨无霸开始在互联网发力之前,当时的计算机世界也确实不怎么需要计算性能了,欧洲,美洲人就那点人口,根本没有中国这种爆发性的计算需求,这就是为啥现在国内的重量级服务要么 C 要么 java 的原因,国内的人有时候喜欢人云亦云老外的说法,老外在国外呆着,当然不觉得 python 的性能有啥问题。德国地铁不来一趟中国,怎么会知道自己的峰值调度数据连北京日常数据都不如呢
    deepreader
        41
    deepreader  
    OP
       2017-04-11 11:01:08 +08:00
    @abcbuzhiming 中国人口红利。这个理论有点溜
    niseshiki
        42
    niseshiki  
       2017-06-07 11:10:23 +08:00
    @abcbuzhiming
    @deepreader 说得有理。互联网就是要用户量。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2578 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 15:40 · PVG 23:40 · LAX 08:40 · JFK 11:40
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.