x86_64 - 自修改代码性能答案

【问题标题】：x86_64 - Self-modifying code performancex86_64 - 自修改代码性能
【发布时间】：2015-12-01 09:51:32
【问题描述】：

我正在阅读英特尔架构文档，第 3 卷，第 8.1.3 节；

自修改代码的执行性能低于非自修改代码或普通代码。性能下降的程度取决于修改频率和代码的具体特性。

所以，如果我尊重规则：

(* 选项 1 *) 将修改后的代码（作为数据）存储到代码段中；跳转到新代码或中间位置；执行新代码；

(* 选项 2 ) 将修改后的代码（作为数据）存储到代码段中；执行序列化指令； ( 比如 CPUID 指令 *) 执行新代码；

并且修改代码每周一次，我应该只在下次修改此代码并即将执行时支付罚金。但在那之后，性能应该与未修改的代码相同（+ 跳转到该代码的成本）。

我的理解正确吗？

【问题讨论】：

标签： performance x86-64 self-modifying

【解决方案1】：

简单地尚未缓存的代码与修改已经推测运行中的指令的代码（获取，可能已解码，甚至可能位于调度程序中并重新排序缓冲区）之间存在差异 -订单核心）。写入已经被 CPU 视为指令的内存会导致它回退到非常慢的操作。这就是自修改代码通常的含义。即使 JIT 编译不太难，也可以避免这种减速。只是在全部写入之前不要跳转到缓冲区。

每周修改一次意味着如果你做错了，你每周可能会受到一微秒的惩罚。确实，经常使用的数据不太可能从缓存中清除（这就是为什么多次读取某些内容更有可能使其“粘住”），但是自修改代码管道刷新应该只应用第一个时间，如果你遇到它。之后，正在执行的缓存行处于概率状态。如果第二次运行没有太多干预代码，L1 I-cache（和 uop 缓存）中仍然很热。它在 L1 D-cache 中还没有处于修改状态。

我忘记了http://agner.org/optimize/ 是否谈论自修改代码和 JIT。即使没有，如果您在 ASM 中编写任何内容，您也应该阅读 Agner 的指南。不过，主要“优化 asm”中的一些内容已经过时，并且与 Sandybridge 和后来的 Intel CPU 并不真正相关。得益于 uop 缓存，对齐/解码问题不再是一个问题，而 SnB 系列微架构的对齐问题可能有所不同。

【讨论】：

我为你加了一个 +1（当我有足够的代表时启用）。所以一微秒/周是绝对可以接受的。我已经阅读了 agner 的组装指南。确实非常有价值。当我可以控制并且机器上的流量减少时，应该会更改代码。很高兴认识彼得 :)
@AmyLindsen 如果这个答案有帮助，完全可以不接受我的，所以你可以接受它:) +1
@Mehrdad：你确定吗？我不会让你不高兴，迈赫达德。一个虚拟的吻作为交换，然后呢？ :)
@AmyLindsen：是的，我很确定，哈哈 :)
我在基本地位上苦苦挣扎的是有多少不同的性能类别。例如，您提到“尚未缓存的代码”与“修改已经推测在运行中的指令的代码”，但这些类别似乎并不完整：缓存在 L1I 中的代码怎么样，但不是“在飞行中”？当讨论诸如 SMC 清除和“1K 子页面”之类的事情时，它适用于更严格的“飞行中”案例还是缓存案例？缓存但不在飞行中的情况会受到什么处罚？ uop 缓存级别会发生什么？

【解决方案2】：

“下次”可能不是这样的；缓存算法会考虑第一个之外的访问（不这样做会很幼稚）。然而，在前几次访问后不久，惩罚应该消失了。（“少数”可能是两个或数千个，但对于一台计算机来说，即使是一百万也不算什么。）

即使当前正在执行的代码也曾在某个时间点被写入内存（甚至可能是最近由于分页），所以它最初会受到类似的惩罚，但很快就会消失，所以您不必担心。

【讨论】：

@AmyLindsen：很高兴它有帮助！ :)
将这些 cmets 变成一个答案，因为它们最终成为一个近乎完整的答案。
@PeterCordes：请注意，问题是 “每周修改一次代码”...我不确定她是否打算成为一个 self -修改本身；我认为她通常关心修改已经在缓存/内存中的代码。但是，是的，如果她打算修改当前正在执行的代码，那么你是对的。
@Mehrdad：是的，我想知道同样的事情。好像这是一个每周重新编译和重新执行一次的程序。