问矩阵/向量运算的GCC优化标志

EN

首先，我不推荐使用-ffast-math，原因如下：

1. 已经证明，在大多数(如果不是全部)情况下使用此选项时，的性能实际上会降低。所以“快速数学”实际上并不是那么快。

1. 此选项打破了浮点运算的严格IEEE遵从性，最终导致不可预测的计算错误累积。

1. 你可能会在不同的环境中得到不同的结果，而且这种差异可能是巨大的。术语环境(在本例中)意味着:硬件、操作系统、编译器的组合。这意味着当你能得到意想不到的结果时，情况的多样性会呈指数级增长。

1. 另一个可悲的结果是，与使用此选项构建的库链接的程序可能需要正确的(符合IEEE标准的)浮点数学，这就是他们的期望被打破的地方，但很难找出原因。

最后，让我们来看看this article.，

出于同样的原因，您应该避免使用-Ofast (因为它包含了邪恶的-ffast-math)。摘录：

-Ofast

无视严格的标准遵从性。-Ofast支持所有-O3优化。它还启用了对所有符合标准的程序都无效的优化。它打开-ffast-math和Fortran特定的-fno-protect-parens和-fstack-arrays。

没有像-O4这样的标志。至少我没有意识到这一点，在GCC的官方文档中也没有它的踪迹。因此，在这方面的最大值是-O3，您应该明确地使用它，不仅是为了优化数学，而且是在一般的发布构建中。

对于数学例程来说，-funroll-loops是一个非常好的选择，尤其是涉及向量/矩阵操作的时候，循环的大小可以在编译时推导出来(结果是由编译器展开)。

我可以再推荐两个标志：-march=native和-mfpmath=sse。与-O3类似，-march=native通常适用于任何软件的发布版本，而不仅仅是数学密集型软件。-mfpmath=sse允许在浮点指令(而不是x87 mode中的堆栈)中使用XMM寄存器。

此外，我想说的是，你不想修改代码来获得更好的性能，这是一个遗憾，因为这是向量/矩阵例程加速的主要来源。多亏了SIMD、SSE Intrinsics和Vectorization，重线性代数代码可以比没有它们的代码快几个数量级。然而，这些技术的正确应用需要深入了解它们的内部结构，并且需要相当多的时间/精力来修改(实际重写)代码。

然而，有一个选择可能适合您的情况。GCC提供了可以通过-ftree-vectorize启用的auto-vectorization，但是由于您使用的是-O3 (因为它已经包含-ftree-vectorize )，所以不需要使用它。重点是，您仍然应该帮助GCC了解哪些代码可以自动向量化。这些修改通常很小(如果需要的话)，但您必须让自己熟悉它们。因此，请参阅上面链接中的可向量化循环部分。

最后，我建议您研究一下Eigen，这是一个基于C++模板的库，它高效地实现了大多数常见线性代数例程。到目前为止，它以一种非常聪明的方式利用了这里提到的所有技术。该接口是纯面向对象的，整洁，并且易于使用。面向对象的方法看起来与线性代数非常相关，因为它通常操作纯对象，如矩阵、向量、四元数、旋转、过滤器等。因此，在使用Eigen进行编程时，您永远不必处理如此低级的概念(如SSE、矢量化等)。你自己，但只享受解决你的特定问题。