【譯】Ruby2.6的JIT功能，編譯和解釋型語言的相關說明

時間 2019-11-08

標籤 ruby2.6 ruby jit 功能編譯解釋語言相關說明欄目 Ruby 简体版

原文原文鏈接

一篇闡述編譯以及解釋相關概念的文章，對於理解計算機語言的編譯以及解釋的過程有必定的好處，同時還會了解到JIT究竟是個什麼東西。原文連接: medium.com/@mich_berr/…程序員

Ruby2.6在幾個星期以前發佈了，新特性是一個嶄新的Just-In-Time(JIT)編譯器. 你能夠點擊這裏讀到關於關於新特性的更多細節，但若是你在尋找更多的背景知識，那麼我想一個闡述編譯型語言，解釋型語言，以及JIT是如何工做的相關指引會對你有所幫助。編程

首先，什麼是編程語言？全部的編程語言都是機器代碼的抽象。機器代碼是由位(許多的0和1)組成的,能夠經過你機器的硬件進行存儲和執行。讓人類去閱讀和編寫二進制是很是低效的事情，這也是咱們發明編程語言的理由。windows

解釋和編譯的不一樣之處主要在於人類編寫的程序是怎麼轉換成機器能夠執行的指令集的。有的時候編程語言並不能明確地劃分爲是究竟是編譯型的仍是解釋型的；編譯和解釋是把你寫的代碼轉換成機器可讀代碼的兩種不一樣的策略。咱們會在討論JIT的時候瞭解到編譯和解釋之間的界線變得愈加模糊。緩存

編譯

簡單來講，編譯就是把高級的編程語言轉換成機器可以識別的語言。ruby

讓咱們拿C語言來作個例子，它是一門有表明性的編譯型語言。爲了運行C語言寫的程序，必須使用像gcc或者clang這樣的編譯器，把C語言的源代碼編譯成能適應你計算機的機器碼。須要重點指出，不一樣的電腦可能會有不一樣的CPU架構，意味着一臺電腦處理0和1序列的方式跟另外一臺電腦是不同。一個編譯器會把源代碼轉換成特定架構的機器代碼。一旦你的代碼被編譯完，它能夠按你但願的那樣運行在任何具備相同架構的系統上。不過若是你更新了源代碼，或者想要把你的程序運行在具備不一樣架構的機器上的時候，你就須要對代碼進行從新編譯了。數據結構

編譯器的一個很好的類比就是人類的翻譯人員。跟翻譯人員把西班牙語的書翻譯成英文書籍那樣，一個編譯器就是把人類編寫的源代碼翻譯成機器代碼。一旦一本書被翻譯完，任何懂英語的讀者都可以閱讀它。然而若是原來西班牙語版本的書籍有所改動，英文版將須要從新翻譯相關的部分並再次發佈。架構

解釋

不像編譯器能夠在程序運行以前預先把源代碼翻譯成機器碼，解釋器是一行接着一行，一邊翻譯一邊執行。繼續以前的類比，計算機解釋器就像一個口譯人員。他們充當西班牙語以及英語談話者交流的橋樑，一句句實時地翻譯出來。編程語言

咱們用Ruby做爲「解釋型」語言的一個例子。Ruby1.8以及更早的版本，那個時候的Ruby解釋器(MRI), 它的行爲就像上面描述的那樣。它讀取每一行Ruby代碼，解析並token化，而後使用一個樹型的數據結構來執行它。而從版本1.9開始，Ruby切換到一個包含YARV(Yet Another Ruby Virtual Machine)的實現。在這個實現裏，Ruby會被預編譯成字節碼，這樣命名是由於它們會佔用一個字節的內存空間。一個很是簡單的例子，2+3 將會把加法運算轉換成字節碼的形式，而且接收2和3做爲參數，一旦Ruby代碼被轉換成字節碼，這些字節碼將會由虛擬機一行一行地執行。把源代碼轉換成字節碼對提高運行速度有重大意義。函數

Python固然也會利用字節碼，你能夠直接在Python程序產生的.pyc文件裏面看到它。這些文件的做用就像是一個緩存；若是Python代碼再次運行，卻沒有做任何修改，能夠跳過編譯的步驟直接執行相關的字節碼文件。當Ruby編程成字節碼以後，它的字節碼只是存儲在內存中而不是持久化到文件。性能

Just-In-Time編譯

我剛剛描述了一些當代的一些解釋型語言現在是怎麼包含字節碼編譯這一步驟的，但還有另外一種方式，它會使編譯與解釋之間的界線開始模糊起來，被稱爲Just-In-Time編譯。

最流行的Just-In-Time編譯器就是Java虛擬機(JVM)了。Java是一門靜態類型的編程語言，它能夠直接被編譯成機器代碼，可是這一般都會經過JVM來完成轉換。在近期的案例中，Java代碼會被Javac編譯器編譯成Java字節碼，這些字節碼會由JVM來翻譯並執行。然而JVM並不會一句句地去翻譯字節碼。相反，在這個時候它會嘗試去組合像函數那樣的有意義的代碼塊。而要決定怎麼去組合這些代碼塊將會稍微有點耗時，不過最終會使執行更加高效。這個過程被稱之爲Just-In-Time編譯，由於它的行爲就像是一個編譯器，區別就是它會在運行時進行編譯。使用JVM的好處是它既保留了編譯型語言的性能特徵又讓Java能夠像解釋型語言那樣移植到不一樣的機器上。Java是世界上最流行的編程語言，很大一部分緣由要歸功於它的JVM。

除了JVM以外，已經有其餘的VM項目採用了JIT編譯。PyPy是一個包含JIT功能的Python解釋器，固然如今的Ruby也有可選的JIT功能了。

折衷

如今你已經對編譯型以及解釋型語言有個大概的瞭解了，那麼他們各自是如何權衡的呢？

速度

編譯型語言一般會比解釋型語言快許多。一個編譯好的C程序可能要比Python，Ruby這樣的解釋型語言快上好幾個量級。然而Java的JIT解決方案也是很是高效的，它的運行速度能夠幾乎能夠媲美C語言所寫的程序。

可移植性

爲了在不一樣架構的機器上運行你編譯好的程序，你須要從新編譯它。當一門語言被解釋以後，它的指令集能夠在具備不一樣架構的機器上運行(固然要有相關的虛擬機)。JVM就是很好的例子，它結合瞭解釋以及編譯兩門技術，最大程度地兼顧了速度以及可移植性。

動態類型 VS 靜態類型

編譯器必需要把應用程序轉換並組合成機器指令，這是很是死板的。當聲明一個變量的時候，編譯器須要明確地知道是什麼類型的變量以及須要爲它分配多少內存空間。這就是爲何編譯一般都要求靜態類型。做爲對比，解釋器一行行地執行相關的程序，所以他們的行爲更靈活。

在Ruby裏面，咱們能夠寫出像2 + 3 或者"a" + "b"這樣的代碼，解釋器會在運行時肯定對象的類型，不論是整數的相加，仍是字符串的拼接，都會爲它們調用正確的方法。

Bugs/調試

解釋型語言一般更容易調試，由於程序在趕上錯誤以前會一直執行。解釋器將會告知用戶具體是哪一行引起的運行時錯誤，反之，在編譯好的程序裏面bug比較難以發現。

FAQS

爲何把一門語言當作是「編譯型語言」或者「解釋型語言」是用詞不當的？

一門語言是根據他們的語法以及數據結構來肯定的。編譯及解釋是把語言的語法轉換成能夠在硬件上運行的形式的兩種不一樣的實現方式。「編譯」或者「解釋」並非語言的天性；同一門語言可能會同時包含這兩種實現方式。

爲何人們把Python看做是解釋型語言把C看做是編譯型語言？

他們都是參考了該語言最通用的實現或者是發行版本。然而Python也可以被編譯，C語言固然也能夠被解釋。

什麼是虛擬機？

一個虛擬機就是一切行爲像計算機那樣的抽象，意味着它可以接收一系列的指令，與硬件的實現方式不一樣，它是經過軟件來實現的。虛擬機一般用於在計算機的一個操做系統上運行其餘的操做系統。舉個例子，你有一個windows的筆記本，可是想要仿真一個Linux的操做系統。你會利用一個軟件，它隱蔽在你物理機的操做系統跟你想要運行的操做系統之間。這被稱爲一個「系統虛擬機」。

不要跟以前的例子混淆，那些是「程序虛擬機」。好比，Java的虛擬機(JVM)或者Ruby的虛擬機(YARV)。這些都會被看做是虛擬機，由於它們能夠接收指令集並運行相關的字節碼。虛擬機的好處是對硬件進行抽象並提供了一個平臺獨立的編程環境。

爲何人們一般認爲Python和Ruby有解釋器，而Java有虛擬機？解釋器是否也符合虛擬機的定義？

解釋器和虛擬機的更可能是語義上的區別，或者像這我的所闡述的是「社會構建」上的區別。我以爲解釋器是符合虛擬機的定義的。嚴格意義上，Ruby和Python的解釋器都包含可以處理相關字節碼的虛擬機。而另外一方面，JVM本質上跟Ruby或者Python的解釋器有所不一樣。我已經在這篇文章中觸及了一小部分的緣由，不過剩下的知識已超出這篇文章的範圍。

爲何解釋一門語言以前先把它編譯成字節碼能使速度加快？

字節碼會比源碼耗費更少的內存空間，而且更容易被解釋器執行。當一門語言要被編譯成字節碼，解釋器必需要解析全部的語句，把他們轉換成字節碼，而後解析字節碼並執行它們。對一個簡單的代碼片斷而言，這個中間的步驟會小幅度地增長了執行的時間。然而，對那些須要重複執行的代碼，好比，循環或者是可複用的方法等，字節碼的步驟可以大幅度提高速度。