C - 有一个简单的循环进行算术计算； profiler 显示这是一个瓶颈。如何加快速度？答案

【问题标题】：C - have a simple loop that does arithmetic calculation; profiler shows this is a bottleneck. How to speed it up?C - 有一个简单的循环进行算术计算； profiler 显示这是一个瓶颈。如何加快速度？
【发布时间】：2011-12-31 19:31:53
【问题描述】：

我在这里的第一篇文章。一个很棒的网站和资源。

我确实搜索了一下，并查看了标题相似的问题，但找不到关于此的具体内容。

我正在尝试从我的 C++ 程序使用的 C 天文计算库中删除任何冗余和膨胀。我运行了一个简单的分析器 (VerySleepy)。

这是分析器显示为使用时间最多的代码（除了 C 库函数 sprintf 等）：

double swi_echeb(const double x, const double* const coef, const int ncf)
{
    int j = ncf - 1;
    double x2, br, brp2, brpp;
    x2 = x * 2.;
    br = 0.;
    brp2 = 0.;  /* dummy assign to silence gcc warning */
    brpp = 0.;

    for (; j >= 0; --j) {                 // <-- 0.39s
        brp2 = brpp;                      // <-- 0.01s
        brpp = br;                        // <-- 0.32s
        br = x2 * brpp - brp2 + coef[j];  // <-- 3.49s ***
    }                                     // <-- 0.14s

    return (br - brp2) * .5;              // <-- 0.06s
}                                         // <-- 0.05s

这个特定的函数深深嵌入到其他函数中，我的程序调用的主要“启动”函数被调用了数千次。

您可以看到 3.49 秒的出色语句远高于所有其他语句时间。我知道有一些方法可以在可能的情况下使用乘除除法来加速 C 算术。但我知道的不多。

喜欢：

将这个语句分成更小的部分会更好吗？：

br = x2 * brpp;

br -= brp2;

br += coef[j];

任何其他想法或批评。我没有编写这段代码，虽然我确实将 const 添加到函数参数中，因为我喜欢 const 正确性。

我以前从未尝试过使用寄存器或其他花哨的技巧来加快速度。有人认为这样的东西可以在这里工作吗？

我知道人们会说，“试试看！”因此，如果它对有类似算术问题的任何人有所帮助，我会并且会更新我得到的信息。

编辑：发布我根据建议测试过的结果

按照从最快到最慢的顺序，这是我目前发现的。 Profiler 非常困倦。编译器是 Visual Studio 2008 Pro Ed。库和我的应用程序的编译选项是：

Debug, C7 format, /O2 /Ob2 /Oi /Ot /Oy /GT /GL /GF /FD /MTd /GS- /Gy /fp:fast /FAs

以下是 Andrew 关于执行“每个循环 4 次迭代”的建议。这是迄今为止最快的。

在函数中花费的总时间（函数中其他语句的时间未在此处显示）= 2.08 秒

for (; index >= 3; index -= 4) {                    // 0.02s
    brp2    = brpp;
    brpp    = br;                                   // 0.02s
    br      = x2 * brpp - brp2 + coef[index];       // 0.25s
    brp2    = brpp;
    brpp    = br;                                   // 0.13s
    br      = x2 * brpp - brp2 + coef[index - 1];   // 0.33s
    brp2    = brpp;
    brpp    = br;                                   // 0.13s
    br      = x2 * brpp - brp2 + coef[index - 2];   // 0.34s
    brp2    = brpp;
    brpp    = br;                                   // 0.14s
    br      = x2 * brpp - brp2 + coef[index - 3];   // 0.42s
}

for (; index >= 0; --index) {                 // 0.03s
    brp2    = brpp;                           // 0.03s
    brpp    = br;
    br      = x2 * brpp - brp2 + coef[index]; // 0.11s
}

第二快的是原始未更改的代码，在函数内总时间为 2.39 秒，同样包括循环外的语句。请注意，这比我原来的帖子少。我最初的帖子是未优化的代码，但由于大家都建议这样做，我的所有测试随后都在 VS08 中尽可能优化：

for (j = ncf - 1; j >= 0; j--) {      // 0.02s
    brp2 = brpp;                      // 0.03s
    brpp = br;                        // 0.07s
    br = x2 * brpp - brp2 + coef[j];  // 2.14s
}

在这段原始代码之后，下一个最快的是 Drew 的想法，即提前设置指针并使用它。 函数内花费的总时间为 2.49 秒，包括循环外语句的时间：

for (; index >= coef; --index) {         // 0.01s
    brp2    = brpp;
    brpp    = br;                        // 0.06s
    br      = x2 * brpp - brp2 + *index; // 2.24s
}

我还尝试混合使用 Andrew 的循环展开和 Drew 的指针使用，但这需要 2.39 秒，与未更改的代码相同。

根据结果，循环展开是我目前使用的方法。

【问题讨论】：

...您在 O3 尝试过优化器？
原型应该是swi_echeb(double x, const double *coef, int ncf)。额外的 const 限定符不会提高代码的 const 正确性，它们只会使阅读代码的人感到震惊和烦恼。
到目前为止，这里有很多好的建议。有展开循环、前向递增索引、使用-O3 优化标志等。你能独立测试每一个的性能并报告每个有多大的影响吗？这种信息对后代非常有用。
@user11234607，请查看此文档：edp.org/work/Construction.pdf 它特定于 Altivec 处理器上的 FFT 实现，但有一些非常有趣的性能调整技巧，适用于编译器和 CPU架构。
@DietrichEpp：同意它们应该在原型中（前向声明）。但是我们只看到定义，并且在局部变量（包括参数）上使用const 是一种很好的做法。

标签： c performance math optimization loops

【解决方案1】：

这似乎是缓存问题，而不是算术问题。

for (; j >= 0; --j) {
    ...
    ... coef[j];
}

您正在这里访问一个数组，并且您正在递减一个索引来这样做。此操作确实会破坏简单循环中固有的缓存友好的局部性。

可以向前计数吗？即，

for (int i = 0; i <= j; i++) {
    ...
    ... coef[i];
}

你的计算是否有效？

【讨论】：

向后存储数组也值得一试 - 这将允许向前读取数组。
不，这种转换不会保留结果，尽管可以反转 coef 数组。但是反向迭代与正向迭代具有相同的局部性，并且缓存行读取次数相同。我想一个非常糟糕的预测缓存算法可能会被混淆并且不能以最佳方式预取，但我对此表示怀疑。
@Ben 现代 i7 使用什么预测算法？上次我检查时，x86 架构的缓存预测器可以向前工作，但不能向后工作。不过，这是五年前的事了。
Crashworks：我不确定。但无论如何，预取只影响大约 1/16 的迭代。一旦您拥有良好的局部性，您可能应该更多地担心缓存一致性等问题而不是预取。
@Crashworks：即使是 Core2 也可以在任一方向上预取多个流。

【解决方案2】：

我要尝试的第一件事是以 4 步进行迭代，即：j+=4（或在您的情况下，j -=4）并半展开循环。这样做的原因是它将帮助编译器进行 SSE 优化并批量访问从主内存到缓存的内存。请注意，如果循环计数不能被 4 整除，您将不得不处理最后几个元素。例如：

// Disclaimer: I have not tested this code!
for (; j >= 3; j -= 4) {              
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef[j]; 
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef[j-1]; 
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef[j-2]; 
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef[j-3]; 
}                          
// if (j % 4) != 0 before the loop operation, 
// handle 1, 2 or 3 remaining elements here

我要尝试的第二件事是在计算之前将 coeff[j] 预加载到寄存器中。这样做的原因是浮点计算是流水线的，这意味着在错误位置的内存访问会对性能产生不利影响。计算本身可能非常快，但可能需要 14 条指令才能将缓存中的数据排队到 FPU。再加上从主存访问它会变得更糟。例如，试试这个（也可以尝试使用和不使用 -=4 展开）

// Disclaimer: I have not tested this code!
register double coef1, coef2, coef3, ceof4;
for (; j >= 3; j -= 4) {           
    coef1 = coef[j];    // Preloads the 4 sequential coeffs from 
    coef2 = coef[j-1];  // main memory to cache (if available)
    coef3 = coef[j-2];  
    coef4 = coef[j-3];  
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef1; 
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef2; 
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef3; 
    brp2 = brpp;                      
    brpp = br;                        
    br = x2 * brpp - brp2 + coef4; 
}

在这种情况下，变量 double x2, br, brp2, brpp, coef1, coef2, coef3, coef4 应该尽可能是寄存器。

最后，使用上面的，你可以应用SSE/SSE2优化吗？确保在 GCC 编译器中启用了此功能（我习惯于 VS，因此等效项是打开模式，关闭调试符号，打开优化，打开 SSE2）并在不附加调试器的情况下对代码进行基准测试。仅此一项就会对性能产生巨大影响。

让我们知道结果。性能调优是反复试验！

祝你好运，

【讨论】：

谢谢。我喜欢尝试所有这些建议并将其写在纸上以供将来参考。我饿坏了，要去买点食物，但今天下午会去。
呵呵，性能调优会让你发疯的！正如其他人所建议的那样，算法改进几乎总是会击败实现调优。您是否可以采取一些措施来减少内存访问或乘法次数（甚至是正在操作的数据集）。从我在您的 Q 的评论中发布的那个 pdf 文件中，请注意他选择了完全适合缓存的实现并展开它们。结果是巨大的进步！
小心...在这两种情况下，您都需要将 j >= 0 替换为 j >= 3，否则您将获得负数组索引。
+1：但有一件事，在优化阶段不会尝试展开循环吗？以最大优化共享编译代码的反汇编是否也有帮助？ ...但预加载也很好
我对现代编译器的经验是，它们在自动生成矢量化 SSE 代码方面相当糟糕（GCC 喜欢使用 scalar SSE 操作，但那不是一回事） .您可能需要将数据组织成四个块，并使用 SSE 内在函数让编译器发出正确的操作码。

【解决方案3】：

我从未尝试过使用寄存器或其他花哨的技巧来加快速度之前起来。有人认为这样的东西可以在这里工作吗？

有一个非常简单的注册技巧，任何人都可以做到。 为最近的 CPU 构建项目。此代码是否需要在 1995 年的计算机上运行？ 2000？ 2005 年？如果程序可以依靠更新的 CPU，它就可以依靠更多的寄存器供其使用。

另外，整数索引是不必要的。您可以改为使 j 成为直接指向感兴趣的 double 的指针。 如果您的优化编译器还没有这样做，这可能会有所不同。

double swi_echeb(const double x, const double* const coef, const int ncf)
{
    const double *j = &coef[ncf - 1];
    // (stuff...)

    while (true) { 
        // (stuff...)

        br = x2 * brpp - brp2 + *j;
        if ( j == coef )
            break;
        --j;
    }  
}

【讨论】：

@Dietmar Kühl：恐怕我不明白你在说什么。此示例将从coef[ncf-1] 迭代到coef[0]，包括在内。
从技术上讲，Dietmar 是对的（指针超前一个是可以接受的，指针前一个是不行的）。可以通过在循环末尾添加if (j==coef) break; 来修复。这可能看起来很难看，但编译器可能会结合这两个循环条件。
@wildplasser：那么，在 C 标准中，无效指针的存在是非法的吗？即使它没有被取消引用/使用？ NULL指针不是无效指针吗？特殊情况？
是的。 valid 指针要么是 NULL 指针，要么指向有效对象（例如数组元素），或者 - 在数组元素的情况下 - 在数组之外。空指针或超越指针不能被取消引用，只能与其他有效指针或空指针常量比较。
我很困惑——不管怎样，这不会以 j == coef 结束吗？或者自从制作这些 cmets 后代码是否已更改？

【解决方案4】：

该代码的主要“问题”是您有一条沿着br 的关键路径。在完全完成前一个迭代之前，您不能开始计算下一个迭代。这也禁止了向量指令：没有什么可向量化的。

我的印象是数字系数总是相当（一位数？），并且运行时间源于对该函数的调用量。

缓解这种情况的一种方法是一次计算评估多个多项式。当然，这取决于您的数据结构的特殊布局：一定程度的系数必须在线性数组中，因此它们可以通过单个向量指令加载。

【讨论】：

【解决方案5】：

好吧，除非有一些特殊问题——比如你的系数数组是否足够大以至于你可以交换？ -- 你可能已经很接近了。

应该尝试 Andrew 的循环展开概念。
一定要确保使用 -O3 进行优化

之后，您将需要查看汇编语言或并行性。

【讨论】：

【解决方案6】：

此操作是前缀求和/扫描的轻微变化。（这是一个 3-op，2-history 扫描）。此处性能的关键限制因素很可能是由交叉循环依赖性引起的序列化（指令管道中的数学操作），因此串行循环展开在这里不太可能有太大帮助。

有一些标准方法可以并行化前缀和（参见维基百科），可以用来加速这一点。即使只有一个线程，您也可以通过将系数数组细分为 4 个子数组，并在每次循环迭代中为每个子数组计算前缀 some - 这四个计算流是独立的，并且将被适当地流水线化，从而大大提高效率通过您的硬件。此外，由于它们是独立的，因此您（或您的编译器，如果幸运的话，但我对此表示怀疑）可以在 x86 上利用 SSE 或 AVX 并行处理数组。

一旦您获得了四个累积结果（结果可能是成对的，因为您有 2 个历史前缀总和），您可以以数学上适合您的序列的方式将它们组合起来。

【讨论】：

+1。根据我的经验，调整后的实现可以提供 100% 的改进，而算法改进可以提供 1000%。
这通常是正确的，但是，在这里，延迟序列化可能会花费 2-3 倍性能，而矢量化包会花费 4 倍，因此您可能会获得 1100%。此外，在回答这些问题时，我通常假设发帖者已经用尽了算法途径。（如果不是，他们应该因为浪费大家的时间而被枪杀:-)）

【解决方案7】：

ncf 的典型值是什么？我问的主要原因是您正在向后迭代coef。非顺序访问没有充分利用缓存。

【讨论】：

NCF 似乎差异很大。有时是 1，有时是 -1555361579，有时是 798114699。它看起来到处都是。如果 NCF 有时非常负面，那么前向遍历是否有意义？
这是顺序访问。相同数量的缓存行未命中。
嘎。必须不断纠正自己。 NCF 只有在它是一个虚拟/未初始化值并且当 coef 也为 NULL 时才为负数。有道理。
@BenVoigt：如果我错了，请纠正我，但Optimizing C++ 确实说明了以地址递增顺序访问内存的使用。请注意，我没有为驴年做过 x86 优化，我主要为嵌入式代码（反向访问预取失败），所以如果我的理解不同步，请原谅我。或者我应该提到预取？
@JSPerfUnkn0wn：现代处理器（甚至许多“嵌入式”处理器）同样擅长在任一方向进行流式预取。

【解决方案8】：

这是分析器找到您期望的情况的情况。看看代码：你有一些循环设置（“哦，运行一次，它不会占用任何东西”）和一个循环。在循环内部，您有两个赋值（“不，它们很便宜”），并且恰好有一行代码执行乘法、两次加法和数组引用。

你不会通过微优化让这个函数运行得更快。处理器实际上是在花时间做你想让函数做的工作——是的，我知道，令人震惊。

最好的选择是提高一两级。如何减少调用此函数的次数？是否多次使用相同的参数调用它，以便您可以缓存结果？有没有地方可以使用更少的系数，从而减少循环运行的次数？

【讨论】：

【解决方案9】：

如果您同意 Drew 的建议，即使用指针而不是数组索引，则可能需要 restrict 指针才能看到任何好处：

...
double *restrict index = coef + ncf - 1;
...
for (; index >= coef; --index) {
    brp2    = brpp;
    brpp    = br;
    br      = x2 * brpp - brp2 + *index;
}

这可能有助于缓存优化，因为编译器可以确定没有人会更改index 指向的值。

另外，我去年发布了一个类似的问题，得到了很多很好的答案。请务必have a look。

【讨论】：

【解决方案10】：

您需要双精度吗？改为浮动可以节省一些时间。

虽然优化器应该可以解决这个问题，但在变量声明中添加显式寄存器提示并没有什么坏处：

register double x2, br, brp2, brpp;

您也可以尝试将 coef 移动到寄存器中：

register double* rc;
rc = coef;
. . .
br = x2 * brpp - brp2 + rc[j];

我不特别了解这种情况，但我看到编译器没有正确优化复合表达式的情况数量惊人。您可以通过将其分解为简单的两分量表达式来增加它做正确事情的几率：

brp2 = brpp;     
brpp = br;
br = x2 * brpp;
br -= brp2;
br += rc[j];

您可能会查看生成的代码，看看是否有任何明显的低效率。

【讨论】：