为什么用JIT编译器(就应用程序性能而言)难以击败AOT编译器？

Question

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

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

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

编辑:
一些常见的论点:

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

另一个编辑:
有关具体示例,请参阅此文章:改进Swing性能:JIT与AOT编译.从我从本文中可以收集的内容来看,作者基本上说当没有热点时,运行时信息的优势会降低,因此没有JIT开销的AOT就会获胜.但是40%？这似乎没有多大意义.仅仅是因为这种情况没有调整被比较的JIT编译器吗？还是更基本的东西？

Answer 1

JIT和AOT(提前)编译之间存在明确的权衡.

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

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

例如,取自您链接的文章:

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

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

另请参阅此问题:JIT编译器与脱机编译器