主题：【讨论】解释执行类代码的性能有无可能达到甚至超过本机编译代码 -- 老兵帅客
家园 呵呵，其实这已经不是编译的问题了 而是某些功能应该放在那个整个系统的那个部分比较好的问题,
是放在编译器里面，新增加的一层虚拟机里面，还是操作系统里面。
家园 嘿嘿，你这问题越来越有意思了。 你的意思是程序一边执行，一边修改自己。我不敢说不可以，但现在没这样的情况。软件和硬件都没有这样的能力。
如果按照你的做法，今天我在执行Word的时候，发现某种特点（比如我是用中文写作）于是对程序进行了优化，甚至是像你说的“覆盖”。但第二天我写英文，这些特点不适用了，可是我改不回来了，应为原来的image已经被你昨天“覆盖”了。怎么办，哭鼻子？重新安装？
现在一个可行性程序一旦编译成代码发行，他就是他了。你什么时候见微软的DLL，EXE自己在“变”。你想变都不成，那代码是受法律保护的。
家园 没有这么玄乎吧 其实也不是代码在变，也就是代码中多分支，或者说顶多是spawn进程的问题，一些类似动态连结的概念也可以借鉴到这里啊。
不过这里似乎就有一个是使得每一个机器码的程序都带有这种智能，还是干脆让他成不带任何智能的中间码，而让VM带有一个统一的在执行中优化代码的性能，二者哪个更合适些。
老兵提到的可能制造出庞大的二进制代码可能是一个比较好的Argument, 不过，我其实怀疑这种动态优化的可能性是不是真的有那么大？
为什么就不能有一种方式，对于可能优化的部分给出几种可能性，而不能优化的部分直接翻译成为机器码，执行的时候动态地选择最优的运行方式，当然这里操作系统里面可能会要变。
家园 关键不在于技术，而在于是否有足够的动力这样做 例如Basic语言，很长时间它都是解释执行的。其实对于很多的Basic实现来说，做一个编译器并不是很难的事情，问题就在于是否值得做这件事情。
对于C/C++这类语言来说，它们已经有了三十多年（C语言）和二十多年（C++语言）的历史了，语言的文化、观念和实现技术都早已经定型，任何大的修改都会导致严重的争论和兼容性问题。另外，对C++来说，Virtual Table的实现方式已经导致了几派的对立，再增加比RTTI强得多的Meta Data岂不会引发地震？更不要说动态优化了。
一句过分的话，技术是人搞的，很多老的技术是由很老的人搞出来的，他们的思路早已经僵化了，人类社会的争斗在技术世界里同样存在。
家园 很高兴老兵终于同意我的观点了 http://www.cchere.com/article/216162
很多事情都不是技术的问题，而是兼容性，
有时候甚至是political的问题，
网络上这种问题更多，比如HTTP就是一个极没有效率，
性能极低的协议，可是, 谁来改一改这个协议看看？
- 复 @@
家园 不是这么个道理。C/C++的代码一旦编译生成，就是一个二进制文件了。 已经是“死”的了。你怎么“动态优化”？
Java的Byte code和.NET的IL不是机器代码。在运行的时候机器代码及时产生，由于没有一个“死的”机器代码，所以才谈得上动态优化。也就是说程序在执行时，对于一段程序在不同的时间，不同的情况下会形成不同的机器代码。
我们不是在讨论哪种语言更优越，我们在讨论两种运行方式下程序的不同特点。或者说是他们各自的优缺点。希望你明白！
家园 @@ 我不能spawn 一个thread. 自己作DEAMON么?
然后我管理这些thread. 代码死不死, 看你编了.
家园 我给你找一下原文，我记得是在MSDN看到的。 The point being:
Run-time dynamic optimization will eventually surpass compile-time static optimization.
当然这有一个前提，假设C++的优化技术不再提高了。
现在微软在测试一种叫做Profile-based C++优化技术，在大多情况下，可以有30%左右的性能提高。其特点有点像Hot spot JVM，观察程序的具体运行一段时间（尽量模拟典型情况），生成一个Profile,然后根据这个Profile对程序再次进行优化。理论上讲，这就是一种dynamic optimization，这是传统C/C++编译器做不到的。
家园 回复 其实这种技术既不是微软发明的，也不是Sun的独创，当年的Bull机器（记得是Bull7000）就有这样的能力。
这个方法的核心就是对一段时间的执行特点作Profiler，它假定这个执行特点是稳定的，这样可以缩小工作集的大小，从而在一定程度上提高性能。但是其代价就是Profiler的开销，如果Profiler是由硬件完成的，并行可以减少性能损失；而如果Profiler完全靠软件来做，执行特点的稳定程度就成为至关重要的考虑因素了，否则就有可能得不偿失。
在软件中经常存在这样的情况：一个程序中不同的执行路径存在着不同的执行概率。对于概率差距比较明显的程序，上述优化方法的效果将会比较明显，否则意义不是很大。
忽然想起来，PC上似乎也存在一种优化器，可以根据程序的执行特点作Profiler，然后优化原有的.obj文件来生成新的可执行文件，这个思想和上面所讨论的是类似的，可惜那个优化器的名字想不起来了。