来福与旺财的养牛场
来福和旺财有一个养 牛场。原本养牛不是一件太难的事情，可是恰恰他俩养的牛都有特别的怪癖。奶牛阿圆只吃切成圆形的牧草，而奶牛阿方和阿三（印度来的？）分别只吃切成正方形 和三角形的牧草。若是来福和旺财拿不和奶牛性格的草去喂食，阿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