主题：【原创】总复老兵：解释执行类代码的性能有无可能达到甚至超过本机编译代码 -- Highway
家园 【原创】总复老兵：解释执行类代码的性能有无可能达到甚至超过本机编译代码 长话短说，把我的意思再强调一下。
1。解释执行类代码的性能一定会超过本机编译代码是一个预言。现在还没有做到。将来能否做到，什么时候可以做到我们还需要观察。
2。解释执行和编译执行由于工作性质的不同而呈现出不同的特点。因该说各有长处。就现在而言，编译代码在总体上仍然占有优势。但解释执行性能提升空间还很大，我们有理由对它的前途乐观。由于解释执行类语言在其他方面的优势，微软，SUN已经将开发重点转移了过来。微软的下一代操作系统，数据库系统都是build aronund managed code的。看来微软对managed code是很有信心的。
3。解释执行类代码在某些情况下的优势不能扩大而覆盖整个程序的life cycle。如下面所以，Hotspot能起作用的只是bytecode execution part。这一部分的比重将极大的影响程序的总体性能。所以Java最后成功的地方是back end，而不是最开始“让网络活起来”的Applet以及其他front end (AWT,Swing and so on)技术。Back end application是Java扬长避短的最好场所。
外链图片需谨慎，可能会被源头改4。微软的.NET情况又有些特殊。一方面，managed code比以前纯解释性的语言，如VBA，VBScript(ASP中广泛使用的)有了很大的性能提高，但如果和C++，WINAPI等等相比，性能还有一定的劣势。但看样子微软是把宝押在.NET上了。除了最底层的一些service外，微软今后的目标是尽可能将所有的产品逐步.NET化（所谓的.Netlization）。
5。.NET的优化技术和SUN Java不是很一样。就我看到的资料而言，我觉得Sun的Hotspot在理论上要比微软.NET的JIT更好。当然哪个产品更好是另外一回事。
6。最后说一点，Java和.NET是分别由两个编译语言高手领导创建的。一个是来自Sun的C/C++老兵，一个出身于Borland的Pascal大师。Java和.NET不意味着对编译语言的否定，只是CS向前迈进的又一个脚步。
本帖一共被 1 帖 引用 (帖内工具实现)家园 回复 首先，感谢老轧认真负责的态度。
其次，说明一下我的观点：
一。解释执行类代码的性能在局部的确会超过本机编译代码，但是在全局则基本不可能，因为技术上无法在缺乏充分优化信息的前提下做到优化的效果超过其成本。
二。解释执行类语言之所以在目前占据上风，主要是因为厂商想要跨平台这个商业性因素而不是因为技术上它的确占优势。Sun很清楚Unix/Linux永远不可能占领客户端市场，微软也很明白目前的Windows结构使得它不可能真正占据服务器市场。技术的局限性和资本的贪婪性决定了解释执行类语言会令人吃惊地成为主流。
- 复 回复
家园 I agree I can't imagine that you can deveop some managed code doing some image processing algorithm which is faster than Intel's IPP library which is fully optimaized for Intel's CPU.
- 复 I agree
家园 Why not? At the end of day, it's binary machine code get executed. Managed code will be eventually translated into native machine code. The code can be as efficient (if not any better)as any other compiler generated, IPP library or whatever. Technically, there is no barrier to stop managed code doing so.
Actually, C/C++ is leaning hard from managed world. I will talk about this one next time.
- 复 回复
家园 老兵能否讲讲跨平台的需求为什么会有利于解释型语言 家园 回您的话 理论上讲，我们可以制定严格的编程语言和技术规范，使得以上述规范构造出来的程序在不同的平台上有相同的表现，但是现实中，平台特定的软硬件特点和各个厂商的私利决定了同样的编程语言和技术规范在不同平台和厂商之间总是有着不同的遵守程度，其结果就是互相的不兼容。
这方面的一个例子就是C++，理论上有标准C++，但是现实中每个C++编译器厂商都推出了自己的特定实现，其结果是很难写出一个有用而通用的源程序使得它可以在任何一个C++编译器下都编译通过而且有着相同的运行表现。这意味着C++程序是难以移植的，或者说它的移植成本会比较高。
但是，如果我们能够构造一个虚拟机，使得它能够存在于操作系统之上，并且为应用程序提供一个经过虚拟然后表现一致的运行环境，那么我们就可以在为各个平台的各个操作系统都提供了对应虚拟机的情况下，只提供一个统一版本的应用程序，而这个应用程序在对应虚拟机的帮助下可以运行于不同的平台和不同的操作系统之上。这样做的好处一个是降低了开发成本（我们现在只需要开发一个版本而不是每个支持平台和操作系统组合各自一个版本），另一个好处就是它的移植成本会比较低。
以前曾经存在过使用虚拟机的C++环境（开发环境和运行环境），但是它并没有成为主流，成为主流的是静态编译加上迟后联编的本机编译程序，这样主流的C++应用程序就不可能利用虚拟机来实现跨平台。但是类似Java和.Net语言这样解释性编程语言使用虚拟机来构造自己的逻辑机器，从而在虚拟机的帮助下实现了跨平台。其表现就是对于虚拟机里面的应用程序来说，物理机器的特性都是一样的，至少是基本一样的，虽然肯定可以找出各自的不同之处来。
应该指出的是，不管是Java还是.Net，它的应用程序跨平台的程度都是有限的，但是不管怎么说，它可以跨平台的程度要比本机编译程序强了很多。
虚拟机本来是一个技术魔术，其目的是在物理机器上构造出逻辑机器，以满足特定的要求。但是现实中，对降低开发成本和扩大可移植性的渴望使得它成为了商业上的一个杀手锏。具体的例子就是Borland C++BuilderX，C++的开发环境和编译器居然是用Java写的。
我想以上的说明可以解释为什么跨平台的需求会有利于解释型语言。
本帖一共被 1 帖 引用 (帖内工具实现)- 复 回您的话
家园 谢谢答复， 再问老兵 编译型的语言，其编译器是建立在不同的本机硬件和操作系统之上的，因此
“平台特定的软硬件特点和各个厂商的私利决定了同样的编程语言和技术规范在不同平台和厂商之间总是有着不同的遵守程度，其结果就是互相的不兼容。 比如， “每个C++编译器厂商都推出了自己的特定实现” 。
虚拟机，也是“存在于不同的操作系统之上，并且为应用程序提供一个经过虚拟然后表现一致的运行环境”，是什么东西能够保证这种在不同物理机器和操作系统上构造的“逻辑机器”具有大体相同的特性，不会有同样的，“平台特定的软硬件特点和各个厂商的私利决定同样的虚拟机概念在不同平台和厂商之间总是有着不同的实现和特性，以导致其结果的不兼容 ？
其实这是一个我第一次接触到 JAVA 是跨平台的这个概念就一直有些困惑的问题，从理论上看，这似乎是两个相同的问题，不是很清楚，什么原因使得编译器的实现不容易标准化，而虚拟机的实现比较容易标准化？
家园 这个问题好回答 因为C++编译器是各个厂商自己做自己的，那个标准只是个牌位，因此无法保证它们之间的兼容性。
Sun的Java和微软的.Net都是由一家公司控制的标准，因此标准可以得到严格的遵守。虽然有很多Java厂商，但是Java标准始终掌握在Sun的手中，这是维持Java不分裂的根本原因。
到目前为止，.Net是个只由微软控制的标准，虽然在Unlix/Linux上面存在理论上独立的Mono，但是远不成气候。
我想以上的回答可以解释为什么目前的虚拟机方案可以维持标准的统一了，其实根本原因不在技术，而在于是否政出多门。说到底，技术只是商业牟利的一种手段。
- 复 回您的话
家园 跨平台只是一个方面。解释性语言还有不少其他特点 这两天没时间。等过些天再细细说说吧！