컴파일러가 예측 가능한 추가 루프를 곱셈으로 최적화 할 수없는 이유는 무엇입니까?

이것은 질문에 대한 Mysticial 의 훌륭한 답변을 읽는 동안 염두에 두었던 질문입니다. 정렬되지 않은 배열보다 정렬 된 배열을 처리하는 것이 왜 더 빠릅 니까?

관련된 유형에 대한 컨텍스트 :

const unsigned arraySize = 32768;
int data[arraySize];
long long sum = 0;

그의 대답에서 그는 인텔 컴파일러 (ICC)가 이것을 최적화한다고 설명합니다.

for (int i = 0; i < 100000; ++i)
    for (int c = 0; c < arraySize; ++c)
        if (data[c] >= 128)
            sum += data[c];

... 이와 동등한 것으로 :

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        for (int i = 0; i < 100000; ++i)
            sum += data[c];

옵티마이 저는 이들이 동등 함을 인식 하고 루프를 교환 하여 분기를 내부 루프 밖으로 이동시킵니다. 매우 영리한!

그러나 왜 그렇지 않습니까?

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        sum += 100000 * data[c];

바라건대 Mysticial (또는 다른 사람)도 똑같이 훌륭한 답변을 줄 수 있습니다. 나는 이전에 다른 질문에서 논의 된 최적화에 대해 배운 적이 없으므로 정말 감사합니다.

컴파일러는 일반적으로 변환 할 수 없습니다

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        for (int i = 0; i < 100000; ++i)
            sum += data[c];

으로

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        sum += 100000 * data[c];

후자는 전자가하지 않은 부호있는 정수의 오버플로를 일으킬 수 있기 때문입니다. 부호있는 2의 보수 정수의 오버플로에 대해 보장 된 랩 어라운드 동작으로도 결과가 변경됩니다 data[c](30000 인 경우 제품은 랩핑이 -1294967296있는 전형적인 32 비트 ints가되고 100000 번 추가하면 30000이 추가 sum됩니다) 오버플로하지 않고 sum3000000000 증가 ). 숫자가 다른 부호없는 수량에 대해서도 동일하게 유지되므로 오버플로 100000 * data[c]는 일반적으로 2^32최종 결과에 나타나지 않아야 하는 감소 모듈로 를 발생시킵니다.

그것은 그것을

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        sum += 100000LL * data[c];  // resp. 100000ull

그러나 평소와 같이 long long충분히 큽니다 int.

그렇게하지 않는 이유는 알 수 없다. 나는 Mysticial이 "루프 교환 후 루프 붕괴 패스를 실행하지 않는다"고 말했다.

루프 교환 자체는 일반적으로 유효하지 않습니다 (서명 된 정수의 경우).

for (int c = 0; c < arraySize; ++c)
    if (condition(data[c]))
        for (int i = 0; i < 100000; ++i)
            sum += data[c];

오버플로로 이어질 수 있습니다

for (int i = 0; i < 100000; ++i)
    for (int c = 0; c < arraySize; ++c)
        if (condition(data[c]))
            sum += data[c];

그렇지 않습니다. 조건 data[c]이 추가 되면 모든 항목 이 동일한 부호를 갖도록 보장 되므로 하나가 넘치면 둘 다 수행됩니다.

컴파일러가 그것을 고려했다고 확신하지는 못합니다 (@Mysticial, data[c] & 0x80양수 및 음수 값에 해당 하는 조건으로 시도해 볼 수 있습니까?). 나는 컴파일러 (예를 들어, 몇 년 전에, 나는 IIRC, ICC는 (11.0했다) 무효 최적화 할 로그인 32 비트-INT-에 두 번에 변환 사용했다 1.0/n어디 n을 하였다 unsigned int. GCC 년대로 두 배 정도 빨랐다 그러나 잘못된 결과는 많은 것보다 컸습니다 2^31.

이 답변은 링크 된 특정 사례에는 적용되지 않지만 질문 제목에는 적용되며 향후 독자에게 흥미로울 수 있습니다.

유한 정밀도로 인해 반복 부동 소수점 추가는 곱셈과 동일하지 않습니다 . 치다:

float const step = 1e-15;
float const init = 1;
long int const count = 1000000000;

float result1 = init;
for( int i = 0; i < count; ++i ) result1 += step;

float result2 = init;
result2 += step * count;

cout << (result1 - result2);

데모

컴파일러에는 최적화를 수행하는 다양한 패스가 포함되어 있습니다. 일반적으로 각 단계에서 명령문에 대한 최적화 또는 루프 최적화가 수행됩니다. 현재 루프 헤더를 기반으로 루프 바디를 최적화하는 모델은 없습니다. 이것은 감지하기 어렵고 덜 일반적입니다.

수행 된 최적화는 루프 불변 코드 모션이었습니다. 이것은 일련의 기술을 사용하여 수행 할 수 있습니다.

글쎄, 우리는 정수 산술에 대해 이야기하고 있다고 가정 할 때 일부 컴파일러가 이러한 종류의 최적화를 수행 할 수 있다고 생각합니다.

동시에 반복적으로 더하기를 곱셈으로 바꾸면 코드의 오버플로 동작이 변경 될 수 있으므로 일부 컴파일러는이를 거부 할 수 있습니다. 부호없는 정수 유형의 경우 오버플로 동작이 언어에 의해 완전히 지정되므로 차이가 없어야합니다. 그러나 서명 된 사람들에게는 아마도 2의 보완 플랫폼에는 없을 것입니다. 실제로 부호있는 오버플로가 C에서 정의되지 않은 동작을 초래한다는 것은 사실입니다. 즉, 오버플로 의미를 완전히 무시한다는 것은 완벽하게 괜찮지 만 모든 컴파일러가 그렇게 용감하지는 않습니다. 그것은 종종 "C는 단지 고수준의 어셈블리 언어"군중들로부터 많은 비판을받습니다. (GCC가 엄격한 앨리어싱 의미론을 기반으로 최적화를 도입했을 때 일어난 일을 기억하십니까?)

역사적으로 GCC는 그처럼 과감한 조치를 취하는 데 필요한 컴파일러로 나타 났지만 다른 컴파일러는 언어에 의해 정의되지 않은 경우에도 인식 된 "사용자 의도"동작을 고수하는 것을 선호 할 수 있습니다.

이제는 최소한 clang은 다음과 같이합니다.

long long add_100k_signed(int *data, int arraySize)
{
    long long sum = 0;

    for (int c = 0; c < arraySize; ++c)
        if (data[c] >= 128)
            for (int i = 0; i < 100000; ++i)
                sum += data[c];
    return sum;
}

-O1을 사용하여 컴파일

add_100k_signed:                        # @add_100k_signed
        test    esi, esi
        jle     .LBB0_1
        mov     r9d, esi
        xor     r8d, r8d
        xor     esi, esi
        xor     eax, eax
.LBB0_4:                                # =>This Inner Loop Header: Depth=1
        movsxd  rdx, dword ptr [rdi + 4*rsi]
        imul    rcx, rdx, 100000
        cmp     rdx, 127
        cmovle  rcx, r8
        add     rax, rcx
        add     rsi, 1
        cmp     r9, rsi
        jne     .LBB0_4
        ret
.LBB0_1:
        xor     eax, eax
        ret

정수 오버플로는 이와 관련이 없습니다. 정의되지 않은 동작을 일으키는 정수 오버플로가있는 경우 어느 경우 든 발생할 수 있습니다. 다음 대신 사용하는 동일한 종류의 함수 int가 있습니다long .

int add_100k_signed(int *data, int arraySize)
{
    int sum = 0;

    for (int c = 0; c < arraySize; ++c)
        if (data[c] >= 128)
            for (int i = 0; i < 100000; ++i)
                sum += data[c];
    return sum;
}

-O1을 사용하여 컴파일

add_100k_signed:                        # @add_100k_signed
        test    esi, esi
        jle     .LBB0_1
        mov     r9d, esi
        xor     r8d, r8d
        xor     esi, esi
        xor     eax, eax
.LBB0_4:                                # =>This Inner Loop Header: Depth=1
        mov     edx, dword ptr [rdi + 4*rsi]
        imul    ecx, edx, 100000
        cmp     edx, 127
        cmovle  ecx, r8d
        add     eax, ecx
        add     rsi, 1
        cmp     r9, rsi
        jne     .LBB0_4
        ret
.LBB0_1:
        xor     eax, eax
        ret

이런 종류의 최적화에는 개념적 장벽이 있습니다. 컴파일러 작성자 는 곱셈을 더하기 및 바꾸기로 바꾸는 등 강도 감소 에 많은 노력을 기울입니다 . 그들은 곱셈이 나쁘다는 생각에 익숙해집니다. 따라서 다른 방법으로 가야하는 경우는 놀랍고 반 직관적입니다. 따라서 아무도 그것을 구현하려고 생각하지 않습니다.

컴파일러를 개발하고 유지 관리하는 사람들은 작업에 소요되는 시간과 에너지가 제한되어 있으므로 일반적으로 사용자가 가장 관심을 갖는 것에 초점을 맞추고 싶습니다. 잘 작성된 코드를 빠른 코드로 전환하는 것입니다. 그들은 바보 같은 코드를 빠른 코드로 바꾸는 방법을 찾기 위해 시간을 허비하기를 원하지 않습니다. 이것이 바로 코드 검토입니다. 고급 언어에는 중요한 아이디어를 표현하는 "어리석은"코드가있을 수 있습니다. 예를 들어, 짧은 삼림 벌채 및 스트림 융합은 Haskell 프로그램이 특정 종류의 게으른 주위에 구조화 될 수있게 해줍니다. 메모리를 할당하지 않는 타이트한 루프로 컴파일 할 데이터 구조를 생성했습니다. 그러나 이러한 종류의 인센티브는 단순히 반복 덧셈을 곱셈으로 바꾸는 데 적용되지 않습니다. 빨리하고 싶다면