为什么很难用JIT编译器击败AOT编译器(就app而言)。表演)？

Question

我认为JIT编译器最终会在编译代码的性能上击败AOT编译器，这是因为JIT固有的优势(只能在运行时使用可用的信息)。一个论点是AOT编译器可以花费更多的时间来编译代码，但是服务器VM也会花费大量的时间。

我确实理解，在某些情况下，JIT似乎确实击败了AOT编译器，但在大多数情况下，它们仍然落后于AOT编译器。

因此，我的问题是，哪些具体的、棘手的问题阻碍了JIT编译器击败AOT编译器？

编辑：

一些共同的论点：

• AOT编译器可以花费更多的时间进行高级优化( -> )，如果您运行服务器VM数天，您可以花费相同的时间，如果不是更长的话。
• 字节码解释已经花费了->大多数JIT编译器缓存本机指令。

的另一个编辑：

有关具体示例，请参阅本文：改进Swing性能: JIT与AOT编译。从本文可以收集到的内容来看，作者基本上是说，当没有热点时，拥有运行时信息的优势就会减少，因此AOT没有JIT的开销，就会获胜。但是有40%？这似乎没什么意义。简单地说，比较过的JIT编译器没有针对这种情况进行调优吗？或者是更基本的东西？

Answer 1

在JIT和AOT (提前)编译之间有一个明确的折衷。

正如您所述，JIT可以访问可以帮助优化的运行时信息。这包括有关它正在执行的机器的数据，启用特定于平台的本机优化。然而，JIT也有将字节代码转换为本机指令的开销。

在需要快速启动或接近实时响应的应用程序中，这种开销常常变得显而易见。如果机器没有足够的资源进行高级优化，或者代码的性质使其不能“积极优化”，那么JIT也就没有那么有效。

例如，摘自你联系的那篇文章

..。在没有明显的性能瓶颈的情况下，我们应该改进什么？正如您可能已经猜到的，配置文件引导的JIT编译器也存在同样的问题。而不是一些热点的积极优化，有大量的“热点”，留下完整的。

AOT编译器也可以花费尽可能多的时间进行优化，而JIT编译则受时间需求(维护响应能力)和客户机资源的约束。由于这个原因，AOT编译器可以执行复杂的优化，在JIT期间代价太高。

请参见以下问题：JIT编译器与脱机编译器

Answer 2

编译和优化是代码、上下文和时间的函数。

原始权衡

AOT可以根据需要使用尽可能多的时间，包括深入的代码分析、对执行平台的了解以及更多的优化提示。缺点是构建速度较慢，可移植代码较少，基于错误假设的优化效果不佳，以及运行时缺乏对反射等高级特性的支持。

JIT更具可移植性，可以在运行时支持高级代码更改，但启动时间更长，资源有限，这意味着有限的优化。

现代发展

最新的JIT编译器速度更快，启动速度更快，同时仍然生成良好的代码，弥补了与AOT在启动延迟方面的大部分差距。

通过多次编译，JIT可以在程序运行时不断优化程序，从而在热身期后获得与AOT相似的性能。JIT可以查看实际使用的代码，使用它的频率，以及其他因素，比如在AOT编译期间无法使用的正在运行的硬件。

--最先进的JIT编译器--可以满足或超过AOT性能，并在更多的情况下维护它。 AOT仍然是快速启动和一致/可预测操作的最佳选择，但不再是获得最佳总体性能的默认选项。