即時編譯器與解釋器的區別?


想先放幾個傳送門:虛擬機隨談(一):解釋器,樹遍歷解釋器,基於棧與基於寄存器,大雜燴(總放這個傳送門真不好…)

為什麼 JVM 不用 JIT 全程編譯? - RednaxelaFX 的回答

Java為什麼解釋執行時不直接解釋源碼? - RednaxelaFX 的回答

主要想說的是:解釋器既可以指一個表象,也可以指具體的實現方式;當它指的是表象時,它底下的具體實現既可以是一個真的解釋器,也可以是一個JIT編譯器,或者兩者的混合。

從表象意義上看,重點就在:

解釋:輸入程序代碼 -&> 得到執行結果,從用戶的角度看一步到位

編譯:輸入程序代碼 -&> 得到可執行代碼

要得到執行結果還得再去執行可執行代碼,從用戶的角度看有[一個單獨的編譯步驟]和[一個單獨的執行步驟]

&<- 這正是 @Irons Du 在問題評論里說的。

至於「解釋器」內部有沒有通過編譯來加速,這用戶就不關心了。

於是就有JIT編譯器這樣的,外面看起來像解釋器,其實裡面的實現是先編譯了再去執行編譯出來的代碼,這樣的做法。

注意:JIT編譯器自身並不混合解釋和編譯,它就是編譯器。

一個使用JIT編譯器實現的執行引擎,為了達到外在表象是解釋執行,需要先通過JIT編譯器將輸入的程序編譯為可執行代碼(這是JIT編譯器的職責),然後去執行這代碼(這不是JIT編譯器自身的職責,而是調用它的執行引擎的職責)。


簡單的回答一下,就以java為例。在jdk 1.0時代,java虛擬完全是解釋執行的。那什麼是解釋執行呢?解釋器(你可以理解為翻譯器)每次讀一代碼,就將位元組碼起轉換(翻譯)為JVM可執行的指令,一直到最後,說白了邊聽邊譯。這樣的結果顯易見,效率低下,更重要的是同樣的代碼每次都需要重新翻譯。這怎麼能忍,必須要解決啊。隨著後面的發展,現在大多數的主流的JVM都包含即時編譯器。那什麼是即時編譯器呢?所謂的即時編譯器說白了就是將源代碼直接生成符合本地物理機可識別的機器語言。還是拿java舉例唄,JVM在運行期間會根據代碼熱度來選擇是否代碼轉換為本地機器語言。當然,這個代碼熱度的判斷相對複雜,不僅僅是某個方法調用的次數達到指定閥值,不同的場景有不同的策略,具體就不說了。即時編譯器的好處在於可以對代碼進行深度優化,同時提高效率(只編譯了一次,以後每次都會調用執行的速度大大提高)


推薦閱讀:

什麼編譯器優化技術可以把FP語言里的sum [1..n]的效率優化到C語言的水平?
設計類Python編譯器時如何處理tab和space縮進?
為什麼所有的教科書中都不贊成手寫自底向上的語法分析器?
學好c++,是不是最好研究下其編譯器?因為感覺c++的編譯器做了很多僅從語言前端看不出的工作。?
如何去學習程序員的三大浪漫,編譯原理,圖形學,操作系統?

TAG:解釋器 | 即時編譯JIT | 編譯原理 | 編譯器 |