jit - 及时编译总是更快？

Question

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

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

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

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

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

谢谢。

Answer 1

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