【发布时间】: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 < n而不是!is_not_prime && (i < 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