intel 컴파일러에서 큰 루프가 무시 되었습니까?

내가 부동 소수점 연산을위한 큰 루프에 대한 몇 가지 타이밍을 할 인텔 컴파일러를 사용하여 매우 간단한 C 테스트 코드를 코드 (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; 
}

내가 컴파일하고 인텔과 13.0 컴파일러를 실행하려고 할 때, 큰 루프는 무시 될 것으로 보인다 및 실행은 제로 타이밍 결과 :

$ icc test.c 
$ ./a.out 
cputime_elapsed_in_sec: 0.000000e+00 
realtime_elapsed_in_sec: 9.000000e-06

나는 (주석 라인 (26)), 루프 것 합계를 인쇄 할 경우에만 실제로 exe가 되라. cuted :

$ 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 컴파일러에서 발생하지 않습니다. 인텔 컴파일러가 변수를 참조하지 않으면 루프가 무시되는 일부 최적화를 수행했을 수도 있습니다. 다음과 같이

시스템 정보는 다음과 같습니다 어떤 제안에 대한

$ 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)

감사합니다!

로이

출처

2017-05-09 Roy Li

무엇이 당신의 질문입니까? – immibis

최적화 기능을 사용하지 않도록 설정하고 합계를 인쇄 할 때 결과를 제공하는지 확인하십시오. http://stackoverflow.com/questions/5765899/how-to-disable-compiler-optimizations-in-gcc –

한 가지 옵션은 ' 합계가 휘발성이다. – paddy

을 감안할 때 최종 값을 인쇄하기를 느리게하여 관찰 ^(A), 옵티마이 당신이 후 아무것도sum를 사용하여 실제로 하지 않은 것을 알아내는 것이 상당히 좋은 기회가있다 계산 했으므로 전체 계산 루프를 최적화하지 않습니다.

꽤 오래 전에 우리 대학이받은 최신 VAX 11/780 기계 성능을 테스트했을 때 비슷한 것을 보았습니다. 똑같은 이유 때문에 수천 퍼센트의 속도로 빨랐습니다. 새로운 최적화 컴파일러는 루프가 실제로 필요하지 않다고 결정했습니다.

어셈블리 출력을 확인해야합니다. 나는 icc 옵션으로 -Fa <asmFileName> 옵션을 사용한 다음 <asmFileName> 대신 사용했던 파일 이름을 검사하여이 작업을 수행 할 수 있다고 생각합니다.

^(a)는 내가 생각 다른 가능성은 여기에 할인 된 것으로 보인다.

i의 범위가 일정하고 (N 기준) 계산에 그렇지 않은 경우 상수가 포함되는 경우 컴파일러 자체에서 컴파일하는 동안 최종 값을 계산할 수 있으므로 일정한로드 작동.

나는 gcc을 보았습니다. -O3 "미친"최적화 레벨에서 이런 종류의 일을했습니다.

값 인쇄가이 작업에 영향을 미치지 않을 가능성이 있으므로이 가능성을 무시합니다.

출처

2017-05-09 02:41:54 paxdiablo

답장을 보내 주셔서 감사합니다. 인쇄 합계 줄, 동일한 결과없이 -O1, -O2, -O3을 시도했습니다. -O0을 사용하여 최적화를 완전히 끄면 루프가 실행되었으므로 컴파일러가 전체 루프를 최적화하는 것으로 대답해야합니다. –

intel 컴파일러에서 큰 루프가 무시 되었습니까?

답변

관련 문제