이 답변을 쓸 때 상수 a < 901vs 의 구체적인 예가 아니라 <vs. <=에 대한 제목 질문 만 보았습니다 a <= 900. 대부분의 컴파일러는 항상 사이의 변환 상수의 크기를 축소 <하고<= 예를 들어, 때문에 86 즉시 피연산자 -128..127에 대한 짧은 1 바이트 인코딩을해야합니다.
ARM 및 특히 AArch64의 경우 즉시 인코딩 할 수있는 것은 좁은 필드를 단어의 임의의 위치로 회전 할 수 있는지에 달려 있습니다. 따라서 cmp w0, #0x00f000인코딩 할 수는 있지만 그렇지 cmp w0, #0x00effff않을 수도 있습니다. 따라서 비교를위한 더 작은 규칙과 컴파일 타임 상수가 항상 AArch64에 적용되는 것은 아닙니다.
<vs. <= 일반적으로 런타임 변수 조건을 포함하여
대부분의 컴퓨터에서 어셈블리 언어로 비교할 때 비교하는 <=비용은< . 이것은 당신이 그것에 분기하거나, 0/1 정수를 만들기 위해 그것을 부울하거나, xless CMOV와 같은 분기없는 선택 연산의 술어로 사용하든 적용됩니다. 다른 답변은 질문 의이 부분만을 다루었습니다.
그러나이 질문은 C ++ 연산자, 최적화 프로그램 의 입력 에 관한 것입니다. 일반적으로 둘 다 동일하게 효율적입니다. 컴파일러가 항상 asm으로 구현 한 비교를 변환 할 수 있기 때문에이 책의 조언은 완전히 허구 적으로 들립니다. 그러나 적어도 하나의 예외가 있습니다.<= 실수로 컴파일러가 최적화 할 수없는 것을 만들 수 있습니다.
루프 조건으로서 컴파일러가 루프가 무한하지 않다는 것을 증명하지 못하게하는 경우와 질적으로 다른 경우 <=가 있습니다. < 이는 자동 벡터화를 비활성화하여 큰 차이를 만들 수 있습니다.
부호없는 오버플로는 부호있는 오버플로 (UB)와 달리 base-2 랩으로 잘 정의되어 있습니다. 부호있는 루프 카운터는 일반적으로 부호없는 오버플로 UB를 기반으로 최적화하는 컴파일러를 통해 이로부터 안전 ++i <= size합니다. 결국에는 항상 거짓이됩니다. ( 모든 C 프로그래머가 정의되지 않은 행동에 대해 알아야 할 것 )
void foo(unsigned size) {
unsigned upper_bound = size - 1; // or any calculation that could produce UINT_MAX
for(unsigned i=0 ; i <= upper_bound ; i++)
...
컴파일러는 정의 되지 않은 동작을 유발하는 값 을 제외하고 가능한 모든 입력 값에 대해 C ++ 소스의 (정의되고 법적으로 관찰 가능한) 동작을 유지하는 방식으로 만 최적화 할 수 있습니다 .
(간단한 i <= size문제도 발생할 수 있지만 상한을 계산하는 것은 실수로 신경 쓰지 않아도되지만 컴파일러가 고려해야하는 입력에 대해 무한 루프의 가능성을 실수로 도입하는보다 현실적인 예라고 생각했습니다.)
이 경우 size=0에 리드 upper_bound=UINT_MAX, 그리고 i <= UINT_MAX항상 사실이다. 따라서이 루프는 무한대이며 size=0컴파일러는 프로그래머가 크기 = 0을 전달하려고하지 않더라도 존중해야 합니다. 컴파일러가 size = 0이 불가능하다는 것을 증명할 수있는 호출자에게이 함수를 인라인 할 수 있다면 훌륭합니다 i < size.
asm if(!size) skip the loop; do{...}while(--size);은 for( i<size )루프 내에서 실제 값이 i필요하지 않은 경우 루프 를 최적화하는 일반적으로 효율적인 방법 중 하나입니다 ( 루프가 항상 "do ... while"스타일 (테일 점프)로 컴파일되는 이유는 무엇입니까? ).
그러나 이것은 무한대 일 수 없지만 {}로 입력 size==0하면 2 ^ n의 반복이 발생합니다. ( for 루프 C 에서 부호없는 정수를 반복 하면 0을 포함한 모든 부호없는 정수에 대해 루프를 표현할 수 있지만 캐리 플래그가 없으면 asm 방식으로는 쉽지 않습니다.)
루프 카운터의 랩 어라운드 (wraparound)가 가능성이 있기 때문에, 현대 컴파일러는 종종 "포기"하고 거의 적극적으로 최적화하지 않습니다.
예 : 1에서 n까지의 정수의 합
unsigned i <= n를 사용하면sum(1 .. n) 가우스 n * (n+1) / 2공식을 기반으로 닫힌 형태로 루프 를 최적화하는 clang의 관용구 인식이 무효화 됩니다.
unsigned sum_1_to_n_finite(unsigned n) {
unsigned total = 0;
for (unsigned i = 0 ; i < n+1 ; ++i)
total += i;
return total;
}
Godbolt 컴파일러 탐색기에서 clang7.0 및 gcc8.2의 x86-64 asm
# clang7.0 -O3 closed-form
cmp edi, -1 # n passed in EDI: x86-64 System V calling convention
je .LBB1_1 # if (n == UINT_MAX) return 0; // C++ loop runs 0 times
# else fall through into the closed-form calc
mov ecx, edi # zero-extend n into RCX
lea eax, [rdi - 1] # n-1
imul rax, rcx # n * (n-1) # 64-bit
shr rax # n * (n-1) / 2
add eax, edi # n + (stuff / 2) = n * (n+1) / 2 # truncated to 32-bit
ret # computed without possible overflow of the product before right shifting
.LBB1_1:
xor eax, eax
ret
그러나 순진한 버전의 경우 clang에서 바보 루프를 얻습니다.
unsigned sum_1_to_n_naive(unsigned n) {
unsigned total = 0;
for (unsigned i = 0 ; i<=n ; ++i)
total += i;
return total;
}
# clang7.0 -O3
sum_1_to_n(unsigned int):
xor ecx, ecx # i = 0
xor eax, eax # retval = 0
.LBB0_1: # do {
add eax, ecx # retval += i
add ecx, 1 # ++1
cmp ecx, edi
jbe .LBB0_1 # } while( i<n );
ret
GCC는 닫힌 형식을 사용하지 않으므로 루프 조건을 선택해도 실제로 손상되지 않습니다 . iXMM 레지스터의 요소에서 4 개의 값을 병렬로 실행하여 SIMD 정수 추가로 자동 벡터화됩니다 .
# "naive" inner loop
.L3:
add eax, 1 # do {
paddd xmm0, xmm1 # vect_total_4.6, vect_vec_iv_.5
paddd xmm1, xmm2 # vect_vec_iv_.5, tmp114
cmp edx, eax # bnd.1, ivtmp.14 # bound and induction-variable tmp, I think.
ja .L3 #, # }while( n > i )
"finite" inner loop
# before the loop:
# xmm0 = 0 = totals
# xmm1 = {0,1,2,3} = i
# xmm2 = set1_epi32(4)
.L13: # do {
add eax, 1 # i++
paddd xmm0, xmm1 # total[0..3] += i[0..3]
paddd xmm1, xmm2 # i[0..3] += 4
cmp eax, edx
jne .L13 # }while( i != upper_limit );
then horizontal sum xmm0
and peeled cleanup for the last n%3 iterations, or something.
또한 평범한 스칼라 루프가있어 매우 작 n거나 무한 루프 경우에 사용한다고 생각합니다 .
BTW에서이 두 루프는 루프 오버 헤드에 대한 명령 (및 Sandybridge 제품군 CPU의 UOP)을 낭비합니다. sub eax,1/ cmp / jcc jnz대신 add eax,1/가 더 효율적입니다. 2 대신 1uop (sub / jcc 또는 cmp / jcc의 매크로 융합 후). 두 루프 후의 코드는 EAX를 무조건 작성하므로 루프 카운터의 최종 값을 사용하지 않습니다.