เมื่อผมเขียนคำตอบนี้ผมเป็นเพียงการมองหาที่เกี่ยวกับคำถามชื่อ <เทียบกับ <= โดยทั่วไปไม่ได้เป็นตัวอย่างที่เฉพาะเจาะจงของค่าคงที่เมื่อเทียบกับa < 901 a <= 900คอมไพเลอร์หลายคนมักจะลดขนาดของค่าคงที่โดยการแปลงระหว่าง<และ<=เช่น e เนื่องจาก x86 ตัวถูกดำเนินการทันทีมีการเข้ารหัส 1 ไบต์ที่สั้นกว่าสำหรับ -128..127
สำหรับ ARM และ AArch64 โดยเฉพาะความสามารถในการเข้ารหัสแบบทันทีนั้นขึ้นอยู่กับความสามารถในการหมุนฟิลด์แคบ ๆ ให้อยู่ในตำแหน่งใด ๆ ในคำ ดังนั้นcmp w0, #0x00f000จะเข้ารหัสได้ในขณะที่cmp w0, #0x00effffอาจจะไม่ ดังนั้นกฎที่ทำให้เล็กลงสำหรับการเปรียบเทียบกับค่าคงที่เวลาคอมไพล์ไม่ได้ใช้กับ AArch64 เสมอไป
<vs. <= โดยทั่วไปรวมถึงเงื่อนไขตัวแปรรันไทม์
ในภาษาประกอบในเครื่องมากที่สุดสำหรับการเปรียบเทียบมีค่าใช้จ่ายเช่นเดียวกับการเปรียบเทียบหา<= <สิ่งนี้นำไปใช้ไม่ว่าคุณจะทำการแยกมันบูลีนเพื่อสร้างจำนวนเต็ม 0/1 หรือใช้เป็นเพรดิเคตสำหรับการดำเนินการเลือกแบบไม่มีสาขา (เช่น x86 CMOV) คำตอบอื่น ๆ ได้กล่าวถึงส่วนนี้ของคำถามเท่านั้น
แต่คำถามนี้เกี่ยวกับตัวดำเนินการ C ++ คืออินพุตของเครื่องมือเพิ่มประสิทธิภาพ โดยปกติพวกเขาทั้งสองมีประสิทธิภาพเท่าเทียมกัน คำแนะนำจากหนังสือเล่มนี้ฟังดูผิด ๆ โดยสิ้นเชิงเพราะคอมไพเลอร์สามารถเปลี่ยนการเปรียบเทียบที่พวกเขาใช้ใน asm แต่มีข้อยกเว้นอย่างน้อยหนึ่งข้อที่การใช้งาน<=สามารถสร้างบางอย่างที่คอมไพเลอร์ไม่สามารถปรับให้เหมาะสม
เป็นเงื่อนไขห่วงมีกรณีที่<=เป็นเชิงคุณภาพที่แตกต่างจาก<เมื่อมันหยุดเรียบเรียงจากการพิสูจน์ว่าห่วงไม่ได้ไม่มีที่สิ้นสุด สิ่งนี้สามารถสร้างความแตกต่างใหญ่ปิดการใช้งานการทำให้เป็นเวกเตอร์อัตโนมัติ
Overflow ที่ไม่ได้ลงนามถูกกำหนดอย่างดีว่าเป็น base-2 ที่ล้อมรอบซึ่งต่างจาก overflow ที่ลงนามแล้ว (UB) โดยทั่วไปแล้วตัวนับลูปที่ลงนามจะปลอดภัยจากสิ่งนี้ด้วยคอมไพเลอร์ที่ปรับให้เหมาะสมตาม 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และคอมไพเลอร์ต้องเคารพว่าแม้ว่าคุณในฐานะโปรแกรมเมอร์อาจไม่เคยตั้งใจจะส่งผ่าน size = 0 ถ้าคอมไพเลอร์สามารถ inline ฟังก์ชั่นนี้ในการโทรที่มันสามารถพิสูจน์ได้ว่าขนาด = 0 i < sizeเป็นไปไม่ได้แล้วที่ดีก็สามารถเพิ่มประสิทธิภาพเหมือนมันสามารถสำหรับ
Asm like if(!size) skip the loop; do{...}while(--size);เป็นวิธีหนึ่งที่มีประสิทธิภาพในการเพิ่มประสิทธิfor( i<size )ภาพลูปถ้าiไม่จำเป็นต้องใช้ค่าจริงของลูปในลูป )
แต่นั่นทำ {} ในขณะที่ไม่สามารถสิ้นสุดได้: หากป้อนด้วยsize==0เราจะได้รับซ้ำ 2 ^ n (การวนซ้ำกับจำนวนเต็มที่ไม่ได้ลงนามทั้งหมดใน for for C ทำให้สามารถแสดงลูปมากกว่าจำนวนเต็มที่ไม่ได้ลงนามทั้งหมดรวมถึงศูนย์ แต่มันไม่ใช่เรื่องง่ายหากไม่มีแฟล็กที่ถือในแบบ asm)
ด้วยการวนซ้ำของตัวนับลูปทำให้มีความเป็นไปได้คอมไพเลอร์สมัยใหม่มักจะ "ยอมแพ้" และไม่ปรับให้เหมาะสมเกือบจะก้าวร้าว
ตัวอย่าง: ผลรวมของจำนวนเต็มตั้งแต่ 1 ถึง n
การใช้การi <= nรับรู้สำนวนเสียงดังกังวานที่ไม่ได้ลงนามของ clang ที่ปรับsum(1 .. n)ลูปให้เหมาะสมกับรูปแบบปิดตามn * (n+1) / 2สูตรของ Gauss
unsigned sum_1_to_n_finite(unsigned n) {
unsigned total = 0;
for (unsigned i = 0 ; i < n+1 ; ++i)
total += i;
return total;
}
x86-64 asm จาก clang7.0 และ gcc8.2 บนตัวรวบรวมคอมไพเลอร์ Godbolt
# 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
GCC ไม่ได้ใช้แบบฟอร์มการปิดทางใดทางหนึ่งดังนั้นทางเลือกของสภาพ loop ไม่ได้จริงๆมันเจ็บปวด ; มันจะปรับเวกเตอร์อัตโนมัติด้วยการเพิ่มจำนวนเต็มของ SIMD โดยรัน 4 iค่าแบบขนานในองค์ประกอบของการลงทะเบียน XMM
# "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, ลูปทั้งสองนี้เสียคำสั่ง (และ uop บน Sandybridge-family CPUs) บนลูปโอเวอร์เฮด sub eax,1/ jnzแทนที่จะเป็นadd eax,1/ cmp / jcc จะมีประสิทธิภาพมากกว่า 1 uop แทน 2 (หลังแมโครฟิวชั่นของ sub / jcc หรือ cmp / jcc) รหัสหลังจากลูปทั้งสองเขียน EAX โดยไม่มีเงื่อนไขดังนั้นจึงไม่ได้ใช้ค่าสุดท้ายของตัวนับลูป