為什麼很多語言的JIT實現最後會失敗，主要的技術原因和難點有哪些？

01-13

為什麼很多語言的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基本成功了吧，只是很難證明失敗。

如果是想證明自己是宇宙最好的語言，不同語言一般對業務處理中的效率影響微小，成功的語言都是在不同領域發揮其最基本的作用，而盲目對腳本語言做jit，想拿來對比編譯語言，結果並沒有讓人」大喜過望「，甚至最後對語言產生懷疑，但jit失敗了么，其實沒有，他啥也沒證明。

JIT 提升效率的同時會犧牲代碼清晰度和跨平台性。一般不會 merge 回主支，只能平行維護。同時因為較差的清晰度和跨平台性又難以找到足夠的維護力度。

樓主提到的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失敗了

就算是unladen-swallow的性能也已經大大提高了，只是沒有達到預期目標而已，失敗這個詞太重了。

你是說那門語言呢 php 還是 js