我知道ASM基本上是最快的,但是HLL比ASM慢抽象的原因是什么?抽象的意思是,例如在C ++中你有一个类,需要存储关于类中存储的内容,它来自什么,私有/公共访问器和其他东西的数据。编译此代码时,是否有实际的汇编代码可以确定有关该类的信息?就像CPython是基于C构建的那样,在运行时运行时比C更多的抽象和指令。我说的是什么?我想我已经回答了我自己的问题,但我想从一个比我更有经验的人那里得到答案。
编辑:我理解Python被解释但如果编译它会不会比C慢?答案 0 :(得分:5)
这是一个广泛的问题。
从根本上说,编译语言就像ASM一样被翻译成机器指令(操作码)(ASM也是一个抽象层)。一个好的编译器实际上可能超出平均ASM编码器的结果,因为它可以检查大量代码并应用大多数程序员无法手动执行的优化规则(订购最佳执行指令等)。
在这方面,所有编译语言都是“平等的”。但是,有些人比其他人更平等。编译代码的执行情况从根本上取决于编译器的优异程度,更不用说特定语言了。某些功能(如虚拟方法)会导致性能下降(上次我检查虚拟方法是使用函数指针表实现的,尽管我的知识可能已在此处注明日期。)
解释语言在程序执行时从根本上检查人类可读的语言,在程序运行时期间基本上需要等同于编译和执行阶段。因此,它们几乎总是比编译的对应物慢一些。智能实现将逐步解释执行代码的部分(以避免解释从未命中的分支),并缓存结果,以便只将代码的一部分解释一次。
还有一个中间立场,其中人类可读的语言被翻译成伪代码(有时称为P代码或字节代码)。这样做的目的是使代码的紧凑表示能够快速解释,并且可以在许多操作系统中移植(您仍然需要一个程序来解释每个平台上的P代码)。 Java属于这一类。
答案 1 :(得分:2)
实际上,你的前提不一定是真的。
许多人会说优秀的优化编译器可以胜过手工编码的汇编。
其他人可能会说像Java和.Net那样的即时编译器可以利用运行时启发式算法,因此优于任何静态编译的代码。
在编译器和解释器中,我向你保证不必然有任何相关性 介于语言高级和运行时效率之间。 非常高级语言 可以生成极其高效的代码。
恕我直言......
答案 2 :(得分:1)
根据经验,语言越抽象(通常对程序员来说更方便),它就越慢。 C编译器将生成汇编代码,这就是它与系统相关的原因。像Java这样的语言在虚拟机中运行,虚拟机本身就是一个已编译的程序。但这种抽象通常会使事情变慢。
但这并不是说没有例外。就像paulsm4所说的那样,高级语言最终会比低级语言更有效,因为它们可以利用各种模式(我不知道细节)。
答案 3 :(得分:1)
当你谈到语言的速度时,首先要问的是它是编译还是解释。 解释语言通常比编译语言慢一到两个数量级。
但这可能无关紧要。解释性语言可能有其他优点,你想用它做什么可能不需要炫目的速度 - 如果它有速度,你就不会注意到。
例如,命令行shell语言都被解释(据我所知),这没关系,因为它们只执行一个耗时的操作系统命令,然后执行下一个操作系统命令。在命令之间刮胡子的循环永远不会被注意到。
即使在快速编译的语言中,只是将一个库调用连接到另一个库调用的程序,只需要在它们之间进行一点原始数据操作,从语言的速度中获得的好处很少,因为所有的时间都是在地下室度过了。
语言速度很重要的地方在于地下室的东西。 如果您只编写更高级别的代码,则编译代码的速度很小。 重要的是 lot ,如果您的代码调用的是从属程序,而不是实际需要的。 编译器无法帮助您。 Here's an example of how to fix that kind of problem.