C/C++는 최소 실행 시간에 대한 보장을 제공합니까?

C/C++는 최소 실행 시간에 대한 보장을 제공합니까?

컴파일러가 아무 것도 하지 않고 제거하지 않는 루프에 대해 예의를 갖추는 이유는 무엇입니까?

C 표준은 루프에 시간이 좀 걸릴까요?

예: 다음 코드:

void foo(void) {
    while(1) {
        for(int k = 0; k < 1000000000; ++k);
        printf("Foo\n");
    }
}

다음보다 느리게 실행됩니다.

void foo(void) {
    while(1) {
        for(int k = 0; k < 1000; ++k);
        printf("Foo\n");
    }
}

에도 -O3최적화 수준.빈 루프를 제거할 수 있으므로 두 코드 모두에서 동일한 속도를 얻을 수 있습니다.

"시간 소비"는 컴파일러에 의해 보존되어야 하는 부작용입니까?

아니요, 소요된 시간은 다음과 같은 as-if 규칙에 의해 보호되는 관찰 가능한 동작으로 계산되지 않습니다.

[C++14: 1.8/5]: 잘 형성된 프로그램을 실행하는 적합한 구현은 동일한 프로그램과 동일한 입력을 가진 추상 기계의 해당 인스턴스의 가능한 실행 중 하나와 동일한 관찰 가능한 동작을 생성해야 합니다.그러나 이러한 실행에 정의되지 않은 작업이 포함된 경우 이 국제 표준은 해당 입력으로 프로그램을 실행하는 구현에 대한 요구 사항을 두지 않습니다(첫 번째 정의되지 않은 작업 이전의 작업에 대해서도 마찬가지입니다).

[C++14: 1.5/8]:적합한 구현에 대한 최소 요구사항은 다음과 같습니다.

• 휘발성 개체에 대한 액세스는 추상 시스템의 규칙에 따라 엄격하게 평가됩니다.
• 프로그램 종료 시, 파일에 기록된 모든 데이터는 추상적 의미론에 따라 프로그램을 실행할 경우 발생할 수 있는 결과 중 하나와 동일해야 합니다.
• 대화형 장치의 입력 및 출력 역학은 프로그램이 입력을 대기하기 전에 실제로 출력을 요청하는 방식으로 발생해야 합니다.대화형 장치를 구성하는 것은 구현 정의된 것입니다.

이것들을 총칭하여 프로그램의 관찰 가능한 동작이라고 합니다.[ 참고:추상적 의미와 실제 의미 사이의 보다 엄격한 대응은 각 구현에 의해 정의될 수 있습니다.—끝 노트 ]

이러한 루프는 법적으로 최적화될 수 있으며, 실제로 이를 훨씬 더 쉽게 하기 위해 표준이 의도적으로 시도하는 시나리오가 있습니다.

[C++14: 1.10/24]:구현에서는 모든 스레드가 결국 다음 중 하나를 수행한다고 가정할 수 있습니다.

• 종료,
• 라이브러리 I/O 기능으로 호출,
• 휘발성 개체에 액세스하거나 수정합니다.
• 동기화 작업 또는 원자력 작업을 수행합니다.

[주: 이것은 종료를 증명할 수 없는 경우에도 빈 루프 제거와 같은 컴파일러 변환을 허용하기 위한 것입니다.—끝 노트 ]

컴파일러는 실제로 이러한 프로그램의 루프 의도가 반복적인 텍스트 출력의 방출 속도를 늦추는 것으로 보인다는 것을 알아차리는 데 있어 "예의 바른" 것일 수 있습니다.:)

컴파일러를 지정하지 않았지만 다음과 같이 가정합니다.gcc.

gcc는 적어도 설명서에 따르면 빈 루프를 제거하지 않습니다.다음 텍스트가 포함되어 있습니다.

GCC는 프로그램에 "빈" 루프를 넣는 가장 가능성이 높은 이유는 지연이 있기 때문이라는 가정 하에 "빈" 루프를 삭제하지 않았기 때문에 루프를 삭제해도 실제 프로그램이 더 빨리 실행되지 않습니다.

그러나 옵티마이저에 의해 빈 루프가 "비어있는" 경우, 즉 루프에 옵티마이저가 루프 밖으로 이동할 수 있는 코드가 포함되어 있고 결과 루프가 비어 있는 경우에는 빈 루프를 제거할 수 있습니다.

최신 버전에서 이 문제가 여전히 사실인지 여부는 설명서에서 명확하지 않습니다.설명서에는 이유를 명시하지 않고 "역사적으로" 언급되어 있습니다.당신이 당신의 정확한 플랫폼과 컴파일러에 대한 정보로 당신의 질문을 업데이트한다면, 아마도 더 나은 대답이 제공될 것입니다.

C 또는 C++ 실행 파일의 실행 시간은 다음과 같은 플랫폼 관련 문제에 따라 달라지기 때문에 최소 실행 시간은 없습니다.

1. 프로세서 클럭 속도입니다.
2. 명령당 클럭 주기입니다.
3. 내부 프로세서 실행 최적화.
4. 방해.
5. 프로세서 명령 집합/기능.

일부 프로세서는 곱셈을 지원하지만 다른 프로세서는 지원하지 않습니다.곱셈을 지원하지 않는 프로세서는 곱셈 명령이 있는 프로세스보다 프로그램을 실행하는 데 더 오래 걸립니다.부동 소수점도 마찬가지입니다.

프로세서의 내부 작동 속도는 다양합니다."클럭 사이클"이라고 하는 일반적인 시간 측정 단위가 있습니다.대부분의 프로세서 공급업체는 명령의 지속 시간을 클럭 주기로 지정합니다.이 측정은 캐시 관리와 같은 내부 지원으로 인해 어려울 수 있습니다.

일부 프로세서에는 명령어 또는 명령어 패턴의 실행을 최적화할 수 있는 논리가 있습니다.한 가지 최적화 방법은 분기 예측입니다.

많은 플랫폼에 인터럽트가 있습니다.예를 들어, 운영 체제가 언제 다른 프로그램으로 실행을 전환해야 하는지 알 수 있게 해주는 "시스템 틱" 인터럽트가 있을 수 있습니다.일부는 I/O가 발생하는 경우와 같이 주기적이지 않습니다.프로그램이 중단되면 최소 실행 시간을 보장할 수 없습니다.

최소 실행 시간을 명시하는 것은 C 및 C++ 언어 이식성에 큰 영향을 미칠 것입니다.일부 플랫폼은 최소 시간보다 빠르게 코드를 실행하려고 합니다.다른 플랫폼은 최소 실행 시간을 달성하지 못할 수도 있지만 C와 같은 고급 언어의 이점을 누릴 수 있습니다.

또한, 시간은 어떻게 측정됩니까?

최소 실행 시간이 지연 루프 또는 폴링에 적용됩니까?

아니요, 보장은 없습니다: (N1570, 5.1.2.3 프로그램 실행의 인용)

1 이 국제 표준의 의미론적 설명은 최적화 문제가 관련이 없는 추상적 기계의 동작을 설명합니다.

어쨌든 C 표준은 무한한 메모리 및/또는 CPU를 가질 수 있는 추상 시스템에서 실행될 때 프로그램의 동작만 지정합니다.

언급URL : https://stackoverflow.com/questions/36814199/does-c-c-offer-any-guarantee-on-minimal-execution-time