“不精确故障”与SIMD

Question

我在看CIL Spec。在附录中，它讨论了“不精确的错误”，这意味着用户可以指定空引用异常等的确切顺序可以放松。附录讨论了JITer可以使用这些方法来提高性能的各种方法。

我注意到一个具体的分节：

F.5.2循环矢量化 循环的向量化通常需要知道两件事：

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

在为可能出错的检查放松的方法中，第1部分通常是假的，因为故障的可能性会导致从每个循环迭代到后续循环迭代的控制依赖。在轻松的方法中，这些控制依赖可以被忽略。在大多数情况下，放松的方法简化了矢量化，允许将检查从循环中吊起。尽管如此，即使这种提升是不可能的，忽略故障所隐含的交叉迭代依赖对于“短向量”SIMD硬件(如IA-32 SSE或PowerPC Altivec )的向量化也是至关重要的。

例如，考虑这个循环：

对于(k = 0；k< n；k++) { xk = xk + yk * sk.a；}

其中s是一个引用数组。空引用的检查不能从循环中吊起，即使在轻松的上下文中也是如此。但放松确实允许成功地应用“展开和堵塞”。循环可以以4的因子展开，以创建聚合迭代，并且将检查悬挂到每个聚合迭代的顶部。

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

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

因此，我很好奇是否有关于附录(以及12.6.4节“优化”，其中也谈到了这个)的一些历史片段，我错过了。如果两个主要供应商都没有真正实现它，那么为什么它会出现在标准中呢？微软是否有计划在未来致力于这方面的工作？

Answer 1

因此，我很好奇是否有关于附录(以及12.6.4节“优化”，其中也谈到了这个)的一些历史片段，我错过了。如果两个主要供应商都没有真正实现它，那么为什么它会出现在标准中呢？微软是否有计划在未来致力于这方面的工作？

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

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

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

请注意，微软在这方面有改进的对VS UserVoice的几点建议站点。

Answer 2

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

SIMD是一个问题，它有一个相当困难的变量对齐要求。至少在编写x86抖动时，试图在错误对齐变量上应用SIMD指令会产生硬总线故障。不太确定在编写x64抖动时，它的技术水平如何，但到了今天，它仍然非常昂贵。x86抖动不能超过4字节对齐，x64不能超过8字节，它可能需要下一代128位核心才能真正实现16字节对齐。我不是为了这个而屏住呼吸的