編譯器與解釋器

為了讓更多的人能夠從本質(zhì)上理解編譯器和解釋器的區(qū)別,，我杜撰了一個小故事

來福與旺財?shù)酿B(yǎng)牛場

來福和旺財有一個 養(yǎng)牛場。本來養(yǎng)牛不是一件太難的事情,，但是偏偏他倆養(yǎng)的牛都有特別的怪癖,。奶牛阿圓只吃切成圓形的牧草，而奶牛阿方和阿三（印度來的,？）分別只吃切成正方 形和三角形的牧草,。如果來福和旺財拿不和奶牛性格的草去喂食，阿X們不但不產(chǎn)奶而且還會鄙視來福和旺財,。

于是來福和旺財分別有了自己的主意

來福的方案：

來福發(fā)明了三套大型碾碎機：圓圓碾碎機,，方方碾碎機和三三碾碎機。每天收割了牧草,，就分別放到這三套機器里碾碎給三頭奶牛吃,。但是一旦被碾碎了，這堆草就只能給某一頭牛吃了,。很明顯阿方是不會吃給阿圓準備的草的,。而且來福每天都要操作這三臺機器，覺得比較麻煩,。

 旺財?shù)姆桨福?/span>

旺財在考察了來福的方案后,，發(fā)現(xiàn)每天操作三臺機器真的很麻煩，而且有時有的牛吃不完,，有的牛不夠吃時,，還不能在奶牛之間調(diào)配碾碎了的牧草,。所以旺財有了不同的想法：口罩型碾碎機。

就像在圖上看到的,，旺財給每頭奶牛裝配了一臺口罩碾碎機,，所以三頭牛完全可以在一個槽里吃草了，在吃之前口罩會自動把牧草碾碎成適合該牛食用的類型,。旺財就輕松了,，他每天只需要割割草就行了。

但是旺財被鄙視了,？,？？

是的,，被來福鄙視了,。來福觀察后發(fā)現(xiàn)，旺財?shù)目谡帜胨闄C的效率很低（因為比較小嘛）,。阿圓食量大,，吃來福的圓圓碾碎機的食物一個小時就飽了，但是戴著口罩吃的時候要吃十個小時,！所以來福認為旺財?shù)目谡帜胨闄C雖然省事,，但只能喂喂小牛，完全不適合食量大的牛,。

旺財也覺得這樣做有問題，但他不想回到來福方案上,，他改進了口罩方案：牧草預切割機,。

呵呵，看到預切割做了什么嗎,？它把牧草割得小了一些,，所以需要口罩碾碎機做的事情就少多了。（當然口罩碾碎機也要作適當改進適合預切割后的牧草,，所以圖上用藍色表示）阿圓以前用口罩不是要吃十個小時嗎,，現(xiàn)在兩三個小時就可以了。

編譯器與解釋器

好的,，謝謝你有耐心看到這里,，經(jīng)過上面那個不太恰當?shù)睦樱嘈拍阋呀?jīng)相當?shù)暮苛?。那么我們試著回到技術(shù)方面來,。

在上面的例子中

牧草 ＝ 我們的各種編程語言，C/C++/C#, Java, Pascal, PHP, Python, Perl, Java Script等等

切割機 ＝ 各種編譯器

奶牛 ＝ 各種CPU（不要告訴我Intel和AMD哦）,，比如x86,，ARM,，MIPS等等

那你應該知道了為什么奶牛會有吃不同形狀牧草的嗜好了，這個奇怪的比喻是為了表示不同的CPU接受的不同的機器語言,。

對應上面的奶牛圖,，編譯器的圖是這樣的

源代碼被編譯成機器碼，在CPU上運行,。

而解釋器是這樣的

用解釋器很方便,，只需要直接“運行”就好了，不用像C那樣有編譯鏈接的工序,。

為什么說這些語言是跨平臺的,？因為你寫了程序以后，如果這個平臺上有這種語言的解釋器,，只需要拿到這個平臺上直接運行就可以了,。你可以理解為：解釋器是在“一邊編譯，一邊運行”,，它只是把以前程序員手工做的編譯過程放在了運行程序的時候進行,。

為什么我們一般說解釋器的效率比較低？你也可以想象的是,，一段程序在解釋器中運行時可能會被編譯多次,，因為每次運行到這段程序時，都會重新編譯一次,，這樣的開銷是很大的,。

所以誕生了Java，C#這樣的預編譯語言：

在運行之前,，需要手動把源代碼編譯成中間代碼（Java里叫字節(jié)碼）,，然后在解釋器中執(zhí)行。

這種架構(gòu)避免了上面純解釋器中編譯源代碼的開銷,，所以相對會有效率一些,。

但 是我不能騙你們，其實我畫在純解釋器中的Python,，Perl,，PHP可能都不會是真的純解釋執(zhí)行的，這樣實在是太沒有效率,。Python在運行時會生 成pyc的二進制臨時文件,，看起來很像是預編譯的結(jié)果。只有JavaScript這種真的不會寫得太長的語言（Ajax請原諒我）才會采用純解釋的運行方 式,。