compiler-construction - 编译和解释有什么区别？

Question

我刚刚和一位同事进行了一次对话，在哪里谈论 V8 JavaScript 引擎。根据维基百科，

V8 compiles JavaScript to native machine code [...] before executing it, instead of more traditional techniques such as interpreting bytecode or compiling the whole program to machine code and executing it from a filesystem.

其中(如果我错了，请纠正我)“解释字节码”是 Java 的工作方式，而“编译整个程序”将适用于 C 或 C++ 等语言。现在我们想知道、辩论和提出关于差异、相似性的错误断言和假设。为此，我建议询问有关 SO 的专家。

那么，谁能

命名、解释和/或引用所有主要方法(例如预编译与运行时解释)

可视化或提供关于源、编译和解释之间关系的方案

给出#1的主要方法的例子(命名编程语言)。

笔记:

我不是在寻找一篇关于不同范式的冗长乏味的文章，而是一个视觉支持的快速概述。

我知道 Stackoverflow 并非旨在成为程序员的百科全书(而是针对更具体问题的问答平台)。但是，由于我可以找到很多热门问题，从而为某些主题(例如 [1]、[2]、[3]、[4]、[5])提供了百科全书式的观点，我开始了这个问题。

如果这个问题更适合任何其他 StackExchange 站点(例如 cstheory )，请让我知道或标记这个问题以供审核。

Answer 1

由于一个简单的原因，几乎不可能回答您的问题:没有几种方法，它们是一个连续体。这个连续体中涉及的实际代码也相当相同，唯一的区别是事情发生的时间，以及是否以某种方式保存了中间步骤。这个连续体中的各个点(不是一条线，一个级数，而是更多的具有不同角的矩形，您可以靠近这些点)是:

阅读源码

了解代码

执行你所理解的

沿途缓存各种中间数据，甚至将它们持久保存到磁盘。

例如，纯粹的 解释 编程语言 几乎没有 #4 和 #2 有点隐式发生在 1 和 3 之间，所以你几乎不会注意到它。它只是读取代码的一部分，并立即对它们使用react。这意味着实际开始执行的开销很低，但是例如在一个循环中，相同的文本行被读取并再次重新读取。



在矩形的另一个角，传统上是 编译 语言，通常情况下，第 4 项包括将实际机器代码永久保存到文件中，然后可以在以后运行。这意味着您在开始时要等待相对较长的时间，直到整个程序被翻译(即使您只在其中调用一个函数)，但 OTOH 循环更快，因为不需要再次读取源代码。



然后还有一些介于两者之间的东西，例如一个 虚拟机 :为了可移植性，许多编程语言不会编译成实际的机器码，而是编译成字节码。然后有一个编译器生成字节码，还有一个解释器获取这个字节码并实际运行它(有效地“将其转换为机器码”)。虽然这通常比编译和直接转为机器代码要慢，但将这种语言移植到另一个平台更容易，因为您只需移植通常用高级语言编写的字节码解释器，这意味着您可以使用现有的编译器来执行这种“有效地转换为机器代码”，并且不必为您要运行的每个平台制作和维护后端。此外，如果您可以执行一次字节码编译，然后只分发编译后的字节码，这会更快，这样其他人就不必花费 CPU 周期在例如在您的代码上运行优化器，并且只为字节码到 native 的翻译付费，这在您的用例中可能可以忽略不计。此外，您没有分发源代码。

介于两者之间的另一件事是 准时制 编译器(JIT)，它实际上是一个解释器，它以编译的形式保存它曾经运行过的代码。这种“保留”使其比纯解释器慢(例如，增加的开销和 RAM 使用导致交换和磁盘访问)，但在重复执行一段代码时使其更快。它也可以比代码的纯编译器更快，例如只有一个函数被重复调用，因为如果不使用它，它不会浪费时间编译程序的其余部分。

最后，您可以在此矩形上找到其他点，例如通过不永久保存已编译的代码，而是再次从缓存中清除已编译的代码。这样你可以例如在嵌入式系统上节省磁盘空间或 RAM，代价是可能不得不再次编译一段很少使用的代码。许多 JIT 编译器都这样做。