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

為什麼很多語言的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

