जब मैंने यह उत्तर लिखा था, मैं केवल सामान्य रूप में <बनाम <= के बारे में शीर्षक प्रश्न देख रहा था, न कि एक स्थिर a < 901बनाम का विशिष्ट उदाहरण a <= 900। कई कंपाइलर हमेशा <और के बीच परिवर्तित करके स्थिरांक की भयावहता को कम करते हैं <=, जैसे कि x86 तत्काल ऑपरेंड में -128 के लिए एक छोटा बाइट एन्कोडिंग होता है ।.127।
एआरएम और विशेष रूप से AArch64 के लिए, एक तत्काल के रूप में सांकेतिक शब्दों में बदलना एक संकीर्ण क्षेत्र को एक शब्द में किसी भी स्थिति में घुमाने में सक्षम होने पर निर्भर करता है। अतः cmp w0, #0x00f000अतिक्रमण होगा, जबकि cmp w0, #0x00effffनहीं हो सकता है। इसलिए तुलनात्मक संकलन के लिए मेक-इट-छोटा नियम हमेशा AArch64 के लिए लागू नहीं होता है।
सामान्य रूप से रन-चर स्थितियों के लिए <बनाम <= सामान्य रूप से
अधिकांश मशीनों पर असेंबली भाषा में, एक तुलना के लिए एक <=ही लागत है <। यह उस पर लागू होता है चाहे आप उस पर शाखा लगा रहे हों, इसे 0/1 पूर्णांक बनाने के लिए बूलियनाइज़ कर रहे हों, या इसे एक शाखा रहित चयन ऑपरेशन (जैसे x86 CMOV) के लिए विधेय के रूप में उपयोग कर रहे हों। अन्य उत्तरों ने केवल प्रश्न के इस भाग को संबोधित किया है।
लेकिन यह सवाल C ++ ऑपरेटरों, अनुकूलक के इनपुट के बारे में है । आम तौर पर वे दोनों समान रूप से कुशल होते हैं; पुस्तक से सलाह पूरी तरह से फर्जी लगती है क्योंकि कंपाइलर हमेशा उस तुलना को बदल सकते हैं जिसे वे एसम में लागू करते हैं। लेकिन कम से कम एक अपवाद है जहां <=संयोगवश कुछ ऐसा बना सकते हैं जो संकलक अनुकूलन नहीं कर सकता है।
लूप स्थिति के रूप में, ऐसे मामले होते हैं <=जो गुणात्मक रूप से भिन्न होते हैं <, जब यह संकलक को यह साबित करने से रोकता है कि लूप अनंत नहीं है। यह एक बड़ा अंतर बना सकता है, ऑटो-वेक्टरकरण को अक्षम करना।
हस्ताक्षरित ओवरफ्लो (यूबी) के विपरीत, बिना सौंपा ओवरफ्लो को बेस -2 रैप के रूप में अच्छी तरह से परिभाषित किया गया है। हस्ताक्षर किए गए लूप काउंटर आमतौर पर संकलक के साथ सुरक्षित होते हैं जो हस्ताक्षरित-अतिप्रवाह यूबी के आधार पर अनुकूलन करते हैं जो नहीं हो रहा है: ++i <= sizeहमेशा अंततः गलत हो जाएगा। ( हर सी प्रोग्रामर को अपरिभाषित व्यवहार के बारे में क्या जानना चाहिए )
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 पास करने का इरादा न करें। यदि कंपाइलर इस फ़ंक्शन को एक कॉलर में इनलाइन कर सकता है, जहां यह साबित कर सकता है कि आकार = 0 असंभव है, तो बहुत अच्छा, यह ऑप्टिमाइज़ कर सकता है जैसे यह कर सकता है i < size।
जैसे लूप if(!size) skip the loop; do{...}while(--size);ऑप्टिमाइज़ करने का एक सामान्य तरीका है for( i<size ), अगर लूप के iअंदर वास्तविक मूल्य की आवश्यकता नहीं है ( क्यों लूप हमेशा "डू ... कॉम्प्लेक्स" (टेल जंप)? ) में संकलित किए जाते हैं ।
लेकिन वह {} जबकि अनंत नहीं हो सकता है: अगर साथ में प्रवेश किया है size==0, तो हमें 2 ^ n पुनरावृत्तियों मिलते हैं। ( लूप C के लिए सभी अहस्ताक्षरित पूर्णांक से अधिक का उपयोग करना) शून्य सहित सभी अहस्ताक्षरित पूर्णांकों पर एक लूप व्यक्त करना संभव बनाता है, लेकिन जिस तरह से यह asm में है, उसे कैरी फ़्लैग के बिना आसान नहीं है।)
लूप काउंटर के रैपराउंड के साथ एक संभावना होने के नाते, आधुनिक कंपाइलर अक्सर बस "छोड़ देते हैं", और लगभग आक्रामक रूप से अनुकूलन नहीं करते हैं।
उदाहरण: 1 से n तक पूर्णांकों का योग
अहस्ताक्षरित i <= nपराजित क्लैंग के मुहावरे-मान्यता का उपयोग करना जोsum(1 .. n) गॉस के n * (n+1) / 2फार्मूले के आधार पर एक बंद फॉर्म के साथ लूप को अनुकूलित करता है।
unsigned sum_1_to_n_finite(unsigned n) {
unsigned total = 0;
for (unsigned i = 0 ; i < n+1 ; ++i)
total += i;
return total;
}
Godbolt संकलक एक्सप्लोरर पर xang7.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
लेकिन भोले संस्करण के लिए, हमें बस क्लैंग से एक गूंगा लूप मिलता है।
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
जीसीसी किसी भी तरह से एक बंद-फॉर्म का उपयोग नहीं करता है, इसलिए लूप स्थिति का विकल्प वास्तव में इसे चोट नहीं पहुंचाता है ; यह SIMD पूर्णांक जोड़ के साथ ऑटो-वेक्टर करता है, जो iएक एक्सएमएम रजिस्टर के तत्वों में समानांतर में 4 मान चलाता है ।
# "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, इन दोनों छोरों लूप ओवरहेड पर एक निर्देश (और सैंडब्रिज-परिवार सीपीयू पर एक यूओपी) बर्बाद करते हैं। sub eax,1/ cmp / jcc के jnzबजाय add eax,1अधिक कुशल होगा। 2 के बजाय 1 यूओपी (उप / jcc या cmp / jcc के मैक्रो-फ्यूजन के बाद)। दोनों लूप के बाद का कोड EAX बिना शर्त लिखता है, इसलिए यह लूप काउंटर के अंतिम मूल्य का उपयोग नहीं कर रहा है।