Оператор if vs if-else, который быстрее?

Ответ 1

TL; DR: В неоптимизированном коде if без else кажется неуместным более эффективным, но даже с самым базовым уровнем оптимизации, код в основном переписан на value = condition + 5.

I дал ему попробовать и сгенерировал сборку для следующего кода:

int ifonly(bool condition, int value)
{
    value = 5;
    if (condition) {
        value = 6;
    }
    return value;
}

int ifelse(bool condition, int value)
{
    if (condition) {
        value = 6;
    } else {
        value = 5;
    }
    return value;
}

В gcc 6.3 с отключенными оптимизациями (-O0) соответствующее различие заключается в следующем:

 mov     DWORD PTR [rbp-8], 5
 cmp     BYTE PTR [rbp-4], 0
 je      .L2
 mov     DWORD PTR [rbp-8], 6
.L2:
 mov     eax, DWORD PTR [rbp-8]

для ifonly, а ifelse имеет

 cmp     BYTE PTR [rbp-4], 0
 je      .L5
 mov     DWORD PTR [rbp-8], 6
 jmp     .L6
.L5:
 mov     DWORD PTR [rbp-8], 5
.L6:
 mov     eax, DWORD PTR [rbp-8]

Последний выглядит немного менее эффективным, потому что он имеет дополнительный прыжок, но оба имеют как минимум два и не более трех назначений, поэтому, если вам действительно не нужно сжимать каждую последнюю производительность (подсказка: если вы не работаете на космическом шасси, вы нет, и даже тогда вы, вероятно, этого не сделаете) разница не будет заметной.

Однако даже при самом низком уровне оптимизации (-O1) обе функции сводятся к одному и тому же:

test    dil, dil
setne   al
movzx   eax, al
add     eax, 5

что в основном эквивалентно

return 5 + condition;

Предполагая, что condition равно нулю или одному. Более высокие уровни оптимизации на самом деле не изменяют результат, за исключением того, что они избегают movzx, эффективно обнуляя регистр EAX в начале.

Отказ от ответственности: Вы, вероятно, не должны писать 5 + condition самостоятельно (хотя стандарт гарантирует, что преобразование true в целочисленный тип дает 1), потому что ваше намерение может быть не сразу очевидным людям, читающим ваш код (который может включать ваше будущее). Точка этого кода должна показать, что то, что производит компилятор в обоих случаях, (практически) идентично. Ciprian Tomoiaga достаточно хорошо говорит в комментариях:

a человеческое задание - написать код для людей и позволить компилятору писать код для машины.

Ответ 2

Ответ от CompuChip показывает, что для int оба они оптимизированы для одной и той же сборки, поэтому это не имеет значения.

Что делать, если значение является матрицей?

Я буду интерпретировать это более общим образом, т.е. что, если value имеет тип, конструкции и назначения которого дороги (и ходы дешевы).

затем

T value = init1;
if (condition)
   value = init2;

является субоптимальным, поскольку в случае, если condition истинно, вы делаете ненужную инициализацию на init1, а затем выполняете назначение копии.

T value;
if (condition)
   value = init2;
else
   value = init3;

Это лучше. Но все еще не оптимально, если построение по умолчанию дорогое, и если построение копии дороже, то инициализация.

У вас есть условное операторное решение, которое хорошо:

T value = condition ? init1 : init2;

Но я бы защищал создание такой вспомогательной функции, как это:

T create(bool condition)
{
  if (condition)
     return {init1};
  else
     return {init2};
}

T value = create(condition);

Но опять же я должен подчеркнуть, что это имеет значение только тогда, когда построение и присвоения действительно дороги для данного типа. И даже тогда, только профилирование, вы точно знаете.

Ответ 3

В неоптимизированном коде первый пример присваивает переменную всегда один раз, а иногда и дважды. Второй пример только присваивает переменную один раз. Условное одно и то же на обоих кодах, так что это не имеет значения. В оптимизированном коде это зависит от компилятора.

Как всегда, если вы заинтересованы, сгенерируйте сборку и посмотрите, что делает на самом деле компилятор.

Ответ 4

В языке псевдоассоциирования

    li    #0, r0
    test  r1
    beq   L1
    li    #1, r0
L1:

может быть или не быть быстрее, чем

    test  r1
    beq   L1
    li    #1, r0
    bra   L2
L1:
    li    #0, r0
L2:

в зависимости от того, насколько сложным является фактический процессор. Переход от простейшего к фантастическому:

• С любым процессором, производимым примерно после 1990 года, хорошая производительность зависит от установки кода в кэше инструкций. Поэтому в сомнении минимизируйте размер кода. Это весит в пользу первого примера.

• С базовым в порядке, пятиступенчатым конвейером "CPU, который по-прежнему примерно совпадает с тем, что вы получаете во многих микроконтроллеров, существует конвейерный пузырь каждый раз, когда выполняется ветвь-условное или безусловное - поэтому важно также минимизировать количество ветвей инструкции. Это также весит в пользу первого примера.

• Несколько более сложные процессоры - достаточно для того, чтобы сделать " исполнение вне порядка", но недостаточно для использования наиболее известные реализации этой концепции - могут возникать пузырьки трубопровода, когда они сталкиваются с опасностями write-after-write. Это весит в пользу второго примера, где r0 записывается только один раз независимо от того, что. Эти процессоры обычно достаточно хороши для обработки безусловных ветвей в наборе команд, поэтому вы не просто торгуете штрафом за запись после штрафа за ветку.

  Я не знаю, все ли кто-то еще делает такой процессор. Тем не менее, процессоры, которые используют "самые известные реализации" исполнения вне порядка, скорее всего, сократят углы на менее часто используемых инструкциях, поэтому вам нужно знать, что такое может случиться. Реальный пример: ложные зависимости данных от целевых регистров в popcnt и lzcnt на процессорах Sandy Bridge.

• В самом верхнем конце двигатель OOO завершает выдачу точно такой же последовательности внутренних операций для обоих фрагментов кода - это аппаратная версия "не беспокойтесь об этом, компилятор будет генерировать то же самое машинный код в любом случае". Однако размер кода по-прежнему имеет значение, и теперь вы также должны беспокоиться о предсказуемости условной ветки. Отклонения в ветки отказы потенциально могут привести к полному потоку трубопровода, что катастрофично для производительности; см. Почему быстрее обрабатывать отсортированный массив, чем несортированный массив?, чтобы понять, насколько это может сделать разница.

  Если ветвь очень непредсказуема, и ваш процессор имеет команды с условным набором или условным перемещением, настало время их использовать:

      li    #0, r0
      test  r1
      setne r0
  

  или

      li    #0, r0
      li    #1, r2
      test  r1
      movne r2, r0
  

  Условная версия также более компактна, чем любая другая альтернатива; если эта инструкция доступна, она практически гарантирована как правильная вещь для этого сценария, даже если ветвь была предсказуемой. Для версии условного перемещения требуется дополнительный регистр нуля и всегда тратит одну команду li на отправку и выполнение ресурсов; если ветвь на самом деле предсказуема, разветвленная версия может быть быстрее.

Ответ 5

Что заставило бы вас думать, что любой из них даже один лайнер работает быстрее или медленнее?

unsigned int fun0 ( unsigned int condition, unsigned int value )
{
    value = 5;
    if (condition) {
        value = 6;
    }
    return(value);
}
unsigned int fun1 ( unsigned int condition, unsigned int value )
{

    if (condition) {
        value = 6;
    } else {
        value = 5;
    }
    return(value);
}
unsigned int fun2 ( unsigned int condition, unsigned int value )
{
    value = condition ? 6 : 5;
    return(value);
}

Другие строки кода языка высокого уровня дают компилятору больше работать, поэтому, если вы хотите сделать общее правило, это даст компилятору больше кода для работы. Если алгоритм будет таким же, как и в случае выше, то можно ожидать, что компилятор с минимальной оптимизацией сможет понять это.

00000000 <fun0>:
   0:   e3500000    cmp r0, #0
   4:   03a00005    moveq   r0, #5
   8:   13a00006    movne   r0, #6
   c:   e12fff1e    bx  lr

00000010 <fun1>:
  10:   e3500000    cmp r0, #0
  14:   13a00006    movne   r0, #6
  18:   03a00005    moveq   r0, #5
  1c:   e12fff1e    bx  lr

00000020 <fun2>:
  20:   e3500000    cmp r0, #0
  24:   13a00006    movne   r0, #6
  28:   03a00005    moveq   r0, #5
  2c:   e12fff1e    bx  lr

не большой сюрприз, он сделал первую функцию в другом порядке, такое же время выполнения.

0000000000000000 <fun0>:
   0:   7100001f    cmp w0, #0x0
   4:   1a9f07e0    cset    w0, ne
   8:   11001400    add w0, w0, #0x5
   c:   d65f03c0    ret

0000000000000010 <fun1>:
  10:   7100001f    cmp w0, #0x0
  14:   1a9f07e0    cset    w0, ne
  18:   11001400    add w0, w0, #0x5
  1c:   d65f03c0    ret

0000000000000020 <fun2>:
  20:   7100001f    cmp w0, #0x0
  24:   1a9f07e0    cset    w0, ne
  28:   11001400    add w0, w0, #0x5
  2c:   d65f03c0    ret

Надеюсь, вы поняли, что могли бы просто попробовать это, если бы не было очевидно, что разные реализации на самом деле не были разными.

Что касается матрицы, не знаю, как это важно,

if(condition)
{
 big blob of code a
}
else
{
 big blob of code b
}

просто собирается поставить ту же оболочку if-then-else вокруг больших блоков кода, если они будут стоить = 5 или что-то более сложное. Аналогично сравнению, даже если это большой код кода, он все равно должен быть вычислен и равен или не равен чему-то, часто компилируется с отрицанием, если (условие) что-то часто компилируется, как если бы не условие goto.

00000000 <fun0>:
   0:   0f 93           tst r15     
   2:   03 24           jz  $+8         ;abs 0xa
   4:   3f 40 06 00     mov #6, r15 ;#0x0006
   8:   30 41           ret         
   a:   3f 40 05 00     mov #5, r15 ;#0x0005
   e:   30 41           ret         

00000010 <fun1>:
  10:   0f 93           tst r15     
  12:   03 20           jnz $+8         ;abs 0x1a
  14:   3f 40 05 00     mov #5, r15 ;#0x0005
  18:   30 41           ret         
  1a:   3f 40 06 00     mov #6, r15 ;#0x0006
  1e:   30 41           ret         

00000020 <fun2>:
  20:   0f 93           tst r15     
  22:   03 20           jnz $+8         ;abs 0x2a
  24:   3f 40 05 00     mov #5, r15 ;#0x0005
  28:   30 41           ret         
  2a:   3f 40 06 00     mov #6, r15 ;#0x0006
  2e:   30 41

мы только что прошли это упражнение с кем-то еще недавно в stackoverflow. этот компилятор mips интересно, в этом случае не только реализовано, что функции были одинаковыми, но одна функция просто переходила к другой, чтобы сэкономить на кодовом пространстве. Не делал этого здесь, хотя

00000000 <fun0>:
   0:   0004102b    sltu    $2,$0,$4
   4:   03e00008    jr  $31
   8:   24420005    addiu   $2,$2,5

0000000c <fun1>:
   c:   0004102b    sltu    $2,$0,$4
  10:   03e00008    jr  $31
  14:   24420005    addiu   $2,$2,5

00000018 <fun2>:
  18:   0004102b    sltu    $2,$0,$4
  1c:   03e00008    jr  $31
  20:   24420005    addiu   $2,$2,5

еще несколько целей.

00000000 <_fun0>:
   0:   1166            mov r5, -(sp)
   2:   1185            mov sp, r5
   4:   0bf5 0004       tst 4(r5)
   8:   0304            beq 12 <_fun0+0x12>
   a:   15c0 0006       mov $6, r0
   e:   1585            mov (sp)+, r5
  10:   0087            rts pc
  12:   15c0 0005       mov $5, r0
  16:   1585            mov (sp)+, r5
  18:   0087            rts pc

0000001a <_fun1>:
  1a:   1166            mov r5, -(sp)
  1c:   1185            mov sp, r5
  1e:   0bf5 0004       tst 4(r5)
  22:   0204            bne 2c <_fun1+0x12>
  24:   15c0 0005       mov $5, r0
  28:   1585            mov (sp)+, r5
  2a:   0087            rts pc
  2c:   15c0 0006       mov $6, r0
  30:   1585            mov (sp)+, r5
  32:   0087            rts pc

00000034 <_fun2>:
  34:   1166            mov r5, -(sp)
  36:   1185            mov sp, r5
  38:   0bf5 0004       tst 4(r5)
  3c:   0204            bne 46 <_fun2+0x12>
  3e:   15c0 0005       mov $5, r0
  42:   1585            mov (sp)+, r5
  44:   0087            rts pc
  46:   15c0 0006       mov $6, r0
  4a:   1585            mov (sp)+, r5
  4c:   0087            rts pc

00000000 <fun0>:
   0:   00a03533            snez    x10,x10
   4:   0515                    addi    x10,x10,5
   6:   8082                    ret

00000008 <fun1>:
   8:   00a03533            snez    x10,x10
   c:   0515                    addi    x10,x10,5
   e:   8082                    ret

00000010 <fun2>:
  10:   00a03533            snez    x10,x10
  14:   0515                    addi    x10,x10,5
  16:   8082                    ret

и компиляторы

с этим кодом я можно было бы ожидать, что различные цели будут также соответствовать

define i32 @fun0(i32 %condition, i32 %value) #0 {
  %1 = icmp ne i32 %condition, 0
  %. = select i1 %1, i32 6, i32 5
  ret i32 %.
}

; Function Attrs: norecurse nounwind readnone
define i32 @fun1(i32 %condition, i32 %value) #0 {
  %1 = icmp eq i32 %condition, 0
  %. = select i1 %1, i32 5, i32 6
  ret i32 %.
}

; Function Attrs: norecurse nounwind readnone
define i32 @fun2(i32 %condition, i32 %value) #0 {
  %1 = icmp ne i32 %condition, 0
  %2 = select i1 %1, i32 6, i32 5
  ret i32 %2
}


00000000 <fun0>:
   0:   e3a01005    mov r1, #5
   4:   e3500000    cmp r0, #0
   8:   13a01006    movne   r1, #6
   c:   e1a00001    mov r0, r1
  10:   e12fff1e    bx  lr

00000014 <fun1>:
  14:   e3a01006    mov r1, #6
  18:   e3500000    cmp r0, #0
  1c:   03a01005    moveq   r1, #5
  20:   e1a00001    mov r0, r1
  24:   e12fff1e    bx  lr

00000028 <fun2>:
  28:   e3a01005    mov r1, #5
  2c:   e3500000    cmp r0, #0
  30:   13a01006    movne   r1, #6
  34:   e1a00001    mov r0, r1
  38:   e12fff1e    bx  lr


fun0:
    push.w  r4
    mov.w   r1, r4
    mov.w   r15, r12
    mov.w   #6, r15
    cmp.w   #0, r12
    jne .LBB0_2
    mov.w   #5, r15
.LBB0_2:
    pop.w   r4
    ret

fun1:
    push.w  r4
    mov.w   r1, r4
    mov.w   r15, r12
    mov.w   #5, r15
    cmp.w   #0, r12
    jeq .LBB1_2
    mov.w   #6, r15
.LBB1_2:
    pop.w   r4
    ret


fun2:
    push.w  r4
    mov.w   r1, r4
    mov.w   r15, r12
    mov.w   #6, r15
    cmp.w   #0, r12
    jne .LBB2_2
    mov.w   #5, r15
.LBB2_2:
    pop.w   r4
    ret

В настоящее время технически существует разница в производительности в некоторых из этих решений, иногда в результате получается 5 случаев, когда скачок по результату составляет 6 кодов, и наоборот, является ветвью быстрее, чем выполнение? можно утверждать, но исполнение должно меняться. Но это скорее условие if vs, если не условие в коде, в результате чего компилятор делает, если этот переход через else выполняется. но это не обязательно связано с стилем кодирования, но сравнение и случаи if и else в любом синтаксисе.

Ответ 6

Хорошо, поскольку сборка является одним из тегов, я просто предполагаю, что ваш код является псевдокодом (а не обязательно c) и переводит его человеком в сборку 6502.

1-й вариант (без дополнительного)

        ldy #$00
        lda #$05
        dey
        bmi false
        lda #$06
false   brk

Второй вариант (с другим)

        ldy #$00
        dey
        bmi else
        lda #$06
        sec
        bcs end
else    lda #$05
end     brk

Предположения: Условие находится в регистре Y, установите это значение 0 или 1 в первой строке любой опции, результат будет в аккумуляторе.

Итак, после подсчета циклов для обеих возможностей каждого случая, мы видим, что 1-я конструкция, как правило, быстрее; 9 циклов, когда условие равно 0 и 10 циклам, когда условие равно 1, тогда как второй вариант также 9 циклов, когда условие равно 0, но 13 циклов, когда условие равно 1. (количество циклов не включает в себя BRK в конце).

Вывод: If only быстрее, чем If-Else.

И для полноты, это оптимизированное решение value = condition + 5:

ldy #$00
lda #$00
tya
adc #$05
brk

Это сокращает наше время до 8 циклов (опять же, не включая BRK в конце).

Ответ 7

Оператор if работает немного быстрее, потому что, когда мы преобразуем этот код в язык ассемблера, if else выполняет дополнительный скачок, тогда как if имеет назначение. Переход занимает дополнительное время, а назначение выполняется быстро.