为什么很多语言的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
