41

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

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

所以我的问题是，阻止 JIT 编译器击败 AOT 编译器的具体、棘手的问题是什么？

编辑：
一些常见的论点：

  • AOT 编译器可以花费更多时间进行高级优化->如果您运行服务器虚拟机数天，您可以花费相同的时间，如果不是更长的话。
  • 字节码解释是有成本的->现在大多数 JIT 编译器都会缓存本机机器指令。

另一个编辑：
有关特定示例，请参阅本文：提高 Swing 性能：JIT 与 AOT 编译。从我从这篇文章中可以了解到，作者基本上是在说，当没有热点时，拥有运行时信息的优势会降低，因此没有 JIT 开销的 AOT 会胜出。但是40%？？这似乎没有多大意义。仅仅是被比较的 JIT 编译器没有针对这种情况进行调整吗？或者它是更基本的东西？

4

2 回答 2

35

JIT 和 AOT（提前）编译之间存在一定的权衡。

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

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

例如，取自您链接的文章：

...在没有明显的性能瓶颈的情况下，我们应该改进什么？您可能已经猜到，配置文件引导的 JIT 编译器也存在同样的问题。没有几个热点需要积极优化，而是有很多“热点”保持不变。

AOT 编译器也可以根据需要花费尽可能多的时间进行优化，而 JIT 编译受时间要求（以保持响应性）和客户端计算机资源的约束。出于这个原因，AOT 编译器可以执行复杂的优化，这在 JIT 期间成本太高。

另请参阅此 SO 问题：JIT 编译器与离线编译器

于 2011-09-29T01:16:49.427 回答
1

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

原始权衡

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

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

现代发展

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

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

最先进的 JIT 编译器可以达到或超过 AOT 性能，并在更多场景下保持。AOT 仍然是快速启动和一致/可预测操作的最佳选择，但不再是最佳整体性能的默认选项。

于 2020-10-08T19:07:51.880 回答