为什么使用JIT编译器难以击败AOT编译器（在应用程序性能方面）？ [英] Why is it hard to beat AOT compiler with a JIT compiler (in terms of app. performance)?

问题描述

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

I was thinking that JIT compilers will eventually beat AOT compilers in terms of the performance of the compiled code, due to the inherent advantage of JIT (can use information available only at runtime). One argument is that AOT compilers can spend more time compiling code, but a server VM could spend a lot of time, too.

我明白JIT在某些情况下似乎击败AOT编译器，但在大多数情况下它们似乎落后。

I do understand that JIT does seem to beat AOT compilers in some cases, but they still seem to lag behind in most cases.

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

So my question is, what are the specific, tough problems that is preventing JIT compilers to beat AOT compilers?

编辑：

一些常见的参数：

Some common arguments:

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

• AOT compilers can spend more time doing advanced optimizations -> If you are running a server VM for days, you can spend the same amount of time, if not longer.
• Byte code interpretation has cost -> Most JIT compilers cache native machine instructions anyways these days.

还有一个编辑：

有关具体示例， 改进摆动性能：JIT与AOT编译。从我从本文可以收集，作者基本上说，当没有热点时，运行时信息的优势减少，因此AOT没有JIT的开销赢。但是40％？这似乎没有多大的意义。是否只是被比较的JIT编译器没有调整这种情况？

Yet another edit:
For a specific example, see this article: Improving Swing Performance: JIT vs AOT Compilation. From what I can gather from this article, the authors are basically saying that when there are no hotspots, the advantage of having runtime information decreases and thus AOT without the overhead of JIT, wins. But by 40%?? That doesn't seem to make a lot of sense. Is it simply that the JIT compiler that was compared wasn't tuned for this situation? Or is it something more fundamental?

推荐答案

JIT和AOT之间有一个确定的折衷提前）编译。

There's a definite trade-off between JIT and AOT (ahead-of-time) compilation.

正如你所说，JIT有权访问可帮助优化的运行时信息。这包括有关其正在执行的机器的数据，启用平台特定的本机优化。然而，JIT还具有将字节代码转换为本地指令的开销。

As you stated, JIT has access to run-time information that can aid in optimization. This includes data about the machine it's executing on, enabling platform-specific native optimization. However, JIT also has the overhead of translating byte-code to native instructions.

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

This overhead often becomes apparent in applications where a fast start-up or near real-time responses are necessary. JIT is also not as effective if the machine does not have sufficient resources for advanced optimization, or if the nature of the code is such that it cannot be "aggressively optimized."

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

...在没有明显的性能瓶颈的情况下，我们应该如何改进？正如你可能
猜测，配置文件引导JIT
编译器也存在同样的问题。

... what should we improve in the absence of clear performance bottlenecks? As you may have guessed, the same problem exists for profile-guided JIT compilers. Instead of a few hot spots to be aggressively optimized, there are plenty of "warm spots" that are left intact.

AOT compilers can also spend as much time optimizing as they like, whereas JIT compilation is bound by time requirements (to maintain responsiveness) and the resources of the client machine. For this reason AOT compilers can perform complex optimization that would be too costly during JIT.

同样可以看到这个问题： JIT编译器与离线编译器

Also see this SO question: JIT compiler vs offline compilers

这篇关于为什么使用JIT编译器难以击败AOT编译器（在应用程序性能方面）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！