JIT 热重编译答案

【问题标题】：JIT hot recompilationJIT 热重编译
【发布时间】：2013-09-04 18:21:28
【问题描述】：

我的问题与this one 类似，但有所不同，因为我不询问 EditAndContinue。

我读到存在热重新编译。我的意思是，例如我们有这样的代码

if (a > 0 && b >0 && c > 0 && d > 0)

我们假设我们有一个监控可执行文件和启动 JIT 的环境（例如 CLR）。所以这个环境看到d > 0这种情况很少见（我们在编译时不知道a b c或d的实际值，我们只能在运行时收集一些统计信息）。所以它可以像这样重新编译它

if (d > 0 && a > 0 && b >0 && c > 0)

所以我们得到了优化，因为首先检查了最不可能的条件。那么这个热重编译究竟是怎么命名的呢？它是如何以及在哪里工作的？

【问题讨论】：

您是否正在寻找一个现有的优化框架来完成它或检查如何实现这种优化？
这是关于大白雪人的问题，它也有名字但实际上并不存在。分支预测是一种处理器功能。
自 .NET 4.5 起，JIT 不会插入分析工具，因此它无法知道采用单个分支的频率。此功能目前不在 CLR 中。事实上，JIT 总的来说很差。它速度很快，而且没有高质量模式。
@Hans：有时你有很好的答案，有时你表现得像个巨魔。在软件中可以进行多少重新排序，以及在硬件中（由处理器）可以完成多少是有限制的，而软件的限制要大得多。这对于 JIT 来说是一个有用的功能，并且一些用于非 Microsoft 平台的 JIT 编译器实际上会进行在线配置文件引导的重新编译。事实上，我怀疑执行配置文件引导优化的 Microsoft AOT 编译器也会或很快就会这样做。
Alex，巨魔言论不是针对你，而是针对@HansPassant。

标签： .net performance compiler-construction clr jit

【解决方案1】：

可以称为Branch Reordering。

GCC 似乎也支持类似的branch profiling option，这可能会帮助您追踪真实姓名。

-fbranch-probabilities
   After running a program compiled with -fprofile-arcs
   (see Options for Debugging Your Program or gcc), you can compile it a second
   time using -fbranch-probabilities, to improve optimizations based on the number
   of times each branch was taken. When a program compiled with -fprofile-arcs
   exits, it saves arc execution counts to a file called sourcename.gcda for each
   source file. The information in this data file is very dependent on the
   structure of the generated code, so you must use the same source code and the
   same optimization options for both compilations. 

   With -fbranch-probabilities, GCC puts a ‘REG_BR_PROB’ note on each ‘JUMP_INSN’
   and ‘CALL_INSN’. These can be used to improve optimization. Currently, they are
   only used in one place: in reorg.c, instead of guessing which path a branch is
   most likely to take, the ‘REG_BR_PROB’ values are used to exactly determine
   which path is taken more often.

【讨论】：

GCC != .Net JIT。而且有点不一样，我说的不是编译时优化。
否，但优化通常会共享名称，尽管编译器不同。无论如何，死代码消除将被称为相同。