及时编译总是更快？

Question

在 Stack Overflow 上向所有编译器设计者致以问候。

我目前正在从事一个项目，该项目的重点是开发一种用于高性能计算的新脚本语言。源代码首先被编译成字节码表示。字节码然后由运行时加载，它对其执行积极的（可能是耗时的）优化（这比大多数“提前”编译器所做的更进一步，毕竟这是整个过程中的重点。项目）。请记住，此过程的结果仍然是字节码。

然后字节码在虚拟机上运行。目前，这个虚拟机是使用直接跳转表和消息泵来实现的。虚拟机通过指针运行字节码，在指针下加载指令，在跳转表中查找指令处理程序并跳转到其中。指令处理程序执行适当的操作，并最终将控制权返回给消息循环。虚拟机的指令指针递增，整个过程重新开始。我能够用这种方法实现的性能实际上非常惊人。当然，实际指令处理程序的代码又是手动微调的。

现在大多数“专业”运行时环境（如 Java、.NET 等）都使用即时编译在执行前将字节码转换为本机代码。使用 JIT 的 VM 通常比字节码解释器具有更好的性能。现在的问题是，由于解释器所做的基本上就是加载一条指令并在跳转表中查找跳转目标（记住指令处理程序本身是静态编译到解释器中的，所以它已经是本机代码），是否会使用即时编译会提高性能还是会降低性能？我真的不能想象解释的跳转表降低性能是大大弥补了使用 JITer 编译该代码所花费的时间。我知道 JITer 可以对代码执行额外的优化，但在我的情况下，在执行之前已经在字节码级别执行了非常积极的优化。你认为我可以通过用 JIT 编译器替换解释器来获得更快的速度吗？如果是这样，为什么？

我知道同时实施方法和基准测试将为这个问题提供最准确的答案，但如果有明确的答案，可能不值得花时间。

谢谢。

Answer 1

答案在于单字节代码指令复杂度与跳转表开销的比率。如果您正在对大型矩阵乘法等高级操作进行建模，那么一点点开销将是微不足道的。如果您要递增单个整数，那么这当然会受到跳转表的显着影响。总体而言，平衡将取决于该语言所用于的时间紧迫任务的性质。如果它是一种通用语言，那么一切都以最小的开销更有用，因为您不知道在紧密循环中将使用什么。要快速量化潜在的改进，只需对执行一些简单操作（但无法优化掉的操作）的一些嵌套循环与等效的 C 或 C++ 程序进行基准测试即可。