西西河

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

共:💬64 新:
分页树展主题 · 全看首页 上页
/ 5
下页 末页
    • 家园 不知道你们在说什么

      说什么有什么C做不到的.系统都是C写的, 有什么做不到的?

    • 家园 再说几句。现在好像没有严格意义上的解释执行类代码了。

      Java 的VM是混合型的。简单的运算是解释执行,费时的反复进行的操作进行编译,生成本机代码。这部优化工作可以超过C++的静态优化,因为它现在更了解程序运行的特点。而C++/C的编译器在生成本机代码的时候没有这些信息。那么为什么不将所有的Code在运行前编译成本机代码呢。Sun的理论是“磨刀有时会误砍柴功”。编译和优化是有代价的。只有当收获大于开销的时候才有意义。基于这个原理,Hotspot JVM要观察程序的运行一段时间才能决定哪些操作有必要优化。

      微软的CLR是JIT技术。也就是在运行前,MSIL要转化为本机代码。这种技术早期的Java使用过,但后来放弃了。不知道为什么微软使用这种技术。在实施细节上,CLR和JVM也有些不同。

      • 家园 那么C 为什么不能也引进动态的优化技术呢?

        这样Hotspot的部分同样能够被优化,

        而非Hotspot的部分VM是解释执行,

        而C是静态优化过的本机代码

        这样在理论上,解释执行的语言在性能上永远

        不能超过本机编译的代码。

        • 家园 C语言有两个问题阻止了它的进步

          一个是它太老了,那么多的新生语言使得它的生存空间基本只剩下高级汇编这一点了,这样给它做工作的动力就不足了。

          另一个是它的显式指针,显式指针(而不是隐式指针)阻碍了动态优化,因为要修改的东西太多了,成本也太高了。在这一点上,C语言的显式指针显然不如Java/C#的隐式指针好处理。

          相比较而言,传统Basic的动态内存管理现在看来倒成了优点了,真是世事沧桑啊。

          • 家园 老兵的这个Argument比下面的那个好

            呵呵,挑拨一下敌方阵营

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

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

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

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


            本帖一共被 1 帖 引用 (帖内工具实现)
          • 家园 呕, 是吗?

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

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

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

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

        • 家园 C/C++的编译器在编译程序的时候,看到的只是Source code。

          它不可能预见程序在编译后会怎么运行,有什么具体特点,因为那是Run-time的行为。这些信息只有在程序运行的时候,JVM/CLR才可以获得,这是动态优化的根据。

          这不是说C/C++编译器不够聪明。这是由于C/C++这种语言的特点决定的。它避免了很多运行时的开销(C++还有一些运行时的开销,所以C++比C还要慢一些),但同时也失去了运行时的许多有用的信息。一种观点认为基于这些信息的优化技术一定会超过编译时的静态优化。这种理论在局部取得了成功,但就大面积而言,还没有!

          • 家园 评论

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

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

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

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

            • 评论
              家园 这个观点我同意。因为说到最后还是机器代码在执行。

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

              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位长。

          • 家园 这种比较没意义

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

        • 家园 说什么啊.

          什么C不进行优化,..., 问题是这么问的么?

          • 家园 讨论的就是老兵主贴的问题啊

            “解释执行类代码的性能有无可能达到甚至超过本机编译代码 ”

            解释执行的代码有其固有的缺点,但是赞成“解释执行类代码的性能有可能达到甚至超过本机编译代码”者的 Argument是 VM有一些优点,比如动态优化。

            但是这种优点是不是象C语言这样的编译执行方式做不到,或者很难做到的?

            如果答案是否定的,那么上述赞成者的Argument就不太成立。

分页树展主题 · 全看首页 上页
/ 5
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河