2011-03-31 4 views
2

디버그 모드에서 함수 f1()을 실행하는 데 걸리는 시간이 다른 것으로 변경되는 이유는 무엇입니까? 왜 그것이 릴리스 모드에서 항상 0입니까?clock() 함수에 관한 질문

나는 stdio.h 나 cstdio를 포함시키지 않았고 코드를 컴파일했다. 어떻게?

#include <iostream> 
#include <ctime> 

void f1() 
{ 
    for(int i = 0; i < 10000; i++); 
} 

int main() 
{ 
    clock_t start, finish; 

    start = clock(); 
    for(int i = 0; i < 100000; i++) f1(); 
    finish = clock(); 

    double duration = (double)(finish - start)/CLOCKS_PER_SEC; 

    printf("Duration = %6.2f seconds\n", duration); 
} 

답변

0

릴리스 모드에서 f1()의 런타임이 표시되지 않는 이유는 컴파일러가 함수를 최적화하기 때문입니다. for 루프에는 코드 블록이 없으므로 컴파일하는 동안 루프를 효과적으로 끌 수 있습니다.

이 최적화가 디버그 모드에서 수행되지 않는다고 생각합니다. 그러면 디버깅 모드에서 실행 시간이 더 긴 이유가 설명됩니다. 운영 체제 스케줄러 (거의 확실하게)가 프로세스의 고정 시간 슬롯을 보장하지 않기 때문에 실행마다 다릅니다.

printf()<cstdio>을 명시 적으로 포함시키지 않은 이유는 <iostream> 포함이기 때문입니다. C에서 내 헤더를 찾고에서

: 10.0 \ VC \이 포함 \ 프로그램 Files \ Microsoft Visual Studio에서, 나는, iostreamIOS을 포함 모두의 IStream을ostream에가 포함되어 있음을 알 수 xlocnum을 포함하며, cstdlibcstdio을 모두 포함합니다.

+0

함수 f1()을 변경하여 첫 번째 10000 int의 합계를 계산하고이 값을 반환했습니다. 릴리스 모드는 여전히 실행 시간 동안 0을 반환합니다. – Ayrosa

+0

릴리스 모드에서 실행 시간이 0보다 큰 상황을 마침내 발견했습니다. – Ayrosa

+0

@jaayrosa, 컴파일러 최적화에 대한 내 가정이 맞는지 잘 모르겠지만 빈 루프 일 가능성이 큽니다. 루프에 명령어가있는 런타임이 여전히 0 인 경우 다른 일이 발생할 가능성이 큽니다 (hopia의 답변 참조). – Rob

1

테스트 코드를 실행하는 컴퓨터가 너무 빠릅니다. 루프 카운트를 엄청나게 늘려보십시오.

다른 시도는 sleep() 함수로 테스트하는 것입니다. 이것은 clock() 측정의 동작을 확인해야합니다.

+0

작은 수정을 할 수 있습니까? 'sleep()'으로 테스트에 대한 의견을 듣지 못했고 투표를 변경하고 싶습니다. 죄송합니다. – Rob

+1

문제가 없습니다. 그의 clock()이 제대로 작동하는지 확인하는 방법에 대한 디버깅 정보를 제공 할 생각이었다. 하지만 그렇습니다. 최적화가 루프를 변환하지 않을 것이라고 동의합니다. – hopia