什么静态编译器可以优化JIT不能？

Question

是否存在静态编译器在JIT无法优化的情况下的示例？

例如，.NET JIT无法完成C ++编译器的一些优化？

Answer 1

无。证明：接受任何编译器并将其用作JIT。 QED。

但是，JIT的执行时间有限，因此在那里进行复杂的优化是不可接受的。

Answer 2

This answer有一个JIT优化器使用的优化和策略列表。它们与本机代码优化器的作用并没有根本的不同。

抖动中的一个限制是它不能花费大量时间来分析代码。它燃烧的每毫秒都会影响程序的响应性。两种策略有帮助。程序集可以由ngen.exe预先安装，所有.NET程序集都是如此，并且对自己的程序集执行相同的操作也是明智之举。只要它们“大”，与在磁盘上查找和加载.ni.dll文件相比，可能花费更少的时间来查找代码。

抖动在方法开始执行之前按需编译代码。随着时间的推移，这往往会分摊成本，这与在响应性很重要的人类时间运行的代码相关。

值得注意的一个细节是抖动可以利用核心特定指令。这是一个基本消失的边缘，核心现在并没有那么不同。但它很容易在x64操作系统上生成64位代码，而不会做任何特殊的事情。

一个典型的数字是，jitted机器代码的效率是本机预编译代码的85％。拿几块大块的盐来说，源代码的质量和性质总是第一位的。

Answer 3

一般情况下，静态编译器无法做到JIT编译器无法做到的事情 - 因为JIT编译器具有等效静态编译器所具有的所有信息 - 以及更多。 JIT编译器有一个巨大的优势 - 它知道代码运行的确切环境。

由于语言功能，C ++中可能存在不在C＃中的特定优化。但同样，它更可能是相反的方式 - 例如，在没有指针的情况下，更容易推理C＃。

在C＃中查看优化时，大部分优化都发生在从C＃到IL的转换中，而不是JIT。

Answer 4

静态编译器提前运行良好，而JIT在代码执行前不久完成。静态编译器有更多的时间来运行，因此需要很长时间才能执行的优化通常由静态编译器完成，而不是由JIT编译器完成。原则上，JIT 可以进行这些优化，但执行它们所需的额外时间使它们变得不切实际。

---

另一方面，现代JIT在某些情况下可以对代码做出更积极的假设（产生比静态编译器更快的代码），因为如果这些假设，它可以选择回退到不太优化的版本。结果是不正确的。

Answer 5

这里的主要问题是运行时和资源。编译Visual Studio需要61个小时 - 我甚至不知道他们有什么样的构建机器。但是，JIT必须以机器的实际资源的一小部分运行，并且以毫秒为单位运行。他们无法以强烈的方式进行优化。