ซึ่งเร็วกว่า: if (bool) หรือ if (int)?

ใช้คุ้มค่าไหนดี? บูลีนจริงหรือจำนวนเต็ม 1?

หัวข้อดังกล่าวข้างต้นทำให้ผมทำการทดลองบางคนที่มีboolและintในifสภาพ ดังนั้นฉันจึงเขียนโปรแกรมนี้ด้วยความอยากรู้อยากเห็น:

int f(int i) 
{
    if ( i ) return 99;   //if(int)
    else  return -99;
}
int g(bool b)
{
    if ( b ) return 99;   //if(bool)
    else  return -99;
}
int main(){}

g++ intbool.cpp -S สร้างรหัส asm สำหรับแต่ละฟังก์ชันดังนี้:

• รหัส asm สำหรับ f(int)

  __Z1fi:
     LFB0:
           pushl  %ebp
     LCFI0:
            movl  %esp, %ebp
     LCFI1:
            cmpl  $0, 8(%ebp)
            je    L2
            movl  $99, %eax
            jmp   L3
     L2:
            movl  $-99, %eax
     L3:
            leave
     LCFI2:
            ret
  

• รหัส asm สำหรับ g(bool)

  __Z1gb:
     LFB1:
            pushl %ebp
     LCFI3:
            movl  %esp, %ebp
     LCFI4:
            subl  $4, %esp
     LCFI5:
            movl  8(%ebp), %eax
            movb  %al, -4(%ebp)
            cmpb  $0, -4(%ebp)
            je    L5
            movl  $99, %eax
            jmp   L6
     L5:
            movl  $-99, %eax
     L6:
            leave
     LCFI6:
            ret
  

น่าแปลกใจที่g(bool)สร้างasmคำแนะนำเพิ่มเติม! หมายความว่าif(bool)ช้ากว่าเล็กน้อยif(int)? ฉันเคยคิดว่าboolถูกออกแบบมาโดยเฉพาะเพื่อใช้ในคำสั่งเงื่อนไขเช่นifดังนั้นฉันจึงคาดหวังว่าg(bool)จะสร้างคำสั่ง asm น้อยลงจึงทำให้g(bool)มีประสิทธิภาพและรวดเร็วมากขึ้น

แก้ไข:

ฉันไม่ได้ใช้ค่าสถานะการเพิ่มประสิทธิภาพใด ๆ ณ ตอนนี้ แต่ถึงจะไม่มีมันทำไมมันถึงสร้าง asm ให้มากขึ้นg(bool)เป็นคำถามที่ฉันกำลังมองหาคำตอบที่สมเหตุสมผล ฉันควรบอกคุณด้วยว่า-O2แฟล็กการเพิ่มประสิทธิภาพสร้าง asm เหมือนกันทุกประการ แต่นั่นไม่ใช่คำถาม คำถามคือสิ่งที่ฉันเคยถาม

ทำให้รู้สึกดีกับฉัน เห็นได้ชัดว่าคอมไพเลอร์ของคุณกำหนดboolเป็นค่า 8 บิตและระบบของคุณ ABI กำหนดให้ "เลื่อน" อาร์กิวเมนต์จำนวนเต็มขนาดเล็ก (<32 บิต) เป็น 32 บิตเมื่อผลักดันไปยัง call stack ดังนั้นเพื่อเปรียบเทียบboolคอมไพเลอร์สร้างรหัสเพื่อแยกไบต์ที่สำคัญน้อยที่สุดของอาร์กิวเมนต์ 32 cmpbบิตที่ได้รับกรัมและเปรียบเทียบกับ ในตัวอย่างแรกที่intอาร์กิวเมนต์ใช้เต็มรูปแบบ 32 cmplบิตที่ถูกผลักลงบนสแต็คดังนั้นมันก็เปรียบเทียบกับสิ่งที่ทั้งกับ

การรวบรวม-03จะให้สิ่งต่อไปนี้สำหรับฉัน:

ฉ:

    pushl   %ebp
    movl    %esp, %ebp
    cmpl    $1, 8(%ebp)
    popl    %ebp
    sbbl    %eax, %eax
    andb    $58, %al
    addl    $99, %eax
    ret

g:

    pushl   %ebp
    movl    %esp, %ebp
    cmpb    $1, 8(%ebp)
    popl    %ebp
    sbbl    %eax, %eax
    andb    $58, %al
    addl    $99, %eax
    ret

.. ดังนั้นจึงรวบรวมเป็นหลักรหัสเดียวกันยกเว้นVScmpl cmpbนั่นหมายความว่าความแตกต่างถ้ามีก็ไม่สำคัญ การตัดสินโดยรหัสที่ไม่ได้เพิ่มประสิทธิภาพนั้นไม่ยุติธรรม

แก้ไขเพื่อชี้แจงประเด็นของฉัน รหัสที่ไม่ได้เพิ่มประสิทธิภาพมีไว้สำหรับการดีบักอย่างง่ายไม่ใช่เพื่อความเร็ว การเปรียบเทียบความเร็วของโค้ดที่ไม่ได้เพิ่มประสิทธิภาพนั้นไม่สมเหตุสมผล

เมื่อฉันรวบรวมสิ่งนี้ด้วยชุดตัวเลือกที่มีเหตุผล (โดยเฉพาะ -O3) นี่คือสิ่งที่ฉันได้รับ:

สำหรับf():

        .type   _Z1fi, @function
_Z1fi:
.LFB0:
        .cfi_startproc
        .cfi_personality 0x3,__gxx_personality_v0
        cmpl    $1, %edi
        sbbl    %eax, %eax
        andb    $58, %al
        addl    $99, %eax
        ret
        .cfi_endproc

สำหรับg():

        .type   _Z1gb, @function
_Z1gb:
.LFB1:
        .cfi_startproc
        .cfi_personality 0x3,__gxx_personality_v0
        cmpb    $1, %dil
        sbbl    %eax, %eax
        andb    $58, %al
        addl    $99, %eax
        ret
        .cfi_endproc

พวกเขายังคงใช้คำแนะนำที่แตกต่างกันสำหรับการเปรียบเทียบ ( cmpbสำหรับบูลีนเทียบกับcmplสำหรับ int) แต่อย่างอื่นร่างกายจะเหมือนกัน การดูคู่มือของ Intel อย่างรวดเร็วช่วยบอกฉันว่า: ... ไม่มีอะไรมาก ไม่มีสิ่งที่เรียกว่าcmpbหรือcmplในคู่มือของ Intel พวกเขาทั้งหมดcmpและฉันไม่พบตารางเวลาในขณะนี้ อย่างไรก็ตามฉันคาดเดาว่าไม่มีความแตกต่างของนาฬิการะหว่างการเปรียบเทียบไบต์ทันทีกับการเปรียบเทียบแบบยาวทันทีดังนั้นสำหรับวัตถุประสงค์ในทางปฏิบัติทั้งหมดรหัสจะเหมือนกัน

แก้ไขเพื่อเพิ่มสิ่งต่อไปนี้ตามการเพิ่มของคุณ

สาเหตุที่รหัสแตกต่างกันในกรณีที่ไม่ได้เพิ่มประสิทธิภาพคือรหัสไม่ได้รับการเพิ่มประสิทธิภาพ (ใช่มันเป็นวงกลมฉันรู้) เมื่อคอมไพเลอร์เดินตาม AST และสร้างโค้ดโดยตรงมันจะไม่ "รู้" อะไรเลยนอกจากว่ามีอะไรอยู่ที่จุด AST ในทันที ณ จุดนั้นมันขาดข้อมูลเชิงบริบททั้งหมดที่จำเป็น เพื่อให้ทราบว่า ณ จุดที่เฉพาะเจาะจงนี้สามารถถือว่าประเภทที่ประกาศboolเป็นintไฟล์. โดยค่าเริ่มต้นบูลีนจะถือว่าเป็นไบต์และเมื่อจัดการกับไบต์ในโลกของ Intel คุณต้องทำสิ่งต่าง ๆ เช่น sign-expand เพื่อนำไปยังความกว้างที่กำหนดเพื่อวางลงบนสแต็กเป็นต้น (คุณไม่สามารถพุชไบต์ .)

อย่างไรก็ตามเมื่อเครื่องมือเพิ่มประสิทธิภาพดู AST และใช้เวทมนตร์มันจะดูบริบทโดยรอบและ "รู้" เมื่อสามารถแทนที่โค้ดด้วยสิ่งที่มีประสิทธิภาพมากขึ้นโดยไม่ต้องเปลี่ยนความหมาย ดังนั้นจึง "รู้" ว่าสามารถใช้จำนวนเต็มในพารามิเตอร์และทำให้สูญเสียการแปลงที่ไม่จำเป็นและการขยับขยาย

ด้วย GCC 4.5 บน Linux และ Windows เป็นอย่างน้อย, sizeof(bool) == 1. บน x86 และ x86_64 คุณไม่สามารถส่งผ่านค่ารีจิสเตอร์วัตถุประสงค์ทั่วไปไปยังฟังก์ชันได้น้อยกว่า (ไม่ว่าจะผ่านสแต็กหรือรีจิสเตอร์ขึ้นอยู่กับรูปแบบการโทร ฯลฯ ... )

ดังนั้นโค้ดสำหรับ bool เมื่อไม่ได้รับการปรับให้เหมาะสมจะมีความยาวเพื่อแยกค่าบูลนั้นออกจากกองอาร์กิวเมนต์ (โดยใช้ช่องสแต็กอื่นเพื่อบันทึกไบต์นั้น) มันซับซ้อนกว่าแค่ดึงตัวแปรขนาดรีจิสเตอร์ดั้งเดิม

ที่ระดับเครื่องจะไม่มีบูล

สถาปัตยกรรมชุดคำสั่งน้อยมากที่กำหนดประเภทตัวถูกดำเนินการบูลีนประเภทใดก็ได้แม้ว่ามักจะมีคำสั่งที่ทริกเกอร์การดำเนินการกับค่าที่ไม่ใช่ศูนย์ สำหรับซีพียูโดยทั่วไปทุกอย่างเป็นประเภทสเกลาร์หรือสตริงของพวกเขา

คอมไพเลอร์ที่กำหนดและ ABI ที่กำหนดจะต้องเลือกขนาดเฉพาะสำหรับ intและboolและเมื่อเช่นในกรณีของคุณซึ่งเป็นขนาดที่แตกต่างกันซึ่งอาจสร้างโค้ดที่แตกต่างกันเล็กน้อยและในบางระดับของการเพิ่มประสิทธิภาพอาจเร็วกว่าเล็กน้อย

เหตุใดบูลหนึ่งไบต์ในหลายระบบ

การเลือกcharประเภทของบูลจะปลอดภัยกว่าเนื่องจากอาจมีคนสร้างอาร์เรย์จำนวนมาก

อัปเดต:โดย"ปลอดภัยกว่า"ฉันหมายถึง: สำหรับผู้ใช้คอมไพเลอร์และไลบรารี ฉันไม่ได้บอกว่าคนอื่นต้องติดตั้งระบบประเภทนี้ใหม่

ใช่การอภิปรายเป็นเรื่องสนุก แต่เพียงทดสอบ:

รหัสทดสอบ:

#include <stdio.h>
#include <string.h>

int testi(int);
int testb(bool);
int main (int argc, char* argv[]){
  bool valb;
  int  vali;
  int loops;
  if( argc < 2 ){
    return 2;
  }
  valb = (0 != (strcmp(argv[1], "0")));
  vali = strcmp(argv[1], "0");
  printf("Arg1: %s\n", argv[1]);
  printf("BArg1: %i\n", valb ? 1 : 0);
  printf("IArg1: %i\n", vali);
  for(loops=30000000; loops>0; loops--){
    //printf("%i: %i\n", loops, testb(valb=!valb));
    printf("%i: %i\n", loops, testi(vali=!vali));
  }
  return valb;
}

int testi(int val){
  if( val ){
    return 1;
  }
  return 0;
}
int testb(bool val){
  if( val ){
    return 1;
  }
  return 0;
}

คอมไพล์บนแล็ปท็อป Ubuntu 10.10 64 บิตพร้อมด้วย: g ++ -O3 -o / tmp / test_i /tmp/test_i.cpp

การเปรียบเทียบตามจำนวนเต็ม:

sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.203s
user    0m8.170s
sys 0m0.010s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.056s
user    0m8.020s
sys 0m0.000s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.116s
user    0m8.100s
sys 0m0.000s

การทดสอบบูลีน / การพิมพ์ที่ไม่มีการแสดงความคิดเห็น (และจำนวนเต็มแสดงความคิดเห็น):

sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.254s
user    0m8.240s
sys 0m0.000s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m8.028s
user    0m8.000s
sys 0m0.010s
sauer@trogdor:/tmp$ time /tmp/test_i 1 > /dev/null

real    0m7.981s
user    0m7.900s
sys 0m0.050s

เหมือนกันกับงาน 1 ชิ้นและการเปรียบเทียบ 2 ครั้งในแต่ละลูปมากกว่า 30 ล้านลูป ค้นหาสิ่งอื่นเพื่อเพิ่มประสิทธิภาพ ตัวอย่างเช่นอย่าใช้ strcmp โดยไม่จำเป็น ;)

ส่วนใหญ่จะขึ้นอยู่กับคอมไพเลอร์และการปรับให้เหมาะสม มีการสนทนาที่น่าสนใจ (ไม่เชื่อเรื่องพระเจ้าภาษา) ที่นี่:

"if ([bool] == true)" ต้องการมากกว่าหนึ่งขั้นตอนกว่า "if ([bool])" หรือไม่

ดูที่โพสต์นี้: http://www.linuxquestions.org/questions/programming-9/c-compiler-handling-of-boolean-variables-290996/

เข้าหาคำถามของคุณด้วยสองวิธีที่แตกต่างกัน:

หากคุณกำลังพูดถึง C ++ โดยเฉพาะหรือภาษาโปรแกรมใด ๆ ที่จะสร้างรหัสแอสเซมบลีสำหรับเรื่องนั้นเราจะผูกพันกับโค้ดที่คอมไพเลอร์จะสร้างใน ASM นอกจากนี้เรายังผูกพันกับการแทนค่าจริงและเท็จใน c ++ จำนวนเต็มจะต้องถูกเก็บเป็น 32 บิตและฉันสามารถใช้ไบต์เพื่อเก็บนิพจน์บูลีนได้ ข้อมูลโค้ด Asm สำหรับคำสั่งเงื่อนไข:

สำหรับจำนวนเต็ม:

  mov eax,dword ptr[esp]    ;Store integer
  cmp eax,0                 ;Compare to 0
  je  false                 ;If int is 0, its false
  ;Do what has to be done when true
false:
  ;Do what has to be done when false

สำหรับบูล:

  mov  al,1     ;Anything that is not 0 is true
  test al,1     ;See if first bit is fliped
  jz   false    ;Not fliped, so it's false
  ;Do what has to be done when true
false:
  ;Do what has to be done when false

นั่นเป็นเหตุผลว่าทำไมการเปรียบเทียบความเร็วจึงขึ้นอยู่กับการคอมไพล์ ในกรณีข้างต้นบูลจะเร็วขึ้นเล็กน้อยตั้งแต่นั้นมาcmpจะบ่งบอกถึงการลบสำหรับการตั้งค่าแฟล็ก นอกจากนี้ยังขัดแย้งกับสิ่งที่คอมไพเลอร์ของคุณสร้างขึ้น

อีกวิธีหนึ่งที่ง่ายกว่ามากคือดูตรรกะของนิพจน์ด้วยตัวมันเองและพยายามอย่ากังวลว่าคอมไพเลอร์จะแปลโค้ดของคุณอย่างไรและฉันคิดว่านี่เป็นวิธีคิดที่ดีต่อสุขภาพกว่ามาก ในที่สุดฉันก็ยังเชื่อว่าโค้ดที่คอมไพเลอร์สร้างขึ้นนั้นพยายามที่จะให้การแก้ปัญหาที่เป็นจริง สิ่งที่ฉันหมายถึงคือบางทีถ้าคุณเพิ่มกรณีทดสอบในคำสั่ง if และยึดติดกับบูลีนในด้านหนึ่งและจำนวนเต็มในอีกด้านหนึ่งคอมไพเลอร์จะสร้างมันขึ้นมาเพื่อให้โค้ดที่สร้างขึ้นจะทำงานได้เร็วขึ้นด้วยนิพจน์บูลีนในระดับเครื่อง

ฉันกำลังพิจารณาว่านี่เป็นคำถามเชิงแนวคิดดังนั้นฉันจะให้คำตอบตามแนวคิด การสนทนานี้ทำให้ฉันนึกถึงการอภิปรายที่ฉันมักจะมีเกี่ยวกับประสิทธิภาพของโค้ดแปลเป็นโค้ดในการประกอบน้อยลงหรือไม่ ดูเหมือนว่าแนวคิดนี้เป็นที่ยอมรับกันโดยทั่วไปว่าเป็นเรื่องจริง เมื่อพิจารณาว่าการติดตามว่า ALU จะจัดการกับแต่ละคำสั่งได้เร็วเพียงใดตัวเลือกที่สองคือการมุ่งเน้นไปที่การกระโดดและเปรียบเทียบในการประกอบ เมื่อเป็นเช่นนั้นความแตกต่างระหว่างคำสั่งบูลีนหรือจำนวนเต็มในโค้ดที่คุณนำเสนอจะค่อนข้างเป็นตัวแทน ผลลัพธ์ของนิพจน์ใน C ++ จะส่งกลับค่าที่จะได้รับการเป็นตัวแทน ในการประกอบในทางกลับกัน การกระโดดและการเปรียบเทียบจะขึ้นอยู่กับค่าตัวเลขโดยไม่คำนึงถึงประเภทของนิพจน์ที่ถูกประเมินกลับมาที่คุณ C ++ if statement เป็นสิ่งสำคัญสำหรับคำถามเหล่านี้ที่ต้องจำไว้ว่าข้อความเชิงตรรกะอย่างหมดจดเช่นสิ่งเหล่านี้จบลงด้วยค่าใช้จ่ายในการคำนวณจำนวนมากแม้ว่าบิตเดียวจะสามารถทำสิ่งเดียวกันได้