в то время как (1) против для (;;) Есть ли разница в скорости?

Длинная версия ...

Сотрудник заявил сегодня, увидев мое использование while (1)в сценарии Perl, который for (;;)работает быстрее. Я утверждал, что они должны быть такими же, надеясь, что переводчик оптимизирует любые различия. Я установил скрипт, который будет запускать 1 000 000 000 для итераций цикла и столько же циклов while и записывать время между ними. Я не мог найти никакой заметной разницы. Мой коллега сказал, что профессор сказал ему, что while (1)он сравнивает, 1 == 1а for (;;)нет. Мы повторили тот же тест с 100-кратным числом итераций с C ++, и разница была незначительной. Однако это был графический пример того, насколько быстрее может быть скомпилированный код по сравнению с языком сценариев.

Укороченная версия...

Есть ли какая - либо причина предпочитает while (1)больше , for (;;)если вам нужен бесконечный цикл , чтобы вырваться из?

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

Обновление: вышеупомянутый сотрудник взвесил ответ ниже.

Цитируется здесь на случай, если его похоронят.

Это пришло от ассемблера AMD. Он заявил, что программисты на Си (люди) не понимают, что их код имеет недостатки. Однако сегодня он сказал, что компиляторы gcc очень хороши и выводят таких людей, как он, из бизнеса. Он сказал, например, и рассказал мне о while 1против for(;;). Сейчас я использую его по привычке, но gcc и особенно интерпретаторы будут выполнять одну и ту же операцию (скачок процессора) в течение обоих дней, так как они оптимизированы.

В Perl они дают одинаковые коды операций:

$ perl -MO=Concise -e 'for(;;) { print "foo\n" }'
a  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 2 -e:1) v ->3
9     <2> leaveloop vK/2 ->a
3        <{> enterloop(next->8 last->9 redo->4) v ->4
-        <@> lineseq vK ->9
4           <;> nextstate(main 1 -e:1) v ->5
7           <@> print vK ->8
5              <0> pushmark s ->6
6              <$> const[PV "foo\n"] s ->7
8           <0> unstack v ->4
-e syntax OK

$ perl -MO=Concise -e 'while(1) { print "foo\n" }'
a  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 2 -e:1) v ->3
9     <2> leaveloop vK/2 ->a
3        <{> enterloop(next->8 last->9 redo->4) v ->4
-        <@> lineseq vK ->9
4           <;> nextstate(main 1 -e:1) v ->5
7           <@> print vK ->8
5              <0> pushmark s ->6
6              <$> const[PV "foo\n"] s ->7
8           <0> unstack v ->4
-e syntax OK

Аналогично в GCC:

#include <stdio.h>

void t_while() {
    while(1)
        printf("foo\n");
}

void t_for() {
    for(;;)
        printf("foo\n");
}

    .file   "test.c"
    .section    .rodata
.LC0:
    .string "foo"
    .text
.globl t_while
    .type   t_while, @function
t_while:
.LFB2:
    pushq   %rbp
.LCFI0:
    movq    %rsp, %rbp
.LCFI1:
.L2:
    movl    $.LC0, %edi
    call    puts
    jmp .L2
.LFE2:
    .size   t_while, .-t_while
.globl t_for
    .type   t_for, @function
t_for:
.LFB3:
    pushq   %rbp
.LCFI2:
    movq    %rsp, %rbp
.LCFI3:
.L5:
    movl    $.LC0, %edi
    call    puts
    jmp .L5
.LFE3:
    .size   t_for, .-t_for
    .section    .eh_frame,"a",@progbits
.Lframe1:
    .long   .LECIE1-.LSCIE1
.LSCIE1:
    .long   0x0
    .byte   0x1
    .string "zR"
    .uleb128 0x1
    .sleb128 -8
    .byte   0x10
    .uleb128 0x1
    .byte   0x3
    .byte   0xc
    .uleb128 0x7
    .uleb128 0x8
    .byte   0x90
    .uleb128 0x1
    .align 8
.LECIE1:
.LSFDE1:
    .long   .LEFDE1-.LASFDE1
.LASFDE1:
    .long   .LASFDE1-.Lframe1
    .long   .LFB2
    .long   .LFE2-.LFB2
    .uleb128 0x0
    .byte   0x4
    .long   .LCFI0-.LFB2
    .byte   0xe
    .uleb128 0x10
    .byte   0x86
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI1-.LCFI0
    .byte   0xd
    .uleb128 0x6
    .align 8
.LEFDE1:
.LSFDE3:
    .long   .LEFDE3-.LASFDE3
.LASFDE3:
    .long   .LASFDE3-.Lframe1
    .long   .LFB3
    .long   .LFE3-.LFB3
    .uleb128 0x0
    .byte   0x4
    .long   .LCFI2-.LFB3
    .byte   0xe
    .uleb128 0x10
    .byte   0x86
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI3-.LCFI2
    .byte   0xd
    .uleb128 0x6
    .align 8
.LEFDE3:
    .ident  "GCC: (Ubuntu 4.3.3-5ubuntu4) 4.3.3"
    .section    .note.GNU-stack,"",@progbits

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

Используя GCC, они оба, похоже, компилируются на одном языке ассемблера:

L2:
        jmp     L2

Нет особой причины предпочитать одно другому. Я думаю, что это while(1)особенно while(true)читабельно for(;;), но это мое предпочтение.

Там нет разницы по стандарту. 6.5.3 / 1 имеет:

Для заявления

for ( for-init-statement ; conditionopt ; expressionopt ) statement

эквивалентно

{
  for-init-statement
  while ( condition ) {
    statement
    expression ;
  }
}

И 6.5.3 / 2 имеет:

Любое или оба условия и выражения могут быть опущены. Отсутствующее условие делает подразумеваемое предложение while эквивалентным while (true).

Итак, в соответствии со стандартом C ++ код:

for (;;);

точно так же, как:

{
  while (true) {
    ;
    ;
  }
}

Компилятор Visual C ++ используется для предупреждения

while (1) 

(постоянное выражение), но не для

for (;;)

Я продолжил практику предпочтения for (;;)по этой причине, но я не знаю, по-прежнему ли это делает компилятор в наши дни.

for(;;) на один символ меньше, если вы хотите пойти в этом направлении, чтобы оптимизировать вещи.

Turbo C с этим старым компилятором for(;;)приводит к более быстрому коду while(1).

Сегодня компиляторы gcc, Visual C (я думаю, почти все) хорошо оптимизируются, а процессоры с частотой 4,7 МГц используются редко.

В те дни a for( i=10; i; i-- )был быстрее, чем for( i=1; i <=10; i++ ), потому что сравнение iравно 0, приводит к условному переходу CPU-Zero-Flag. И Zero-Flag был изменен с последней операцией декремента ( i-- ), никакой дополнительной операции cmp не требуется.

    call    __printf_chk
    decl    %ebx          %ebx=iterator i 
    jnz     .L2
    movl    -4(%ebp), %ebx
    leave

а вот for(i=1; i<=10; i++)с дополнительным cmpl:

    call    __printf_chk
    incl    %ebx
    cmpl    $11, %ebx
    jne     .L2
    movl    -4(%ebp), %ebx
    leave

Для всех людей, утверждающих, что вы не должны использовать неопределенные циклы while, и предлагать глупые вещи, такие как использование open goto 's (серьезно, ой)

while (1) {
     last if( condition1 );
     code();
     more_code(); 
     last if( condition2 ); 
     even_more_code(); 
}

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

Если у вас есть склонность к более сложному синтаксису, используйте что-то вменяемое, что ограничивает область действия.

flow: { 

   if ( condition ){ 
      redo flow;
   }
   if ( othercondition ){ 
       redo flow;
   }
   if ( earlyexit ){ 
       last flow;
   }
   something(); # doesn't execute when earlyexit is true 
}

В конечном счете, скорость не так важна

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

Обычно это как цикла и как цикла.

Вы должны «оптимизировать» читабельность и лаконичность, и написать все, что лучше при объяснении проблемы, следующему бедному обманщику, который найдет ваш код.

Если вы используете трюк "goto LABEL", о котором кто-то упоминал, и я должен использовать ваш код, будьте готовы спать с одним открытым глазом, особенно если вы делаете это более одного раза, потому что такого рода вещи создают ужасно спагетти-код.

То, что вы можете создать код для спагетти, не означает, что вы должны

От Страуструпа, TC ++ PL (3-е издание), §6.1.1:

Любопытная нотация for (;;)- это стандартный способ задания бесконечного цикла; Вы могли бы произнести это "навсегда". [...] while (true)альтернатива.

Я предпочитаю for (;;).

Если компилятор не выполняет оптимизацию, for(;;)он всегда будет быстрее, чемwhile(true) . Это связано с тем, что оператор while оценивает условие каждый раз, а оператор for - безусловный переход. Но если компилятор оптимизирует поток управления, он может генерировать некоторые коды операций. Вы можете прочитать код разборки очень легко.

PS вы могли бы написать бесконечный цикл, как это:

#define EVER ;;
  //...
  for (EVER) {
    //...
  }

Я слышал об этом однажды.

Это пришло от ассемблера AMD. Он заявил, что программисты на C (люди) не осознают, что их код неэффективен. Однако сегодня он сказал, что компиляторы gcc очень хороши и выводят таких людей, как он, из бизнеса. Он сказал, например, и рассказал мне о while 1против for(;;). Сейчас я использую его по привычке, но gcc и особенно интерпретаторы будут выполнять одну и ту же операцию (скачок процессора) в течение обоих дней, так как они оптимизированы.

В оптимизированной сборке скомпилированного языка не должно быть заметного различия между ними. Никто не должен выполнять какие-либо сравнения во время выполнения, они просто будут выполнять код цикла, пока вы не выйдете из цикла вручную (например, с помощью a break).

Я удивлен , что никто должным образом не тестировался в for (;;)сравнении while (1)с Perl!

Поскольку perl является интерпретируемым языком, время запуска сценария perl состоит не только из фазы выполнения (которая в этом случае одинакова), но и из фазы интерпретации перед выполнением. Обе эти фазы должны быть приняты во внимание при сравнении скорости.

К счастью, в Perl есть удобный модуль Benchmark, который мы можем использовать для реализации теста:

#!/usr/bin/perl -w

use Benchmark qw( cmpthese );

sub t_for   { eval 'die; for (;;) { }'; }
sub t_for2  { eval 'die; for (;;)  { }'; }
sub t_while { eval 'die; while (1) { }'; }

cmpthese(-60, { for => \&t_for, for2 => \&t_for2, while => \&t_while });

Обратите внимание, что я тестирую две разные версии бесконечного цикла for: одну, которая короче, чем цикл while, и другую, которая имеет дополнительный пробел, чтобы сделать его такой же длины, как цикл while.

На Ubuntu 11.04 x86_64 с Perl 5.10.1 я получаю следующие результаты:

          Оценить для for2 время
для 100588 / с - -0% -2%
для 2 100937 / с 0% - -1%
в то время как 102147 / с 2% 1% -

Цикл while явно выиграл на этой платформе.

На FreeBSD 8.2 x86_64 с Perl 5.14.1:

         Оценить для for2 время
для 53453 / с - -0% -2%
для 2 53552 / с 0% - -2%
в то время как 54564 / с 2% 2% -

Хотя цикл здесь тоже победитель.

На FreeBSD 8.2 i386 с Perl 5.14.1:

         Оцените пока для for2
при 24311 / с - -1% -1%
для 24481 / с 1% - -1%
для 2 24637 / с 1% 1% -

Удивительно, но цикл for с дополнительным пробелом - самый быстрый выбор здесь!

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

Теоретически, полностью наивный компилятор может хранить литерал '1' в двоичном коде (тратить пространство) и проверять, равен ли 1 == 0 на каждой итерации (тратить время и больше места).

В действительности, однако, даже с оптимизацией «без» компиляторы все равно будут сводить оба к одному и тому же. Они также могут выдавать предупреждения, поскольку это может указывать на логическую ошибку. Например, аргумент whileможет быть определен где-то еще, и вы не понимаете, что это константа.

Я удивлен, что никто не предложил более прямую форму, соответствующую желаемой сборке:

forever:
     do stuff;
     goto forever;

while(1)это идиома, за for(;;)которую признают большинство компиляторов.

Я был рад видеть, что Perl until(0)тоже распознает .

Подводя итог дебатам for (;;)против while (1), очевидно, что первый был быстрее во времена старых неоптимизирующих компиляторов, поэтому вы склонны видеть его в более старых базах кода, таких как комментарии к исходному коду Lions Unix, однако в эпоху оптимизации компиляторы эти выгоды оптимизируются в сочетании с тем, что последний легче понять, чем первый, я считаю, что это было бы более предпочтительным.

Просто наткнулся на эту ветку (хотя и опоздал на несколько лет).

Я думаю, что нашел реальную причину, по которой «for (;;)» лучше, чем «while (1)».

в соответствии со «стандартом кодирования barr 2018»

Kernighan & Ritchie long ago recommended for (;;) , which has the additional benefit
of insuring against the visually-confusing defect of a while (l); referencing a variable ‘l’.

в основном это не проблема скорости, а проблема читабельности. В зависимости от шрифта / печати кода число один (1) через некоторое время может выглядеть как строчная буква l.

т.е. 1 против л. (в некоторых шрифтах они выглядят одинаково).

Так что while (1) может выглядеть как цикл while, зависящий от переменной L.

Хотя (true) также может работать, но в некоторых старых случаях C и встроенного C true / false еще не определены, если не включен stdbool.h.

Я думаю, что оба одинаковы с точки зрения производительности. Но я бы предпочел while (1) для удобства чтения, но я спрашиваю, зачем вам нужен бесконечный цикл.

Они одинаковые. Есть гораздо более важные вопросы для размышления.