历史总是相似？- Python & PHP

[deepreader]

先前 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++成为最后归宿？

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

[sagaxu]

@clino python 在科学计算的时候，应尽量使用 numpy 之类的库

[abcbuzhiming]

我们需要的语言，其实和动态静态无关，我们需要的其实应该是有编译前类型检查，带 GC ，最好还能热更新的现代语言，只是目前满足这几点的都是静态语言而已

[abcbuzhiming]

@sagaxu 其实不管是 pypy 还是 HVVM 都算不上成功，目前 jit 这条路就 node 这一个比较成功的例子

[sagaxu]

@abcbuzhiming node 是因为没有历史包袱。 pypy 技术上 OK 的，但是一堆为 CPython 写的 C 扩展不兼容，没有办法的。如果一开始就是 pypy ，没有 CPython 这个包袱，扩展都用兼容的方式写，就跟 node 一样了。

[wangxn]

@sagaxu 确实。但这些非官方实现也是小打小闹了，兼容性全无。 Python 的威力就在于 CPython 包罗万有的软件库。这些库都依赖于引用计数为基础的 GC 系统，所以，基本不可能上 JIT 了。

[allinwonder]

Nim

[laxenade]

不如先把 GIL 处理处理来的实在

[niseshiki]

按我的印象， Python 社区根本不想把 Python 的性能提升起来。我不止一次地被人说， GIL 根本不是问题，因为计算机的性能是过剩的，性能瓶颈是很少的，少数瓶颈用 C 解决就好，多进程比多线程好，多线程是 Windows 没有 COW 的进程而折腾出来的不必要的东西。对，我在 Python 的官网上也能看到这些。
这些都未必没有道理。
只是，你不承认问题，你就没有办法解决问题。

[sagaxu]

@wangxn

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

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

http://packages.pypy.org/

[sagaxu]

@niseshiki

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

其实有时候吐槽 python 性能瓶颈，一天的 PV 可能也就几百万或者一两千万，那都是无病呻吟。

[QAPTEAWH]

不是 C/C++快，而是解释开销太大。直接 Python 编译到 ASM 难度太大，先编译到 C 中转一下。

[neoblackcap]

Python 不是 JIT 不能做，那是做 JIT 很大可能就要破坏现有的接口，动 C API ，那么就一大堆 C 扩展不能用，这个才是最大的问题。
而且 GC 改成 tracing gc 我觉得其实是挺好的，引用计数会有很多问题的，现代的 GC 大多是 tracing GC

[yanzixuan]

python 就是调用 C 就行了嘛。要说效率不行， tensorflow 用 Python 不一样好好的。

[niseshiki]

@neoblackcap 为什么一做 JIT 就破坏现有接口？因为接口暴露了太多实现细节。
另外 Python 的 GC 据我所知是既 count 也 trace 的。

[lilydjwg]

为什么你会认为 Cython 和 HHVM 是同类？ Cython 是为了给 C ABI 的库做 CPython binding 而弄的，既不是 VM 也不是帮你提速的。

[hareandlion]

计算机科学发展到现在，为什么要求一门语言所有方面都完美无缺呢？明明有更快的轮子，又不是只为学习，何必破坏语言设计，自己造一个注定不会被所有人接受的新轮子

[neoblackcap]

@neoblackcap 这是因为本身 CPython 代码质量高，二来 C API 暴露的底层细节太多了，很多东西都得在 runtime 时候才能知道，没法优化，知乎上面的 R 大曾经发过多篇文章说这方面。

然后就是 GC 的问题了，既然 tracing GC 能回收垃圾，那么为什么还要用引用计数？要知道引用计数其实是将每次回收的成本摊分，有人做过比较，除非是内存很紧张，否则朴素 mark-swap 的效率都比引用计数好。毕竟在两个回收周期里面不管 heap 上的对象怎么变化， GC 只管开头结果两个状态。还有就是这个 GC 由引起 GIL 的问题，如果不是引用计数的话， GIL 压根可以不存在，多线程提高多核利用率也可以做。而且社区还是很抵制这些改变，这也是一个问题。 Pycon 2016 US 就有人做演讲在做移除 GIL 的事情， Guido 对他的工作要求是，移除是可以的，但是不要降低单进程下的效率。真是要求很高啊。

[loryyang]

存在不代表是一个趋势， cython 存在很久了，这仅仅只代表存在这部分的需求
大部分 python 并不需要 cython 这种东西

[deepreader]

@lilydjwg 我指 Cython 和 HipHop PHP 。 HHVM 是后话。

[abcbuzhiming]

@niseshiki 在中国这个巨无霸开始在互联网发力之前，当时的计算机世界也确实不怎么需要计算性能了，欧洲，美洲人就那点人口，根本没有中国这种爆发性的计算需求，这就是为啥现在国内的重量级服务要么 C 要么 java 的原因，国内的人有时候喜欢人云亦云老外的说法，老外在国外呆着，当然不觉得 python 的性能有啥问题。德国地铁不来一趟中国，怎么会知道自己的峰值调度数据连北京日常数据都不如呢