首页 文章

为什么用JIT编译器（在app . 性能方面）很难击败AOT编译器？

提问于
浏览 次
32

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

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

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

EDIT:
一些常见的论点：

  • AOT编译器可以花更多时间进行高级优化 -> 如果您运行的服务器虚拟机数天，您可以花费相同的时间，如果不是更长的话 .

  • 字节代码解释有成本 -> 大多数JIT编译器最近都会缓存本地机器指令 .

Yet another edit:
有关具体示例，请参阅此文章：Improving Swing Performance: JIT vs AOT Compilation . 从我从本文中可以收集的内容来看，作者基本上说当没有热点时，运行时信息的优势会减少，因此没有JIT开销的AOT就会获胜 . 但是40％？那不是为了这种情况而调整的吗？或者它是更基本的东西？

performance compiler-construction jit vm-implementation

1 回答

  • 28

    在JIT和AOT（提前）编译之间有一个 definite trade-off .

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

    在需要快速启动或接近实时响应的应用中，这种开销经常变得明显 . 如果机器没有足够的资源进行高级优化，或者如果代码的性质不能得到"aggressively optimized."，那么JIT也没那么有效

    例如，取自the article you linked：

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

    AOT编译器也可以花费尽可能多的时间进行优化，而JIT编译受时间要求（维护响应性）和客户端机器资源的约束 . 因此，AOT编译器可以执行在JIT期间成本过高的复杂优化 .

    另见这个问题：JIT compiler vs offline compilers

    回复于

相关问题