c# - 为什么代码大小对于 JIT 编译很重要？

Question

假设您正在使用 JIT 编译的语言进行开发。就生成的程序集的代码大小而言，使函数变得非常大是否会对性能产生负面影响？

我问这个是因为我正在查看 Buffer.MemoryCopy 的源代码前几天在 C# 中，这显然是一种对性能非常敏感的方法。看来他们使用了一个大的 switch 语句来专门针对所有字节数 <= 16 的函数，导致 some pretty gigantic生成的程序集。

这种方法在性能方面有什么缺点吗？例如，我注意到 glibc和 FreeBSD尽管 C 是 AOT 编译的，但 memmove 的实现不会这样做，这意味着它不会受到 JIT precompilation 成本的影响。 (这是一个缺点)——对于 C#，JIT 会等到第一次调用才编译方法，因此对于很长的方法，第一次调用将花费更长的时间。

对于 JIT 语言来说，拥有巨大的 switch 语句和增加代码大小(除了我刚才提到的预编译成本)有什么优点/缺点？谢谢。 (我对组装有点陌生，所以请对我放轻松:))

Answer 1

假设是 x86。

获取¹和解码²指令不是免费的。

与数据缓存类似，CPU也有代码缓存；但通常较小，范围从 8 KiB 到 32 KiB。
较短的代码更适合 I-cache，需要更少的内存读取。

然而，获取只是故事的一半。
x86 在解码方面历来存在问题，因为它的(非常)可变长度指令。为了实现快速解码，过去和现在都有各种可遵循的模式和解决方法的限制。

自 Core2 架构以来，CPU 在解码器³之后还有其他指令缓存。
这些缓存保存已解码的指令，绕过了前一阶段的限制和延迟。

只是为了有一个想法，我画了 Haswell 解码单元的草图⁴:

                                             

每个箭头都是数据路径中的一个步骤，通常需要一个时钟。
深色阴影区域是可以找到说明的地方。

缓存距离乱序核心⁵越近，意味着位于底部，所述缓存中的指令到达核心的速度就越快。
但是，缓存越近，它就越小，因此减少代码大小可以提高性能，特别是对于关键循环⁶。

---

我是根据Agner Fog的分析得出这些结论的。 .

---

¹凭内存朗读的行为。
² 将指令转换为微操作的操作。
³ Core2 的预解码器，但仍然如此。
⁴ Peter，欢迎指出错误:)。
⁵ CPU中有效执行指令的部分。
⁶循环意味着经常执行。