历史总是相似？- Python & PHP

处理不确定性也是刚需

python 一开始就是用 c 写出来的。其实性能不够，大多机器来凑。

@BingoXuan 而且大数情况下性能劣势根本显现不出来，瓶颈都在网络还有 IO 上。

python 的运行效率一直都是比较低的
这也说明 py 的使用范围扩展到了 cpu 密集型的领域，或者这些领域的人用静态语言已经用烦了

据说 Python 转成 pypy 来运行，平均提升的效率也只有 2~4 倍。对于绝大多数场景，扩容 2~4 倍硬件就能解决的事情，都没必要在转码了。

遇到用超级计算机都还要考虑到性能优化的活，那还是不要用 Python 写吧。

PHP 这块不是很清楚， Python 最开始的定位就有点胶水语言的意思，其优点就是容易跟 C 集成， Python 很多模块都是用 C 写的。 Cython 只是进一步简化了这个过程。

python 1991~
php 1995~

明明 python 资格更老来着，为什么需要借鉴 php 的历史？

Cython 衍生自 Pyrex, 后者流行时 FB 还没开张呢....

真正要性能的时候 python 就是个超级 wrapper 罢了。

@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.

Python 做个胶水语言也挺好的。内在的弱点使得它很难上 JIT 。

io 密集型 用 python

@wangxn 动态语言的病根

@di94sh 是呀。但是各种科学计算还是 CPU-bound 的。

@wangxn 是 CPython 的 JIT 不好做， pypy 早就做了， Jython 也是天生带 JIT

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

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

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

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

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

Nim

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

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

@wangxn

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

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

http://packages.pypy.org/

@niseshiki

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

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

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

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

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

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

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

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

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

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

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

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

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

@abcbuzhiming 中国人口红利。这个理论有点溜

@abcbuzhiming
@deepreader 说得有理。互联网就是要用户量。