Question

我正在浏览CIL Spec。在附录中，它讨论了“不精确的错误”，这意味着用户可以指定可以放宽空引用异常的确切顺序等。附录讨论了JITer可以用来改善性能的各种方式。

引起我注意的一个特定小节：

F.5.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设置为从other sources提取的一些int代码，但是生成的x86程序集没有区别。

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

所以我很好奇是否有关于该附录的一些历史（以及第12.6.4节“优化”，其中也讨论了这一点）我错过了。如果主要供应商实际上没有实现它，为什么它在标准中呢？微软是否有计划在未来开展这项工作？

Answer 1

所以我很好奇是否有关于该附录的一些历史（以及第12.6.4节“优化”，其中也讨论了这一点）我错过了。如果主要供应商实际上没有实现它，为什么它在标准中呢？微软是否有计划在未来开展这项工作？

我怀疑这是专门提供的选项，允许在某些时候实现它，而不会破坏实现或需要更改规范。

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

这是因为NoStringInterning是目前唯一支持的选项。由于C＃中的枚举是可扩展的（它只是一个基础整数类型），因此可以轻松扩展运行时的未来版本以支持其他选项。

请注意，Microsoft有suggestions on the VS UserVoice个网站可以在此区域进行改进。

Answer 2

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

SIMD是一个问题，它有一个非常难的变量对齐要求。至少在写入x86抖动的时候，尝试对错误对齐的变量应用SIMD指令会产生硬总线故障。不太确定x64抖动写入时的最新技术水平但今天它仍然非常昂贵。 x86抖动不能比4字节对齐更好，x64不能比8更好。可能需要下一代128位内核才能使16字节对齐真正使其有效。我没有屏住呼吸：）

“不精确的故障”和SIMD

2 个答案: