英特尔编译器忽略了大循环?
Large loop was ignored by the intel compiler?
全部:
我有一个非常简单的C测试代码,使用Intel编译器为浮点运算的大循环做一些计时,代码(test.c
)如下:
#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <omp.h>
int main(char *argc, char **argv) {
const long N = 1000000000;
double t0, t1, t2, t3;
double sum=0.0;
clock_t start, end;
struct timeval r_start, r_end;
long i;
gettimeofday(&r_start, NULL);
start = clock();
for (i=0;i<N;i++)
sum += i*2.0+i/2.0; // doing some floating point operations
end = clock();
gettimeofday(&r_end, NULL);
double cputime_elapsed_in_seconds = (end - start)/(double)CLOCKS_PER_SEC;
double realtime_elapsed_in_seconds = ((r_end.tv_sec * 1000000 + r_end.tv_usec)
- (r_start.tv_sec * 1000000 + r_start.tv_usec))/1000000.0;
printf("cputime_elapsed_in_sec: %e\n", cputime_elapsed_in_seconds);
printf("realtime_elapsed_in_sec: %e\n", realtime_elapsed_in_seconds);
//printf("sum= %4.3e\n", sum);
return 0;
}
然而,当我尝试使用 Intel 13.0 编译器编译并运行它时,大循环似乎被忽略了,执行结果为零时序:
$ icc test.c
$ ./a.out
cputime_elapsed_in_sec: 0.000000e+00
realtime_elapsed_in_sec: 9.000000e-06
只有当我打印总和(取消注释第 26 行)时,循环才会真正执行:
$ icc test.c
$ ./a.out
cputime_elapsed_in_sec: 2.730000e+00
realtime_elapsed_in_sec: 2.736198e+00
sum= 1.250e+18
问题是如果我不打印总和值,为什么循环似乎没有执行?
gcc-4.4.7编译器不会出现同样的问题,我猜intel编译器可能做了一些优化,如果没有引用变量,循环可能会被忽略?
系统信息如下:
$ uname -a
Linux node001 2.6.32-642.11.1.el6.x86_64 #1 SMP Wed Oct 26 10:25:23 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
$ icc -v
icc version 13.0.0 (gcc version 4.4.7 compatibility)
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
感谢任何建议!
罗伊
鉴于您观察到打印最终值会减慢它的速度(a),优化器很有可能发现您实际上并不是 在你计算之后对任何东西使用 sum
,所以它优化了整个计算循环不存在。
很久以前,当我们测试我们大学收到的最新 VAX 11/780 机器的性能时,我实际上看到了类似的东西(那里显示了我的年龄)。出于完全相同的原因,它快了百分之几千,新的优化编译器已经决定实际上不需要循环。
要确定,您必须检查程序集输出。我相信这可以通过 icc
来完成,方法是使用 -Fa <asmFileName>
选项,然后检查您使用其名称代替 <asmFileName>
.
的文件
(a)我想到的另一种可能这里好像打了折扣
有可能,鉴于 i
的范围是常量(基于 N
)并且计算在其他方面涉及常量,可能是编译器本身计算了最终的编译时的值,导致简单的常量加载操作。
我见过 gcc
在其 -O3
"insane" 优化级别上做这种事情。
我不考虑这种可能性,因为打印值很可能不会影响此操作。
全部:
我有一个非常简单的C测试代码,使用Intel编译器为浮点运算的大循环做一些计时,代码(test.c
)如下:
#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <omp.h>
int main(char *argc, char **argv) {
const long N = 1000000000;
double t0, t1, t2, t3;
double sum=0.0;
clock_t start, end;
struct timeval r_start, r_end;
long i;
gettimeofday(&r_start, NULL);
start = clock();
for (i=0;i<N;i++)
sum += i*2.0+i/2.0; // doing some floating point operations
end = clock();
gettimeofday(&r_end, NULL);
double cputime_elapsed_in_seconds = (end - start)/(double)CLOCKS_PER_SEC;
double realtime_elapsed_in_seconds = ((r_end.tv_sec * 1000000 + r_end.tv_usec)
- (r_start.tv_sec * 1000000 + r_start.tv_usec))/1000000.0;
printf("cputime_elapsed_in_sec: %e\n", cputime_elapsed_in_seconds);
printf("realtime_elapsed_in_sec: %e\n", realtime_elapsed_in_seconds);
//printf("sum= %4.3e\n", sum);
return 0;
}
然而,当我尝试使用 Intel 13.0 编译器编译并运行它时,大循环似乎被忽略了,执行结果为零时序:
$ icc test.c
$ ./a.out
cputime_elapsed_in_sec: 0.000000e+00
realtime_elapsed_in_sec: 9.000000e-06
只有当我打印总和(取消注释第 26 行)时,循环才会真正执行:
$ icc test.c
$ ./a.out
cputime_elapsed_in_sec: 2.730000e+00
realtime_elapsed_in_sec: 2.736198e+00
sum= 1.250e+18
问题是如果我不打印总和值,为什么循环似乎没有执行?
gcc-4.4.7编译器不会出现同样的问题,我猜intel编译器可能做了一些优化,如果没有引用变量,循环可能会被忽略?
系统信息如下:
$ uname -a
Linux node001 2.6.32-642.11.1.el6.x86_64 #1 SMP Wed Oct 26 10:25:23 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
$ icc -v
icc version 13.0.0 (gcc version 4.4.7 compatibility)
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
感谢任何建议!
罗伊
鉴于您观察到打印最终值会减慢它的速度(a),优化器很有可能发现您实际上并不是 在你计算之后对任何东西使用 sum
,所以它优化了整个计算循环不存在。
很久以前,当我们测试我们大学收到的最新 VAX 11/780 机器的性能时,我实际上看到了类似的东西(那里显示了我的年龄)。出于完全相同的原因,它快了百分之几千,新的优化编译器已经决定实际上不需要循环。
要确定,您必须检查程序集输出。我相信这可以通过 icc
来完成,方法是使用 -Fa <asmFileName>
选项,然后检查您使用其名称代替 <asmFileName>
.
(a)我想到的另一种可能这里好像打了折扣
有可能,鉴于 i
的范围是常量(基于 N
)并且计算在其他方面涉及常量,可能是编译器本身计算了最终的编译时的值,导致简单的常量加载操作。
我见过 gcc
在其 -O3
"insane" 优化级别上做这种事情。
我不考虑这种可能性,因为打印值很可能不会影响此操作。