"；不精确故障”；和SIMD

本文关键字：SIMD 不精确 quot 故障 | 更新日期: 2023-09-27 18:30:14

我正在浏览CIL规范。在附录中，它谈到了"不精确错误"，这意味着用户可以指定null引用异常等的确切顺序可以放宽。附录讨论了JITer可以使用它来提高性能的各种方法。

有一个特定的小节吸引了我的眼球：

F.5.2循环矢量化

矢量化循环通常需要知道两件事：

  1. 循环迭代是独立的

  2. 循环迭代次数是已知的。

在一种针对可能出现故障的检查而放松的方法中，第1部分是经常是错误的，因为故障的可能性会导致控制从每个循环迭代到后续循环迭代的依赖性。在里面作为一种宽松的方法，这些控制依赖性可以忽略。在大多数在某些情况下，宽松的方法通过允许检查吊出一个环。尽管如此，即使不进行这种吊装可能的，忽略故障所隐含的交叉迭代依赖性可能对于"短矢量"SIMD硬件的矢量化至关重要，例如IA-32 SSE或PowerPC Altivec。

例如，考虑这个循环：

for (k = 0; k < n; k++) {
   x[k] = x[k] + y[k] * s[k].a;
}

其中s是引用的数组。检查空引用即使在轻松的环境中，也不能脱离循环。但是松弛确实可以成功地应用"展开和卡住"。这个循环可以按因子4展开以创建聚合迭代，并且检查被提升到每个聚合迭代的顶部。

也就是说，这表明如果JITer使用这些松弛的故障，那么它可以自动将循环转换为SIMD操作。该规范建议您可以使用System.Runtime.CompilerServices.CompilationRelaxations枚举来设置这些松弛错误。但在实际的C#中，枚举只有NoStringInterning选项，没有其他选项。我已经尝试过将System.Runtime.CompilerServices.CompilationRelaxationsAttribute设置为从其他源中提取的一些int代码，但生成的x86程序集没有什么不同。

据我所知，官方的微软JIT并没有实现这一点。我知道Mono有Mono.Simd名称空间，所以我猜它也没有实现这个。

因此，我很好奇是否有我遗漏的关于附录（以及第12.6.4节"优化"，也谈到了这一点）的一些历史。如果两个主要供应商都没有真正实现它，为什么它会出现在标准中？微软是否有计划在未来对此进行研究？

"；不精确故障”；和SIMD

因此，我很好奇是否有我遗漏的关于附录（以及第12.6.4节"优化"，也谈到了这一点）的一些历史。如果两个主要供应商都没有真正实现它，为什么它会出现在标准中？微软是否有计划在未来对此进行研究？

我怀疑这是为了提供一个选项，允许在某个时候实现它，而不破坏实现或需要更改规范。

但在实际的C#中，枚举只有NoStringInterning选项，没有任何其他

这是因为NoStringInterning是目前唯一受支持的选项。由于C#中的enum是可扩展的（它只是一个底层的整数类型），因此可以很容易地扩展未来版本的运行时以支持其他选项。

请注意，VS UserVoice网站上有一些建议，建议微软在这一领域进行改进。

这是必须编写CLI规范的人的负担，他还不知道在抖动中实际实现这一点是否可行。这种情况会在以后发生。

SIMD是一个问题，它有一个非常困难的变量对齐要求。至少在编写x86抖动的时候，试图在未对齐的变量上应用SIMD指令会导致硬总线故障。不太确定x64抖动写入时的技术水平，但今天它仍然非常昂贵。x86抖动不能比4字节对齐做得更好，x64不能比8做得更好。它可能需要下一代128位核心来获得16字节的对齐，以使其真正有效。我没有为此屏住呼吸：）

相关文章：