【问题标题】:C loop unrolling optimization performanceC循环展开优化性能
【发布时间】:2018-10-19 12:16:06
【问题描述】:

首先:我知道循环优化是什么以及它是如何工作的,但我发现了一个我无法解释结果的案例。

我创建了一个素数检查器,它对从 2 到 n - 1 的每个数字进行取模,因此没有算法优化。

编辑:我知道可以更有效地计算素数,但这只是循环行为的一个示例。

然后我创建了一个正常和优化的版本:

#include <stdlib.h>
#include <stdio.h>

typedef unsigned long long natural;

int is_prime(natural n){
    int is_not_prime = 0;

    for(natural i = 2; i < n; i += 1){
        is_not_prime |= !!!(n % i);
    }

    if(is_not_prime){
        return 0;
    }else{
        return 1;
    }
}

//__attribute__((noinline))
int is_prime_opt(natural n){
    int is_not_prime = 0;

    for(natural i = 2; i < n; i += 8){
        is_not_prime |= !!(
                !(n % i) |
                !(n % i + 1) |
                !(n % i + 2) |
                !(n % i + 3) |
                !(n % i + 4) |
                !(n % i + 5) |
                !(n % i + 6) |
                !(n % i + 7));
    }

    if(is_not_prime){
        return 0;
    }else{
        return 1;
    }
}

int main(int argc, char *argv[])
{
    if(argc != 2)
        return 1;

    natural check = atoi(argv[1]);

    if(is_prime(check)){
        printf("%llu is prime\n", check);
    }

    return 0;
}

我使用 gcc 编译代码并使用 -O3 强制编译器完成所有优化。由于在编译时不知道迭代次数,我希望编译器不会展开循环。 我创建了第二个版本,它在 8 个数字块中执行相同的操作。由于某些输入不能被 8 整除,因此循环在最坏的情况下会计算 7 个项目,但这是可以接受的。

我使用valgrind --tool=callgrind ./prime 100000000 检查了循环,输出如下:

未优化:

==983== Callgrind, a call-graph generating cache profiler
==983== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==983== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==983== Command: ./prime 100000000
==983== 
==983== For interactive control, run 'callgrind_control -h'.
==983== 
==983== Events    : Ir
==983== Collected : 1000098047
==983== 
==983== I   refs:      1,000,098,047

优化:

==2307== Callgrind, a call-graph generating cache profiler
==2307== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==2307== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==2307== Command: ./prime 100000000
==2307== 
==2307== For interactive control, run 'callgrind_control -h'.
==2307== 
==2307== Events    : Ir
==2307== Collected : 137598072
==2307== 
==2307== I   refs:      137,598,072

我预计循环速度会快 10-20%,因为我节省了 1/8 的跳转和检查。此外,分支预测应该已经加快了第一个版本的速度,因为除了最后一个跳转之外的所有版本都朝着相同的方向发展。

我不清楚为什么它快 7 倍以上? 因为我用 100M 调用它,所以我希望它至少执行 100M - 3 (w/o 0, 1, n) 模数或求反运算,但它每个元素只需要 1.37 个周期(并且 afaik 模数不是便宜的手术)。

【问题讨论】:

  • 是不是故意不把||| 一样快捷方式?你可以试试||,看看优化器是否真的没有在幕后做这件事?
  • 您是否查看了生成的代码以了解它的实际作用?
  • 您的情况是i &lt; n而不是!is_not_prime &amp;&amp; (i &lt; n)的任何特殊原因?
  • !(n % i + 1) 好像是奇数,n%i 会产生0 或正数,加上1 会导致正数,计算! 会导致0。所以每个!(n % i + XX) 都可以优化掉。
  • 你的 CPU 和架构是什么? x86 是一个相对缺乏寄存器的 CPU,即使在 64 位模式下也是如此。如果我正确地阅读了您的问题,那么您的单循环实现优于手动展开的实现。展开循环会增加所需的寄存器数量。我敢打赌,如果您检查编译器发出的实际指令,展开的实现会有很多 register spills and fills

标签: c loops optimization loop-unrolling


【解决方案1】:

!(n % i + 1) 好像是奇数,n%i 会产生0 或正数,加上1 会产生正数,计算! 会产生0。所以每个!(n % i + XX) 都可以优化掉。

应该是!(n % (i + 1))

【讨论】:

    【解决方案2】:

    这个贴出的代码:

    int is_prime(natural n){
        int is_not_prime = 0;
    
        for(natural i = 2; i < n; i += 1){
            is_not_prime |= !!!(n % i);
        }
    
        if(is_not_prime){
            return 0;
        }else{
            return 1;
        }
    }
    

    在找到答案建议后正在执行许多循环

    int is_prime(natural n)
    {
        for(natural i = 2; i < n; i += 1)
        {
            if( !(n&i) )
                return 0;
        }
        return 1
    }
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-12-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多