即时编译总是更快？答案

【问题标题】：Just in Time compilation always faster?即时编译总是更快？
【发布时间】：2011-03-09 01:05:34
【问题描述】：

向 Stack Overflow 上的所有编译器设计者致敬。

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

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

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

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

谢谢。

【问题讨论】：

如果very aggressive optimization 在编译之前完成，我对此表示怀疑。不过，这取决于您的优化有多好。
计算机科学博士论文的有趣前提。让我们知道结果何时公布。

标签： jit software-design compiler-construction runtime-environment

【解决方案1】：

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

【讨论】：

【解决方案2】：

当您使用解释器时，处理器中的代码缓存会缓存解释器代码；不是字节码（可能缓存在数据缓存中）。由于代码缓存比数据缓存快 2 到 3 倍，因此 IIRC；如果您进行 JIT 编译，您可能会看到性能提升。此外，您正在执行的本机真实代码可能是 PIC； JITted 代码可以避免的事情。

其他一切都取决于字节码的优化程度，恕我直言。

【讨论】：

【解决方案3】：

理论上，JIT 可以更好地优化，因为它具有在编译时不可用的信息（尤其是关于典型的运行时行为）。因此，它可以进行更好的分支预测、根据需要推出循环等。

我确信你的跳转表方法没问题，但我仍然认为与直接的 C 代码相比，它的性能会相当差，你不觉得吗？

【讨论】：

或者另一方面，收集信息然后进行优化的开销可能比当时更快的本机代码更重要......这个理论并不是真的片面 -但您可以从特定问题领域的经验中获得一些统计上的信心。
@Tony：你是对的——通常越简单越好——但这正在转向 VM 实现实践，并且在许多情况下特别适用于长时间运行的程序。
是的。但是，如果收益真的很显着，那么编译语言将放入本机检测代码和已经编译的替代代码，并在必要时自行变异（这当然需要让操作系统允许写入可执行内存页面）。这通常不被追求，这在某种程度上表明，VM 语言更多地将其作为对其预编译对应物的理论上的抨击，而不是它特别有效......？还是我太可疑了？ ;-)
@Tony：我不认为你在关注开发——LLVM 变得越来越重要，并且已经有了 C/C++/Obj-C/Fortran 等的前端。