c# - .NET JIT 如何优化生成的代码布局？

Question

早在 2009 年我就发布了 this answer关于嵌套 try/catch/finally block 优化的问题。

几年后再次思考这个问题，似乎这个问题可以扩展到其他控制流程，而不仅仅是 try/catch/finally，还有 if/else。

在这些交叉点中的每一个，执行都将遵循一条路径。显然，必须为两者生成代码，但它们在内存中的放置顺序以及在它们之间导航所需的跳转次数会有所不同。

按顺序生成的代码在内存中的布局对 CPU 指令缓存的未命中率有影响。让指令流水线停滞，等待内存读取，确实会破坏循环性能。

我不认为循环 (for/foreach/while) 是一个很好的选择，除非你期望循环有零迭代比它有一些更频繁，因为自然生成顺序似乎是最佳的。

一些问题:

• 可用的 .NET JIT 以何种方式优化生成的指令顺序？
• 这在实践中对通用代码有多大影响？那些非常适合的案例呢？
• 开发人员可以做些什么来影响此布局？使用禁止的 goto 进行处理怎么样？
• 所使用的特定 JIT 对布局有很大影响吗？
• 内联启发式方法是否也在这里发挥作用？
• 基本上与 JIT 的这个方面相关的任何有趣的事情!

---

一些初步想法:

将 catch block 移出行外是一项简单的工作，因为根据定义它们应该是异常(exception)情况。不确定会发生这种情况。

对于某些循环，我怀疑您可以显着提高性能。但总的来说，我认为这不会产生太大影响。

我不知道 JIT 是如何决定生成代码的顺序的。在 Linux 上的 C 中，你有 likely(cond) and unlikely(cond)您可以使用它来告诉编译器哪个分支是要优化的公共(public)路径。我不确定所有编译器都尊重这些宏。

指令排序不同于分支预测问题，在分支预测中，CPU 猜测(靠自己，afaik)将采用哪个分支以启动管道(过于简单的步骤:解码、获取操作数、执行、写回) 在指令上，在执行步骤确定条件变量的值之前。

我想不出任何方法来影响 C# 语言中的这种顺序。也许您可以通过显式地gotoing 标签来对其进行一些操作，但这是否可移植，还有其他问题吗？

也许这就是配置文件引导优化的目的。我们现在或计划在 .NET 生态系统中拥有它吗？也许我会去读一读LLILC .

Answer 1

你说的优化叫做代码布局优化，定义如下:

• 那些在同一个线程中及时执行的代码片段应该在虚拟地址空间中接近，以便它们适合单个或几个连续的缓存行。这减少了缓存未命中。
• 那些在不同线程中及时执行的代码片段在虚拟地址空间中应该是接近的，这样只要没有自修改代码，它们就可以放在一个或几个连续的缓存行中。这比前一个优先级低。这减少了缓存未命中。
• 那些频繁执行的代码(热代码)应该靠近虚拟地址空间，以便它们适合尽可能少的虚拟页面。这减少了页面错误和工作集大小。
• 那些很少执行的代码(冷代码)应该靠近虚拟地址空间，以便它们适合尽可能少的虚拟页面。这减少了页面错误和工作集大小。

现在回答您的问题。

In what ways do the available .NET JITs optimise for generated instruction order?

“指令顺序”确实是一个非常笼统的术语。许多优化会影响指令顺序。我假设您指的是代码布局。

JITters 的设计应该花费最少的时间来编译代码，同时产生高质量的代码。为了实现这一点，他们只执行最重要的优化，因此花时间去做这些事情真的很值得。代码布局优化不是其中之一，因为如果没有分析，它可能没有好处。虽然 JITter 当然可以执行分析和动态优化，但通常有一种首选方法。

How much difference can this make in practice to common code? What about perfectly suited cases?

代码布局优化本身通常可以将整体性能提高 -1%(负一)到 4%，这足以让编译器编写者感到高兴。我想补充一点，它通过减少缓存未命中间接降低了能耗。指令缓存的未命中率通常可降低高达 35%。

Is there anything the developer can do to influence this layout? What about mangling with the forbidden goto?

是的，有很多方法。我想提一下普遍推荐的 mpgo.exe .请不要为此目的使用 goto。这是禁止的。

Does the specific JIT being used make much difference to layout?

没有。

Does the method inlining heuristic come into play here too?

内联确实可以改善函数调用方面的代码布局。这是最重要的优化之一，所有 .NET JIT 都执行它。

Moving catch blocks out of line is an easy job, as they're supposed to be the exceptional case by definition. Not sure this happens.

是的，它可能“容易”，但潜在的 yield 是什么？ catch block 通常很小(包含对处理异常的函数的调用)。处理这种代码布局的特殊情况似乎并不乐观。如果您真的很在意，请使用 mpgo.exe .

I don't know how the JIT decides the order of generated code. In C on Linux you have likely(cond) and unlikely(cond) which you can use to tell to the compiler which branch is the common path to optimise for.

使用 PGO 比使用 likely(cond) 和 unlikely(cond) 更可取，原因有二:

1. 程序员在代码中放置 likely(cond) 和 unlikely(cond) 时可能会无意中犯错误。它实际上发生了很多。在尝试手动优化代码时犯大错误是很常见的。
2. 在整个代码中添加 likely(cond) 和 unlikely(cond) 会降低将来的可维护性。您必须确保每次更改源代码时这些提示都适用。在大型代码库中，这可能是(或者更确切地说是)一场噩梦。

Instruction ordering is distinct from the problem of branch prediction...

假设您在谈论代码布局，是的，它们是不同的。但是代码布局优化通常由真正包含分支统计信息的配置文件指导。硬件分支预测当然是完全不同的。

Maybe I'll go and have a read about LLILC.

在使用 mpgo.exe 时是执行此优化的主流方式，您也可以使用 LLILC，因为 LLVM 也支持配置文件引导优化。但我认为您不需要走这么远。