podczas gdy (1) Vs. dla (;;) Czy istnieje różnica prędkości?

Długa wersja...

Pewien współpracownik zapewnił mnie dzisiaj po obejrzeniu mojego użycia while (1)w skrypcie Perla, który for (;;)jest szybszy. Argumentowałem, że powinny być takie same, mając nadzieję, że tłumacz zoptymalizuje wszelkie różnice. Skonfigurowałem skrypt, który będzie uruchamiał 1 000 000 000 dla iteracji pętli i tej samej liczby pętli while i rejestruje czas między nimi. Nie mogłem znaleźć żadnej znaczącej różnicy. Mój współpracownik powiedział, że profesor powiedział mu, że while (1)robi porównanie, 1 == 1a for (;;)nie. Powtórzyliśmy ten sam test przy 100-krotnej liczbie iteracji w C ++ i różnica była nieistotna. Był to jednak graficzny przykład tego, o ile szybciej można skompilować kod w porównaniu z językiem skryptowym.

Krótka wersja...

Czy jest jakiś powód, aby preferować a while (1)over a, for (;;)jeśli potrzebujesz nieskończonej pętli, z której chcesz się wyrwać?

Uwaga: jeśli nie wynika to jasno z pytania. To była czysto zabawna dyskusja akademicka między kilkoma przyjaciółmi. Zdaję sobie sprawę, że nie jest to super ważna koncepcja, nad którą wszyscy programiści powinni się męczyć. Dzięki za wszystkie świetne odpowiedzi. Ja (i jestem pewien, że inni) nauczyłem się kilku rzeczy z tej dyskusji.

Aktualizacja: Wspomniany wyżej współpracownik odniósł się do odpowiedzi poniżej.

Cytowany tutaj na wypadek, gdyby został zakopany.

Pochodzi od programisty zespołu AMD. Stwierdził, że programiści C (ludzie) nie zdają sobie sprawy, że ich kod jest nieefektywny. Powiedział jednak dzisiaj, że kompilatory gcc są bardzo dobre i pozbawiają ludzi takich jak on interes. Powiedział na przykład, i powiedział mi o while 1vs for(;;). Używam go teraz z przyzwyczajenia, ale gcc, a zwłaszcza interpretery, będą wykonywać tę samą operację (skok procesora) przez oba te dni, ponieważ są zoptymalizowane.

W perlu dają te same rozkazy:

$ 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

Podobnie w 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

Więc myślę, że odpowiedź brzmi: są takie same w wielu kompilatorach. Oczywiście w przypadku niektórych innych kompilatorów niekoniecznie tak musi być, ale jest szansa, że ​​kod wewnątrz pętli i tak będzie kilka tysięcy razy droższy niż sama pętla, więc kogo to obchodzi?

Używając GCC, oba wydają się kompilować do tego samego języka asemblera:

L2:
        jmp     L2

Nie ma powodu, aby preferować jedno nad drugim. I sądzę, że while(1)w szczególności while(true)są bardziej czytelne niż for(;;), ale to tylko moje preferencje.

Nie ma różnicy w stosunku do normy. 6.5.3 / 1 ma:

Oświadczenie za

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

jest równa

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

A 6.5.3 / 2 ma:

Można pominąć jeden lub oba warunek i wyrażenie. Brak warunku sprawia, że ​​domniemana klauzula while jest równoważna while (prawda).

Czyli zgodnie ze standardem C ++ kod:

for (;;);

jest dokładnie taki sam jak:

{
  while (true) {
    ;
    ;
  }
}

Kompilator Visual C ++ używany do emitowania ostrzeżenia dla platformy

while (1) 

(wyrażenie stałe), ale nie dla

for (;;)

Z for (;;)tego powodu kontynuowałem praktykę preferowania , ale nie wiem, czy kompilator nadal to robi.

for(;;) jest o jeden znak mniej do wpisania, jeśli chcesz iść w tym kierunku, aby zoptymalizować rzeczy.

Turbo C z tymi starymi kompilatorami for(;;)skutkuje szybszym kodem while(1).

Dzisiaj kompilatory gcc, Visual C (chyba prawie wszystkie) optymalizują się dobrze, a procesory o częstotliwości 4,7 MHz są rzadko używane.

W tamtych czasach a for( i=10; i; i-- )było szybsze niż for( i=1; i <=10; i++ ), ponieważ porównanie iwynosi 0, powoduje warunkowy skok CPU-Zero-Flag. Flaga zera została zmodyfikowana podczas ostatniej operacji dekrementacji ( i-- ), nie jest potrzebna żadna dodatkowa operacja cmp.

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

a tutaj for(i=1; i<=10; i++)z dodatkowym cmpl:

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

Dla wszystkich ludzi, którzy argumentują, że nie powinieneś używać indefinte while i sugerują głupie rzeczy, takie jak używanie otwartego goto (serio, ouch)

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

Tak naprawdę nie można go skutecznie przedstawić w żaden inny sposób. Nie bez utworzenia zmiennej wyjściowej i zrobienia czarnej magii, aby ją zsynchronizować.

Jeśli masz skłonność do składni bardziej goto-esque, użyj czegoś rozsądnego, co ogranicza zakres.

flow: { 

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

Ostatecznie szybkość nie jest taka ważna

Martwienie się o to, jak efektywne pod względem szybkości są różne konstrukcje pętli, jest ogromną stratą czasu. Przedwczesna optymalizacja na wskroś. Nie przychodzi mi do głowy żadna sytuacja, jaką kiedykolwiek widziałem, w której kod profilujący znalazłby wąskie gardła w moim wyborze konstrukcji pętli.

Ogólnie jest to jak pętla i co z pętli.

Powinieneś "zoptymalizować" pod kątem czytelności i zwięzłości oraz napisać wszystko, co najlepiej wyjaśni problem następnemu biednemu frajerowi, który znajdzie twój kod.

Jeśli używasz sztuczki „goto LABEL”, o której ktoś wspomniał, a ja muszę użyć twojego kodu, przygotuj się na spanie z jednym okiem otwartym, zwłaszcza jeśli robisz to więcej niż raz, ponieważ takie rzeczy tworzą okropny kod spaghetti.

Tylko dlatego, że można tworzyć spaghetti code nie znaczy, że powinniśmy

Stroustrup, TC ++ PL (wydanie trzecie), §6.1.1:

Ciekawa notacja for (;;)jest standardowym sposobem określenia nieskończonej pętli; można by to wymówić „na zawsze”. […] while (true)jest alternatywą.

Wolę for (;;).

Jeśli kompilator nie przeprowadza żadnej optymalizacji, for(;;)zawsze będzie szybszy niż while(true). Dzieje się tak, ponieważ instrukcja while oblicza warunek za każdym razem, ale instrukcja for jest bezwarunkowym skokiem. Ale jeśli kompilator zoptymalizuje przepływ sterowania, może wygenerować niektóre rozkazy. Możesz bardzo łatwo odczytać kod demontażu.

PS możesz napisać nieskończoną pętlę w ten sposób:

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

Słyszałem o tym kiedyś.

Pochodzi od programisty zespołu AMD. Stwierdził, że programiści C (ludzie) nie zdają sobie sprawy, że ich kod jest nieefektywny. Powiedział jednak dzisiaj, że kompilatory gcc są bardzo dobre i pozbawiają ludzi takich jak on interes. Powiedział na przykład, i powiedział mi o while 1vs for(;;). Używam go teraz z przyzwyczajenia, ale gcc, a zwłaszcza interpretery, będą wykonywać tę samą operację (skok procesora) przez oba te dni, ponieważ są zoptymalizowane.

W zoptymalizowanej wersji skompilowanego języka nie powinno być między nimi zauważalnej różnicy. Żadne z nich nie powinno kończyć się przeprowadzaniem jakichkolwiek porównań w czasie wykonywania, po prostu wykonają kod pętli, dopóki ręcznie nie wyjdziesz z pętli (np. Za pomocą a break).

Dziwię się, że nikt właściwie przetestowane for (;;)kontra while (1)Perl!

Ponieważ perl jest językiem interpretowanym, czas potrzebny na uruchomienie skryptu w Perlu składa się nie tylko z fazy wykonania (która w tym przypadku jest taka sama), ale także z fazy interpretacji przed wykonaniem. Przy porównywaniu prędkości należy wziąć pod uwagę obie te fazy.

Na szczęście perl ma wygodny moduł Benchmark, za pomocą którego możemy zaimplementować benchmark, taki jak:

#!/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 });

Zauważ, że testuję dwie różne wersje nieskończonej pętli for: jedną, która jest krótsza niż pętla while, i drugą, która ma dodatkową przestrzeń, aby uzyskać taką samą długość jak pętla while.

Na Ubuntu 11.04 x86_64 z perlem 5.10.1 otrzymuję następujące wyniki:

          Stawka za 2 chwilę
dla 100588 / s - -0% -2%
dla2 100937 / s 0% - -1%
podczas gdy 102147 / s 2% 1% -

Pętla while jest zdecydowanie zwycięzcą na tej platformie.

We FreeBSD 8.2 x86_64 z perlem 5.14.1:

         Stawka za 2 chwilę
dla 53453 / s - -0% -2%
dla2 53552 / s 0% - -2%
podczas gdy 54564 / s 2% 2% -

Podczas gdy pętla jest tutaj również zwycięzcą.

W FreeBSD 8.2 i386 z perl 5.14.1:

         Oceniaj za for2
podczas gdy 24311 / s - -1% -1%
dla 24481 / s 1% - -1%
dla2 24637 / s 1% 1% -

Zaskakujące jest, że pętla for z dodatkową przestrzenią jest tutaj najszybszym wyborem!

Mój wniosek jest taki, że pętla while powinna być używana na platformie x86_64, jeśli programista optymalizuje pod kątem szybkości. Oczywiście pętla for powinna być używana podczas optymalizacji przestrzeni. Moje wyniki są niestety niejednoznaczne w odniesieniu do innych platform.

Teoretycznie całkowicie naiwny kompilator mógłby przechowywać dosłowne „1” w pliku binarnym (marnowanie miejsca) i sprawdzać, czy 1 == 0 w każdej iteracji (marnowanie czasu i więcej miejsca).

Jednak w rzeczywistości, nawet przy braku optymalizacji, kompilatory nadal będą redukować oba do tego samego. Mogą również emitować ostrzeżenia, ponieważ może to wskazywać na błąd logiczny. Na przykład argument whilemożna zdefiniować gdzie indziej i nie zdajesz sobie sprawy, że jest stały.

Dziwię się, że nikt nie zaproponował bardziej bezpośredniej formy, odpowiadającej żądanemu montażowi:

forever:
     do stuff;
     goto forever;

while(1)to idiom for(;;)rozpoznawany przez większość kompilatorów.

Cieszyłem się, że Perl też to rozpoznaje until(0).

Podsumowując debatę na temat for (;;)vs while (1), jest oczywiste, że ta pierwsza była szybsza w czasach starszych nieoptymalizujących kompilatorów, dlatego zwykle widzisz ją w starszych bazach kodu, takich jak komentarze do kodu źródłowego Lions Unix, jednak w dobie optymalizacji kompilatory te zyski są zoptymalizowane, łącząc to z faktem, że to drugie jest łatwiejsze do zrozumienia niż pierwsze, uważam, że byłoby bardziej korzystne.

Właśnie natknąłem się na ten wątek (chociaż spóźniony o kilka lat).

Myślę, że znalazłem właściwy powód, dla którego „za (;;)” jest lepsze niż „podczas (1)”.

zgodnie ze „standardem kodowania barier 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’.

w zasadzie nie jest to problem z szybkością, ale z czytelnością. W zależności od czcionki / nadruku kodu numer jeden (1) może wyglądać jak mała litera l.

czyli 1 vs l. (w niektórych czcionkach wyglądają identycznie).

Więc while (1) może wyglądać jak pętla while zależna od litery zmiennej L.

while (true) może również działać, ale w niektórych starszych przypadkach C i embedded C true / false nie są jeszcze zdefiniowane, chyba że dołączono stdbool.h.

Myślę, że oba są takie same pod względem wydajności. Ale wolałbym while (1) ze względu na czytelność, ale pytam, dlaczego potrzebujesz nieskończonej pętli.

Oni są tacy sami. Jest dużo ważniejszych pytań do rozważenia.