手动SIMD代码可承受性

Question

我们正在运行一个计算密集程度很高的项目,现在我们让编译器进行SSE优化.但是,我们不确定我们是否获得了代码的最佳性能.

我的理解是,我的理解是广泛的,但我没有找到很多关于此的建议:编写手工SIMD代码是否可以负担得起,或者换句话说值得努力？

在这里,可负担性意味着对成本效益的粗略估计,例如speedup / development_time,或在项目开发背景下合理的任何其他措施.

减少范围:

• 我们分析了代码,我们知道计算是最重要的部分
• 我们有一个C++代码,可以很容易地使用Boost.SIMD和类似的库
• 负担能力不应该考虑代码的可读性,我们假设我们对SSE/AVX充满信心
• 代码目前是多线程的(OpenMP)
• 我们的编译器是英特尔的 icc

Answer 1

非常同意Paul R,并且只是想在大多数情况下补充说IMO内在函数/ asm优化是不值得的.在大多数情况下,这些优化是营销驱动的,即我们在特定平台上榨取性能只是为了获得(在大多数情况下)更好的数字.

如今,在asm中重写C/C++代码几乎不可能达到一个数量级的性能.在大多数情况下,这是保罗已经注意到的内存/缓存访问和方法/算法(即并行化)的问题.

您应该尝试的第一件事是使用硬件性能计数器(使用免费的"perf"工具或Intel VTune)分析您的代码,并了解真正的瓶颈.例如,计算期间的内存访问实际上是最常见的瓶颈,而不是计算本身.因此,这样的代码的手动矢量化没有帮助,因为CPU无论如何都会在内存上停顿.

这样的分析总是值得的,因为您更好地理解您的代码和CPU架构.

您应该尝试的下一件事是优化您的代码.有多种方法:优化数据结构,缓存友好的内存访问模式,更好的算法等.例如,在结构中声明字段的顺序在某些情况下可能会对性能产生重大影响,因为结构可能有漏洞和占用两行缓存而不是一行.另一个例子是虚假共享,当你在CPU之间ping相同的缓存行时,简单的缓存对齐可能会给你一个更好的性能.

这些优化总是值得的,因为它们也会影响您的低级代码.

然后你应该尝试帮助你的编译器.例如,默认情况下编译器矢量化/展开内部循环,但可能更好地矢量化/展开外部循环.你使用#pragma提示做到这一点,有时值得付出努力.

您应该尝试的最后一件事是使用intrinsics/asm重写已经高度优化的C/C++代码.可能有一些原因,例如更好的指令交错(因此您的CPU流水线总是很忙)或使用特殊的CPU指令(即加密).合理的内在函数/ asm使用的实际数量可以忽略不计,并且它们总是依赖于平台.

所以,没有关于你的代码/算法的进一步细节,很难猜测你的情况是否有意义,但我敢打赌.更好地将精力用于分析和独立于平台的优化.如果你真的需要计算能力,最好看看OpenCL或类似的框架.最后,投资于更好的CPU:这种投资的效果是可预测和即时的.