主题：【讨论】解释执行类代码的性能有无可能达到甚至超过本机编译代码 -- 老兵帅客

我可以用C编一个自我调剂运行方法的程序.

其实它就 一缺点.. 出个好的大型程序很难, 要搞炸很容易.

其它高级程序的唯一优点就是出东西快, 骗钱快.

只要不是MISSION CRITIQ的, 快点出中上质量的就

能占领市场. 其它都是胡说.

已经是“死”的了。你怎么“动态优化”？

Java的Byte code和.NET的IL不是机器代码。在运行的时候机器代码及时产生，由于没有一个“死的”机器代码，所以才谈得上动态优化。也就是说程序在执行时，对于一段程序在不同的时间，不同的情况下会形成不同的机器代码。

我们不是在讨论哪种语言更优越，我们在讨论两种运行方式下程序的不同特点。或者说是他们各自的优缺点。希望你明白！

C++多了RTTI，Java多了Reflection API，.Net也多了类似的东西。

我想对于特定类型的程序来说，Meta Info和动态优化的确有可能导致比静态优化更好的代码。但是这个结论不具有可推广性，因为随着代码/工作集的扩大，Meta Info的作用会被稀释，而且很多时候动态优化并不能够显著缩小工作集的大小。

说到底，任何代码到最后都是以机器码的方式来运行，因此任何优化最后都不过是机器码的优化。现代静态编译器的优化已经很接近纯手工汇编码了，因此很难想象动态优化可以产生超过这个极限的结果。

也许，一个理论上最好的代码产生方式就是可以做动态分析和优化的多迭代静态编译优化器。假定存在这样一个东西，它将不是HotSpot这类技术所能够比拟的，因为中间码到机器码的转换是后者无法避免的弱点。

已经是“死”的机器代码了。CPU就是按照这个代码一板一眼来运行了。已经是Done deal了，你怎么“动态优化”？

可是这两个级别的Profiler功能是不可能一致的，因为开销和响应时间的要求是截然不同的。

我不能spawn 一个thread. 自己作DEAMON么?

然后我管理这些thread. 代码死不死, 看你编了.

因此是无法作动态优化的。

病毒还二进制讷.

呵呵，挑拨一下敌方阵营

C直接指针的方式，确实可能使得优化器比较难处理。

不过者也是就是 C的缺点，而不是所有编译执行的语言的缺点。

所以理论上，解释执行的方式，在性能上还是无法超过编译执行的方式。

当然啦，现实世界往往同理论是有距离的，如果现在的市场没有一种被广泛接受的编译执行的语言能够比较轻松的吸收VM的一些优点，那么事实上很可能就是VM机胜利赢得这场战争。

• 很高兴老兵终于同意我的观点了

do loop 等结构的并行处理?

寄存器的利用?

内存使用的重新分配?

没听说用什么解释器的.

FORTRAN倒更多.

PARCAL速度都比JAVA快.

谁能有更好的机器代码质量，谁就运行的快。

C/C++静态优化的潜力已经开挖很长时间了，而动态优化才开始不久，还有潜力。

另外，JVM和CLR对内存管理的方法也有潜力可挖。传统上认为C/C++的内存管理（malloc和new）要优于JVM和CLR的，但这个观点已经不是很确定了。在有些情况下，JVM和CLR的效率也很高。并且还有很多意想不到的附带好处。比如你说的C++静态指针的问题。

前俩天看一篇文章，大意是如果.NET的程序遵循一定规范（比如不和COM talkd等等），那么可以将程序从32位.NET环境直接放到64位NET环境，程序不需要任何改动就是64位程序了。C/C++不行，32位的指针就是32位长，你不重新编译他就是32位程序，4byte长的Integer到了64位机器上不会自己变成64位长。

供调试器使用的带调试信息程序不过是多了些中断点和行号信息以便于走单步、看变量和设断点，再多的就没有了。而动态分析/优化所使用的Meta Data实际上是包含了中间语言（某种相对高级语言）的程序流信息，这样可以根据Profiler结果来对中间语言的程序流进行优化，这样优化的效果往往要比直接优化汇编码的效果好得多。