为什么很多语言的JIT实现最后会失败,主要的技术原因和难点有哪些?
example:
unladen-swallow - A faster implementation of Python
http://psyco.sourceforge.net/

回复内容:

就拿 pypy 和 rubinius 这一对相映成趣的奇葩来看。JIT 越优化,与 C 交互的接口会越慢越复杂。 py 和 ruby 这类高度依赖三方 C 扩展的社区环境,很难忍痛割却这些遗产。rubinius 语法都没能做到兼容,很少有人能用起来;pypy 你 C 扩展就坑去吧。反观 jruby 能在很大程度上兼容 rails,而且附加了无 GIL 的真多线程,到现在已经算比较成功了。 至于 lua 和 js 这类沙盒里跑的内嵌脚本引擎,几乎没有与 C 扩展这个说法(包管理都没个说法),反而优化得比较凶。JIT 提升效率的同时会牺牲代码清晰度和跨平台性。一般不会 merge 回主支,只能平行维护。同时因为较差的清晰度和跨平台性又难以找到足够的维护力度。哪个语言的JIT失败了楼主提到的JIT多与Python有关,但是不该把Python关键字扔掉,因为显然不是JIT导致了这些项目改进的失败。 所以正确的问法应该是:为什么Python的许多JIT改进版本会失败?

如果把问题局限在Python,那么确实是这样的。 但是并非是JIT导致了这些项目的失败,JIT恰恰是真的解决了Python指令码解释执行慢的问题。 所以无论是Pypy或者Jython在很多性能测试指标下面能超越Cpython一截。这个意义上讲并不失败。 然而最关键的问题就是前向兼容,在采用JIT,去掉引用计数后,这些实现版本很大程度上不能和以前的Python程序库兼容了。因此很多Python的程序库就不能用了,比如说Numpy就不能用了。正是由于兼容性的原因,虽然执行效率一定程度上改进了,但是导致很多旧的程序库不能用了。

Python并不是以执行效率见长的语言,所以执行效率的提高很大程度上完全不能弥补前向兼容性。 因此这些版本当然不受待见了。 不过我还是不会说这些项目“失败”了。

今年早些的时候,Dropbox开始了一个叫Pyston得项目,致力于不仅要JIT Python执行,还要维持前向兼容。 在这么多前面尝试项目倒下的情况下,祝他们好运。感觉pypy的jit非常成功啊,很多逻辑运算甚至接近了go的速度。pypy很可能是python在服务器领域的未来。改造成jit基本成功了吧,只是很难证明失败。
如果是想证明自己是宇宙最好的语言,不同语言一般对业务处理中的效率影响微小,成功的语言都是在不同领域发挥其最基本的作用,而盲目对脚本语言做jit,想拿来对比编译语言,结果并没有让人”大喜过望“,甚至最后对语言产生怀疑,但jit失败了么,其实没有,他啥也没证明。就算是unladen-swallow的性能也已经大大提高了,只是没有达到预期目标而已,失败这个词太重了。你是说 那门语言呢 php 还是 js
08-25 02:23