來福與旺財的養牛場
來福和旺財有一個養 牛場。原本養牛不是一件太難的事情，可是恰恰他倆養的牛都有特別的怪癖。奶牛阿圓只吃切成圓形的牧草，而奶牛阿方和阿三（印度來的？）分別只吃切成正方形 和三角形的牧草。若是來福和旺財拿不和奶牛性格的草去餵食，阿X們不但不產奶並且還會鄙視來福和旺財。
因而來福和旺財分別有了本身的主意
來福的方案：
來福發明了三套大型碾碎機：圓圓碾碎機，方方碾碎機和三三碾碎機。天天收割了牧草，就分別放到這三套機器裏碾碎給三頭奶牛吃。可是一旦被碾碎了，這堆草就只能給某一頭牛吃了。很明顯阿方是不會吃給阿圓準備的草的。並且來福天天都要操做這三臺機器，以爲比較麻煩。
旺財的方案：
旺財在考察了來福的方案後，發現天天操做三臺機器真的很麻煩，並且有時有的牛吃不完，有的牛不夠吃時，還不能在奶牛之間調配碾碎了的牧草。因此旺財有了不一樣的想法：口罩型碾碎機。
就像在圖上看到的，旺財給每頭奶牛裝配了一臺口罩碾碎機，因此三頭牛徹底能夠在一個槽裏吃草了，在吃以前口罩會自動把牧草碾碎成適合該牛食用的類型。旺財就輕鬆了，他天天只須要割割草就好了。
可是旺財被鄙視了？？？
是的，被來福鄙視了。來福觀察後發現，旺財的口罩碾碎機的效率很低（由於比較小嘛）。阿圓食量大，吃來福的圓圓碾碎機的食物一個小時就飽了，可是戴着口罩吃的時候要吃十個小時！因此來福認爲旺財的口罩碾碎機雖然省事，但只能喂喂小牛，徹底不適合食量大的牛。
旺財也以爲這樣作有問題，但他不想回到來福方案上，他改進了口罩方案：牧草預切割機。
呵呵，看到預切割作了什麼嗎？它把牧草割得小了一些，因此須要口罩碾碎機作的事情就少多了。（固然口罩碾碎機也要做適當改進適合預切割後的牧草，因此圖上用藍色表示）阿圓之前用口罩不是要吃十個小時嗎，如今兩三個小時就能夠了。
編譯器與解釋器
好的，謝謝你有耐心看到這裏，通過上面那個不太恰當的例子，相信你已經至關的糊塗了。那麼咱們試着回到技術方面來。
在上面的例子中
牧草 ＝ 咱們的各類編程語言，C/C++/C#, Java, Pascal, PHP, Python, Perl, Java Script等等
切割機 ＝ 各類編譯器
奶牛 ＝ 各類CPU（不要告訴我Intel和AMD哦），好比x86，ARM，MIPS等等
那你應該知道了爲何奶牛會有吃不一樣形狀牧草的嗜好了，這個奇怪的比喻是爲了表示不一樣的CPU接受的不一樣的機器語言。
對應上面的奶牛圖，編譯器的圖是這樣的
源代碼被編譯成機器碼，在CPU上運行。
而解釋器是這樣的
用解釋器很方便，只須要直接「運行」就行了，不用像C那樣有編譯連接的工序。
爲何說這些語言是跨平臺的？由於你寫了程序之後，若是這個平臺上有這種語言的解釋器，只須要拿到這個平臺上直接運行就能夠了。你能夠理解爲：解釋器是在「一邊編譯，一邊運行」，它只是把之前程序員手工作的編譯過程放在了運行程序的時候進行。
爲何咱們通常說解釋器的效率比較低？你也能夠想象的是，一段程序在解釋器中運行時可能會被編譯屢次，由於每次運行到這段程序時，都會從新編譯一次，這樣的開銷是很大的。
因此誕生了Java，C#這樣的預編譯語言：
在運行以前，須要手動把源代碼編譯成中間代碼（Java裏叫字節碼），而後在解釋器中執行。
這種架構避免了上面純解釋器中編譯源代碼的開銷，因此相對會有效率一些。
但 是我不能騙大家，其實我畫在純解釋器中的Python，Perl，PHP可能都不會是真的純解釋執行的，這樣實在是太沒有效率。Python在運行時會生 成pyc的二進制臨時文件，看起來很像是預編譯的結果。只有JavaScript這種真的不會寫得太長的語言（Ajax請原諒我）纔會採用純解釋的運行方 式。
zz from http://www.cppblog.com/pengkuny/articles/23106.html