为什么有些编程语言比其他语言更快？
我知道 ASM 基本上是最快的，但是是什么让 HLL 比 ASM 慢呢？我所说的抽象的意思是，例如在 C++ 中，您有一个类，需要存储有关类中存储的内容、派生自什么、私有/公共访问器以及其他内容的数据。编译此代码时，是否有实际的汇编代码可以用来找出有关该类的信息？就像 CPython 是基于 C 构建的一样，因此在运行时运行的抽象和指令比 C 还要多。我所说的都是真的吗？我想我已经回答了我自己的问题，但我想从我以外更有经验的人那里得到答案。
编辑：我知道Python是解释型的，但如果编译它，它不是仍然比C慢吗？
I know that ASM is basically the fastest one can get, but is what makes HLLs slower than ASM the abstraction? What I mean by abstraction is that for instance in C++ you have a class, data needs to be stored about what is stored in the class, what it derives from, private/public accessors, and other things. When this code is compiled, is there actual assembly code that does work to figure out information about the class? Like CPython is built upon C so there is even more abstraction and instructions to be run at run-time than C. Is any of what I am saying true? I think I have answered my own question but I would like to get an answer from a more experienced individual other than myself.
EDIT: I understand that Python is interpreted but wouldn't it still be slower than C if it were compiled?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一个广泛的问题。
从根本上来说，编译语言就像 ASM 一样被翻译成机器指令（操作码）（ASM 也是一个抽象层）。一个好的编译器实际上可能会胜过普通 ASM 编码器的结果，因为它可以检查大量代码并应用大多数程序员无法手动完成的优化规则（为最佳执行排序指令等）。
在这方面，所有编译语言都是“平等”的。然而，有些人比其他人更平等。编译后的代码的执行情况从根本上来说取决于编译器的性能，而不是具体的语言。某些功能（例如虚拟方法）会导致性能损失（上次我检查虚拟方法是使用函数指针表实现的，尽管我的知识可能已经过时了）。
解释型语言从根本上在程序执行时检查人类可读的语言，本质上需要程序运行时的编译和执行阶段。因此，它们几乎总是比编译后的版本慢一些。智能实现将增量地解释所执行的部分代码（以避免解释从未命中的分支），并缓存结果，以便给定的代码部分仅被解释一次。
还有一个中间立场，即人类可读的语言被翻译成伪代码（有时称为 P 代码或字节代码）。这样做的目的是获得代码的紧凑表示，可以快速解释，但可以跨许多操作系统移植（您仍然需要一个程序来解释每个平台上的 P 代码）。 Java 就属于这一类。
That's a broad question.
Fundamentally, compiled languages get translated into machine instructions (op codes) just as ASM does (ASM is a layer of abstraction, too). A good compiler is actually likely to out-perform an average ASM coder's result because it can examine a large patch of code and apply optimization rules that most programmers could not do by hand (ordering instructions for optimal execution, etc).
In that regard, all compiled languages are created "equal". However, some are more equal than others. How well the compiled code performs depends fundamentally on how good the compiler is, and much less on the specific language. Certain features such as virtual methods incur a performance penalty (last time I checked virtual methods were implemented using a table of function pointers, though my knowledge may be dated here).
Interpreted languages fundamentally examine human-readable language as the program executes, essentially necessitating the equivalent of both the compile and execution stages during program runtime. Therefore they will almost always be somewhat slower than a compiled counterpart. Smart implementations will incrementally interpret parts of the code as executed (to avoid interpreting branches that are never hit), and cache the result so that a given portion of code is only interpreted once.
There's a middle ground as well, in which human-readable language is translated into pseudo-code (sometimes called P-code or byte code). The purpose of this is to have a compact representation of the code that is fast to interpret, yet portable across many operating systems (you still need a program to interpret the P-code on each platform). Java falls into this category.
事实上，你的前提不一定成立。
许多人会说，一个好的优化编译器可以胜过手工编码的汇编。
其他人可能会说，像 Java 和 .Net 那样的即时编译器可以利用运行时启发式方法，从而优于任何静态编译的代码。
在编译器和解释器之间，我向你保证不一定有任何相关性
语言的高级程度和运行时效率之间的关系。 非常高级语言
可以生成极其高效的代码。
恕我直言 ...
Actually, your premise isn't necessarily true.
Many would say that a good optimizing compiler can outperform hand-coded assembly.
Others might say that just-in-time compilers like those for Java and .Net can take advantage of runtime heuristics and hence outperform any statically compiled code.
Among compilers and interpreters, I assure you there is not necessarily any correlation
between how high-level the language is and runtime efficiency. Very high level languages
can produce extremely efficient code.
IMHO ...
根据经验，语言越抽象（通常对程序员来说越方便），速度就越慢。 AC编译器将生成汇编代码，这就是它如此依赖于系统的原因。像 Java 这样的语言在虚拟机中运行，虚拟机本身就是一个已编译的程序。但这种抽象通常会减慢速度。
但这并不是说没有例外。就像 paulsm4 所说，高级语言最终会比低级语言更高效，因为它们可以利用各种模式（我不知道细节）。
As a rule of thumb, the more abstract (and usually the more convenient for programmers) the language is, the slower it will be. A C compiler will generate assembly code, which is why it is so system-dependent. Languages like Java run in a Virtual Machine, which itself is a compiled program. But that abstraction will slow things down in general.
But that's not to say that there aren't exceptions. Like paulsm4 said, high level languages can end up being more efficient than low level ones because they can take advantage of various patterns (I don't know the details).
当你谈论一种语言的速度时，首先要问的是它是编译型的还是解释型的。
解释型语言的运行速度通常比编译型语言慢一到两个数量级。
但这可能并不重要。解释性语言可能还有其他优点，并且您想要用它做的事情可能不需要令人眼花缭乱的速度 - 如果它有速度，您就不会注意到。
例如，命令行 shell 语言都是解释型的（据我所知），这很好，因为它们只执行一个耗时的操作系统命令，然后执行下一个命令。在命令之间切换所减少的周期永远不会被注意到。
即使在快速编译的语言中，仅将一个库调用与另一个库调用结合在一起，中间只进行一点原始数据操作的程序也从语言的速度中获得很少的好处，因为所有的时间都花在了地下室。
语言速度最重要的地方在于地下室的东西。
如果您只编写更高级别的代码，则编译代码的速度并不重要。
重要的是您的代码是否调用了比实际需要更多的从属例程。
编译器无法帮助你。
以下是如何解决此类问题的示例。
When you talk about the speed of a language, the first thing to ask is if it's compiled or interpreted.
An interpreted language will typically run one to two orders of magnitude slower than a compiled language.
But that may not matter. An interpreted language may have other advantages, and what you want to do with it may not require blinding speed - if it had the speed, you wouldn't notice.
For example, command-line shell languages are all interpreted (to my knowledge), and that's fine, because they just execute one time-consuming operating system command followed by the next. Cycles shaved in getting between commands would never be noticed.
Even in fast compiled languages, programs that just tie together one library call followed by another and another, with just a little raw data manipulation in between, are getting little benefit from the speed of the language, because all the time is being spent down in the basement.
Where language speed matters is in that basement stuff.
If you're only writing higher-level code, the speed of compiled code matters little.
What matters a lot is if your code calls subordinate routines more than it really needs to.
The compiler can't help you with that.
Here's an example of how to fix that kind of problem.