先前 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++成为最后归宿？
个人想法而已，我什么都不确定。。。
 |
1
janxin Apr 10, 2017 via iPhone
cython 历史比 hhvm 久吧…而且也不是为了科学运算
|
 |
2
cchange Apr 10, 2017 via iPhone
C++能发挥硬件性能是真的
但实在是太难驾驭了 不是说 c 用不好会砸到自己的脚 C++用不好能废掉整个一条腿 |
 |
3
j5shi Apr 10, 2017 via iPhone
首先， Cython 不是什么科学分析师搞出来的， python 的最早是用 C 实现的，为了区分 Jython ， IronPython 和 PyPy ，所以叫 Cython 。其次 Python 的最终归宿不会是静态语言，否则很多动态语言的特性都会丢失，要不然也没必要发明 Python 了，你理解的静态只是底层的实现语言而已。
|
 |
6
jianmingforpc Apr 10, 2017 via iPhone
cython 是不是被放弃交给社区维护那个？
|
 |
7
levn Apr 10, 2017 via iPad
处理不确定性也是刚需
|
 |
8
BingoXuan Apr 10, 2017 via Android
python 一开始就是用 c 写出来的。其实性能不够，大多机器来凑。
|
 |
10
clino Apr 10, 2017 via Android  1
python 的运行效率一直都是比较低的
这也说明 py 的使用范围扩展到了 cpu 密集型的领域，或者这些领域的人用静态语言已经用烦了 |
 |
11
xyjtou Apr 10, 2017
据说 Python 转成 pypy 来运行，平均提升的效率也只有 2~4 倍。对于绝大多数场景，扩容 2~4 倍硬件就能解决的事情，都没必要在转码了。
遇到用超级计算机都还要考虑到性能优化的活，那还是不要用 Python 写吧。 |
 |
12
cy18 Apr 10, 2017 via Android
PHP 这块不是很清楚， Python 最开始的定位就有点胶水语言的意思，其优点就是容易跟 C 集成， Python 很多模块都是用 C 写的。 Cython 只是进一步简化了这个过程。
|
 |
13
lalalakakaka Apr 10, 2017 1
python 1991~
php 1995~ 明明 python 资格更老来着，为什么需要借鉴 php 的历史？ |
 |
14
Zzzzzzzzz Apr 10, 2017
Cython 衍生自 Pyrex, 后者流行时 FB 还没开张呢....
|
 |
15
rogerchen Apr 10, 2017
真正要性能的时候 python 就是个超级 wrapper 罢了。
|
 |
16
deepreader OP @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. |
 |
17
wangxn Apr 10, 2017 via Android
Python 做个胶水语言也挺好的。内在的弱点使得它很难上 JIT 。
|
 |
18
di94sh Apr 10, 2017 via Android
io 密集型 用 python
|
|
19
deepreader OP |
 |
22
abcbuzhiming Apr 10, 2017
我们需要的语言，其实和动态静态无关，我们需要的其实应该是有编译前类型检查，带 GC ，最好还能热更新的现代语言，只是目前满足这几点的都是静态语言而已
|
|
23
abcbuzhiming Apr 10, 2017
@sagaxu 其实不管是 pypy 还是 HVVM 都算不上成功，目前 jit 这条路就 node 这一个比较成功的例子
|
 |
24
sagaxu Apr 10, 2017
@abcbuzhiming node 是因为没有历史包袱。 pypy 技术上 OK 的，但是一堆为 CPython 写的 C 扩展不兼容，没有办法的。如果一开始就是 pypy ，没有 CPython 这个包袱，扩展都用兼容的方式写，就跟 node 一样了。
|
|
25
wangxn Apr 10, 2017 via Android
@sagaxu 确实。但这些非官方实现也是小打小闹了，兼容性全无。 Python 的威力就在于 CPython 包罗万有的软件库。这些库都依赖于引用计数为基础的 GC 系统，所以，基本不可能上 JIT 了。
|
 |
26
allinwonder Apr 10, 2017 via Android
Nim
|
 |
27
laxenade Apr 10, 2017
不如先把 GIL 处理处理来的实在
|
 |
28
niseshiki Apr 10, 2017
按我的印象， Python 社区根本不想把 Python 的性能提升起来。我不止一次地被人说， GIL 根本不是问题，因为计算机的性能是过剩的，性能瓶颈是很少的，少数瓶颈用 C 解决就好，多进程比多线程好，多线程是 Windows 没有 COW 的进程而折腾出来的不必要的东西。对，我在 Python 的官网上也能看到这些。
这些都未必没有道理。 只是，你不承认问题，你就没有办法解决问题。 |
|
29
sagaxu Apr 10, 2017
@wangxn
也不是完全不兼容，事实上大部分给 CPython 写的库，在 pypy 下也是可以用的。 pip 下载量 top 1000 的库，绝大部分是兼容 pypy 的，也有一些公司生产环境中已经在用 pypy 了。 http://packages.pypy.org/ |
|
30
sagaxu Apr 10, 2017
@niseshiki
GIL 不是最大的问题，最大的问题是单线程执行的时候性能也不行，被 PHP7 吊打。虽然可以换 pypy ，或者通过引入 numpy 这类 C 扩展，或者用 cython 写扩展解决局部瓶颈。如果能像 PHP7 一样，用户不用做任何事情，直接带来数倍性能提升，当然就更好了。 其实有时候吐槽 python 性能瓶颈，一天的 PV 可能也就几百万或者一两千万，那都是无病呻吟。 |
 |
31
QAPTEAWH Apr 10, 2017
不是 C/C++快，而是解释开销太大。直接 Python 编译到 ASM 难度太大，先编译到 C 中转一下。
|
 |
32
neoblackcap Apr 10, 2017
Python 不是 JIT 不能做，那是做 JIT 很大可能就要破坏现有的接口，动 C API ，那么就一大堆 C 扩展不能用，这个才是最大的问题。
而且 GC 改成 tracing gc 我觉得其实是挺好的，引用计数会有很多问题的，现代的 GC 大多是 tracing GC |
 |
33
yanzixuan Apr 10, 2017
python 就是调用 C 就行了嘛。要说效率不行， tensorflow 用 Python 不一样好好的。
|
|
34
niseshiki Apr 10, 2017
@neoblackcap 为什么一做 JIT 就破坏现有接口？因为接口暴露了太多实现细节。
另外 Python 的 GC 据我所知是既 count 也 trace 的。 |
 |
35
lilydjwg Apr 10, 2017
为什么你会认为 Cython 和 HHVM 是同类？ Cython 是为了给 C ABI 的库做 CPython binding 而弄的，既不是 VM 也不是帮你提速的。
|
 |
36
hareandlion Apr 10, 2017 via iPhone
计算机科学发展到现在，为什么要求一门语言所有方面都完美无缺呢？明明有更快的轮子，又不是只为学习，何必破坏语言设计，自己造一个注定不会被所有人接受的新轮子
|
|
37
neoblackcap Apr 10, 2017
@neoblackcap 这是因为本身 CPython 代码质量高，二来 C API 暴露的底层细节太多了，很多东西都得在 runtime 时候才能知道，没法优化，知乎上面的 R 大曾经发过多篇文章说这方面。
然后就是 GC 的问题了，既然 tracing GC 能回收垃圾，那么为什么还要用引用计数？要知道引用计数其实是将每次回收的成本摊分，有人做过比较，除非是内存很紧张，否则朴素 mark-swap 的效率都比引用计数好。毕竟在两个回收周期里面不管 heap 上的对象怎么变化， GC 只管开头结果两个状态。还有就是这个 GC 由引起 GIL 的问题，如果不是引用计数的话， GIL 压根可以不存在，多线程提高多核利用率也可以做。而且社区还是很抵制这些改变，这也是一个问题。 Pycon 2016 US 就有人做演讲在做移除 GIL 的事情， Guido 对他的工作要求是，移除是可以的，但是不要降低单进程下的效率。真是要求很高啊。 |
 |
38
loryyang Apr 10, 2017
存在不代表是一个趋势， cython 存在很久了，这仅仅只代表存在这部分的需求
大部分 python 并不需要 cython 这种东西 |
|
39
deepreader OP @lilydjwg 我指 Cython 和 HipHop PHP 。 HHVM 是后话。
|
|
40
abcbuzhiming Apr 11, 2017
@niseshiki 在中国这个巨无霸开始在互联网发力之前，当时的计算机世界也确实不怎么需要计算性能了，欧洲，美洲人就那点人口，根本没有中国这种爆发性的计算需求，这就是为啥现在国内的重量级服务要么 C 要么 java 的原因，国内的人有时候喜欢人云亦云老外的说法，老外在国外呆着，当然不觉得 python 的性能有啥问题。德国地铁不来一趟中国，怎么会知道自己的峰值调度数据连北京日常数据都不如呢
|
|
41
deepreader OP @abcbuzhiming 中国人口红利。这个理论有点溜
|
|
42
niseshiki Jun 7, 2017
|
Select Language