Który jest szybszy: while (1) czy while (2)?

To było pytanie do wywiadu zadane przez kierownika wyższego szczebla.

Który jest szybszy?

while(1) {
    // Some code
}

lub

while(2) {
    //Some code
}

Powiedziałem, że oba mają tę samą szybkość wykonywania, ponieważ wyrażenie wewnątrz whilepowinno ostatecznie ocenić na truelub false. W takim przypadku zarówno ocena, jak truei brak dodatkowych instrukcji warunkowych wewnątrz whilewarunku. Oba będą miały tę samą szybkość wykonywania i wolę while (1).

Ale ankieter powiedział pewnie: „Sprawdź swoje podstawy. while(1)Jest szybszy niż while(2)”. (Nie testował mojej pewności siebie)

Czy to prawda?

Zobacz także: Czy „for (;;)” jest szybsze niż „while (TRUE)”? Jeśli nie, dlaczego ludzie z niego korzystają?

Obie pętle są nieskończone, ale możemy zobaczyć, która z nich pobiera więcej instrukcji / zasobów na iterację.

Korzystając z gcc, skompilowałem dwa następujące programy do montażu na różnych poziomach optymalizacji:

int main(void) {
    while(1) {}
    return 0;
}

int main(void) {
    while(2) {}
    return 0;
}

Nawet bez optymalizacji ( -O0) wygenerowany zestaw był identyczny dla obu programów . Dlatego nie ma różnicy prędkości między dwiema pętlami.

Dla odniesienia tutaj jest wygenerowany zespół (przy użyciu gcc main.c -S -masm=intelflagi optymalizacji):

Z -O0:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    push    rbp
    .seh_pushreg    rbp
    mov rbp, rsp
    .seh_setframe   rbp, 0
    sub rsp, 32
    .seh_stackalloc 32
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Z -O1:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Z -O2i -O3(ta sama moc wyjściowa):

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .section    .text.startup,"x"
    .p2align 4,,15
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

W rzeczywistości zespół wygenerowany dla pętli jest identyczny dla każdego poziomu optymalizacji:

 .L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Najważniejsze bity to:

.L2:
    jmp .L2

Nie potrafię dobrze czytać asemblera, ale jest to oczywiście bezwarunkowa pętla. jmpInstrukcja bezwarunkowo resetuje programu tyłu do .L2etykiety bez nawet porównując wartość przed prawdą, i oczywiście od razu robi to ponownie, aż program jest jakoś skończyło. Odpowiada to bezpośrednio kodowi C / C ++:

L2:
    goto L2;

Edytować:

Co ciekawe, nawet bez optymalizacji wszystkie poniższe pętle dały dokładnie taki sam wynik (bezwarunkowy jmp) w zestawie:

while(42) {}

while(1==1) {}

while(2==2) {}

while(4<7) {}

while(3==3 && 4==4) {}

while(8-9 < 0) {}

while(4.3 * 3e4 >= 2 << 6) {}

while(-0.1 + 02) {}

I nawet ku mojemu zdumieniu:

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

Sprawy stają się trochę bardziej interesujące dzięki funkcjom zdefiniowanym przez użytkownika:

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

double x(void) {
    return sqrt(7);
}

while(x()) {}

Na -O0te dwa przykłady rzeczywiście wywołać xi wykonać porównania dla każdej iteracji.

Pierwszy przykład (zwracanie 1):

.L4:
    call    x
    testl   %eax, %eax
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Drugi przykład (powrót sqrt(7)):

.L4:
    call    x
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jp  .L4
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Jednak w -O1obu przypadkach oba wytwarzają ten sam zestaw co poprzednie przykłady (bezwarunkowy jmppowrót do poprzedniej etykiety).

TL; DR

W GCC różne pętle są kompilowane do identycznego zestawu. Kompilator ocenia stałe wartości i nie przeszkadza w faktycznym porównaniu.

Morał tej historii jest następujący:

• Istnieje warstwa tłumaczenia między kodem źródłowym C ++ a instrukcjami procesora i ta warstwa ma ważne implikacje dla wydajności.
• Dlatego wydajności nie można ocenić, patrząc tylko na kod źródłowy.
• Kompilator powinien być wystarczająco inteligentny, aby zoptymalizować takie trywialne przypadki. Programiści nie powinni tracić czasu na myślenie o nich w zdecydowanej większości przypadków.

Tak, while(1)jest o wiele szybszy niż while(2), aby człowiek czytał! Jeśli widzę while(1)w nieznanej bazie kodu, od razu wiem, co zamierzał autor, a moje oczy mogą przejść do następnej linii.

Jeśli zobaczę while(2), pewnie zatrzymam się i spróbuję dowiedzieć się, dlaczego autor nie napisał while(1). Czy palec autora poślizgnął się na klawiaturze? Czy opiekunowie tej bazy kodu używają while(n)niejasnego mechanizmu komentowania, aby pętle wyglądały inaczej? Czy to prymitywne obejście fałszywego ostrzeżenia w uszkodzonym narzędziu do analizy statycznej? Czy jest to wskazówka, że ​​czytam wygenerowany kod? Czy jest to błąd wynikający z niewłaściwego znalezienia i zastąpienia wszystkich, złego scalenia lub kosmicznego promienia? Może ta linia kodu ma robić coś zupełnie innego. Może miał to przeczytać while(w)lub while(x2). Lepiej znajdę autora w historii pliku i wyślę mu wiadomość e-mail „WTF” ... a teraz przełamałem swój kontekst mentalny.while(2)while(1) zajęłoby ułamek sekundy!

Przesadzam, ale tylko trochę. Czytelność kodu jest naprawdę ważna. I warto o tym wspomnieć w wywiadzie!

Istniejące odpowiedzi pokazujące kod wygenerowany przez określony kompilator dla określonego celu z określonym zestawem opcji nie odpowiadają w pełni na pytanie - chyba że pytanie zostało zadane w tym konkretnym kontekście („Które jest szybsze przy użyciu gcc 4.7.2 dla x86_64 z domyślnymi opcjami? ”, na przykład).

Jeśli chodzi o definicję języka, w abstrakcyjnej maszynie while (1) ocenia stałą całkowitą 1i while (2)ocenia stałą całkowitą 2; w obu przypadkach wynik jest porównywany dla równości do zera. Standard językowy absolutnie nic nie mówi o względnej wydajności obu konstrukcji.

Mogę sobie wyobrazić, że niezwykle naiwny kompilator może generować inny kod maszynowy dla tych dwóch formularzy, przynajmniej po skompilowaniu bez żądania optymalizacji.

Z drugiej strony, kompilatory C absolutnie muszą oceniać niektóre wyrażenia stałe w czasie kompilacji, gdy pojawiają się w kontekstach wymagających wyrażenia stałego. Na przykład:

int n = 4;
switch (n) {
    case 2+2: break;
    case 4:   break;
}

wymaga diagnostyki; leniwy kompilator nie ma możliwości odroczenia oceny 2+2do czasu wykonania. Ponieważ kompilator musi mieć możliwość oceny stałych wyrażeń w czasie kompilacji, nie ma dobrego powodu, aby nie korzystać z tej możliwości, nawet jeśli nie jest to wymagane.

Tak mówi standard C ( N1570 6.8.5p4)

Instrukcja iteracyjna powoduje, że instrukcja zwana ciałem pętli jest wykonywana wielokrotnie, aż wyrażenie kontrolne nie będzie równe 0.

Odpowiednimi stałymi wyrażeniami są 1 == 0i 2 == 0oba, które oceniają intwartość 0. (Te porównania są niejawne w semantyce whilepętli; nie istnieją jako rzeczywiste wyrażenia C.)

Przewrotnie naiwny kompilator mógłby wygenerować inny kod dla obu konstrukcji. Na przykład, dla pierwszego może wygenerować bezwarunkową nieskończoną pętlę (traktując to 1jako przypadek specjalny), a dla drugiego może wygenerować wyraźne porównanie w czasie wykonywania odpowiadające 2 != 0. Ale nigdy nie spotkałem kompilatora C, który zachowywałby się w ten sposób i poważnie wątpię, czy taki kompilator istnieje.

Większość kompilatorów (mam ochotę powiedzieć, że wszystkie kompilatory o jakości produkcyjnej) mają opcje żądania dodatkowej optymalizacji. Przy takiej opcji jest jeszcze mniej prawdopodobne, że kompilator wygeneruje inny kod dla tych dwóch formularzy.

Jeśli Twój kompilator generuje inny kod dla dwóch konstrukcji, najpierw sprawdź, czy różne sekwencje kodu mają różną wydajność. Jeśli tak, spróbuj skompilować ponownie z opcją optymalizacji (jeśli jest dostępna). Jeśli nadal się różnią, prześlij raport o błędzie do dostawcy kompilatora. Nie jest to (koniecznie) błąd w sensie niezgodności ze standardem C, ale prawie na pewno jest to problem, który należy naprawić.

Podsumowując: while (1)i while(2) prawie na pewno mają taką samą wydajność. Mają dokładnie taką samą semantykę i żaden kompilator nie ma żadnego powodu, aby nie generować identycznego kodu.

I chociaż kompilator generuje szybszy kod dla while(1)niż całkowicie while(2), to równie legalny jest dla kompilatora generowanie szybszego kodu while(1)niż dla innego wystąpienia while(1)tego samego programu.

(W tym, które zadałeś, kryje się jeszcze jedno pytanie: jak radzisz sobie z ankieterem, który nalega na niewłaściwy punkt techniczny. Prawdopodobnie byłoby to dobre pytanie dla witryny Workplace ).

Poczekaj minutę. Ankieter, czy wyglądał jak ten facet?

Na tyle źle, że sam ankieter nie zdał tego wywiadu, co jeśli inni programiści w tej firmie „zdali” ten test?

Nie Ocenianie oświadczenia 1 == 0i 2 == 0 powinno być równie szybki. Możemy sobie wyobrazić słabe implementacje kompilatora, w których jedna może być szybsza od drugiej. Ale nie ma dobrego powodu, aby jeden był szybszy od drugiego.

Nawet jeśli istnieją jakieś niejasne okoliczności, w których twierdzenie byłoby prawdziwe, programiści nie powinni być oceniani na podstawie wiedzy o niejasnych (aw tym przypadku przerażających) ciekawostkach. Nie martw się o ten wywiad, najlepszym krokiem tutaj jest odejść.

Uwaga: To NIE jest oryginalna kreskówka Dilberta. To jest tylko mashup .

Twoje wyjaśnienie jest poprawne. To wydaje się być pytaniem, które oprócz wiedzy technicznej sprawdza Twoją pewność siebie.

Przy okazji, jeśli odpowiedziałeś

Oba fragmenty kodu są równie szybkie, ponieważ oba zajmują nieskończenie dużo czasu

powiedziałby ankieter

Ale while (1)może zrobić więcej iteracji na sekundę; czy możesz mi wytłumaczyć dlaczego? (to nonsens; ponownie sprawdź swoją pewność siebie)

Odpowiadając tak jak ty, zaoszczędziłeś czas, który w innym przypadku zmarnowałbyś na omawianie tego złego pytania.

Oto przykładowy kod wygenerowany przez kompilator w moim systemie (MS Visual Studio 2012) z wyłączonymi optymalizacjami:

yyy:
    xor eax, eax
    cmp eax, 1     (or 2, depending on your code)
    je xxx
    jmp yyy
xxx:
    ...

Przy włączonych optymalizacjach:

xxx:
    jmp xxx

Tak więc wygenerowany kod jest dokładnie taki sam, przynajmniej z kompilatorem optymalizującym.

Najbardziej prawdopodobnym wyjaśnieniem tego pytania jest to, że ankieter uważa, że ​​procesor sprawdza poszczególne bity liczb, jeden po drugim, aż osiągnie niezerową wartość:

1 = 00000001
2 = 00000010

Jeśli „wynosi zero?” algorytm zaczyna się od prawej strony liczby i musi sprawdzać każdy bit, aż osiągnie wartość niezerową, while(1) { }pętla musiałaby sprawdzać dwa razy więcej bitów na iterację niż while(2) { }pętla.

Wymaga to bardzo błędnego modelu mentalnego działania komputerów, ale ma swoją własną logikę wewnętrzną. Jednym ze sposobów sprawdzenia byłoby pytanie, while(-1) { }czy while(3) { }byłoby równie szybkie, czy też while(32) { }byłoby jeszcze wolniejsze .

Oczywiście nie znam prawdziwych intencji tego menedżera, ale proponuję zupełnie inny punkt widzenia: zatrudniając nowego członka w zespole, warto wiedzieć, jak reaguje na sytuacje konfliktowe.

Doprowadzili cię do konfliktu. Jeśli to prawda, są sprytni, a pytanie było dobre. W niektórych branżach, takich jak bankowość, opublikowanie problemu w Stack Overflow może być przyczyną odrzucenia.

Ale oczywiście nie wiem, po prostu proponuję jedną opcję.

Myślę, że wskazówką jest „zapytany przez kierownika wyższego szczebla”. Ta osoba oczywiście przestała programować, kiedy został menadżerem, a potem zajęło jej kilka lat, aby zostać menedżerem wyższego szczebla. Nigdy nie straciłem zainteresowania programowaniem, ale nigdy nie napisałem linii od tamtych czasów. Tak więc jego odniesieniem nie jest „jakikolwiek przyzwoity kompilator”, jak wspomniano w niektórych odpowiedziach, ale „kompilator, z którym ta osoba pracowała 20-30 lat temu”.

W tym czasie programiści spędzili znaczną część czasu na wypróbowywaniu różnych metod zwiększania szybkości i wydajności kodu, ponieważ czas procesora „centralnego minikomputera” był tak cenny. Podobnie jak ludzie piszący kompilatory. Zgaduję, że jedyny kompilator, który jego firma udostępniła w tamtym czasie, zoptymalizowany na podstawie „często spotykanych instrukcji, które można zoptymalizować” i skrócił się na chwilę (1) i wszystko ocenił jeszcze, w tym chwilę (2). Doświadczenie takie mogło wyjaśnić jego pozycję i zaufanie do niego.

Najlepszym sposobem, aby cię zatrudnić, jest prawdopodobnie takie, które pozwala starszemu menedżerowi dać się ponieść emocjom i wygłosić 2-3 minuty na temat „starych dobrych dni programowania”, zanim TY płynnie poprowadzisz go do następnego tematu rozmowy. (Ważny jest tutaj odpowiedni moment - zbyt szybko, a przerywasz historię - zbyt wolno i jesteś oznaczony jako osoba o niewystarczającym skupieniu). Po zakończeniu rozmowy powiedz mu, że chciałbyś dowiedzieć się więcej na ten temat.

Powinieneś był zapytać go, jak doszedł do tego wniosku. Pod jakimkolwiek przyzwoitym kompilatorem, oba kompilują się do tych samych instrukcji asm. Powinien więc był powiedzieć kompilatorowi, żeby zaczął. Mimo to musiałbyś bardzo dobrze znać kompilator i platformę, aby nawet zgadywać teoretycznie. I w końcu tak naprawdę nie ma to znaczenia w praktyce, ponieważ istnieją inne czynniki zewnętrzne, takie jak fragmentacja pamięci lub obciążenie systemu, które będą miały większy wpływ na pętlę niż ten szczegół.

Ze względu na to pytanie powinienem dodać, że pamiętam Douga Gwyna z komitetu C, który napisał, że niektóre wczesne kompilatory C bez przepustki optymalizatora wygenerowałyby test zestawu dla while(1)(w porównaniu z for(;;)którym nie miałby tego).

Chciałbym odpowiedzieć ankieterowi, podając tę ​​historyczną notatkę, a następnie powiedzieć, że nawet jeśli byłbym bardzo zaskoczony, że jakikolwiek kompilator to zrobił, kompilator mógłby mieć:

• bez zaliczenia optymalizatora kompilator wygeneruje test dla obu while(1)iwhile(2)
• z przepustką optymalizatora kompilator otrzymuje polecenie optymalizacji (z bezwarunkowym skokiem), while(1)ponieważ są one uważane za idiomatyczne. To zostawiłoby while(2)test i dlatego czyni różnicę wydajności między tymi dwoma.

Dodałbym oczywiście do ankietera, że ​​nieuwzględnianie while(1)i while(2)ten sam konstrukt jest oznaką niskiej jakości optymalizacji, ponieważ są to konstrukty równoważne.

Innym podejściem do takiego pytania byłoby sprawdzenie, czy masz odwagę powiedzieć swojemu przełożonemu, że się myli! I jak delikatnie możesz to przekazać.

Moim pierwszym instynktem byłoby wygenerowanie danych wyjściowych zestawu, aby pokazać menedżerowi, że każdy porządny kompilator powinien się tym zająć, a jeśli tak się nie stanie, prześlesz następną łatkę :)

Aby zobaczyć, jak wiele osób zagłębia się w ten problem, pokazuje dokładnie, dlaczego może to być test sprawdzający, jak szybko chcesz mikrooptymalizować rzeczy.

Moja odpowiedź brzmiałaby; to nie ma większego znaczenia, wolę skupić się na problemie biznesowym, który rozwiązujemy. W końcu za to otrzymam zapłatę.

Co więcej, wybrałbym, while(1) {}ponieważ jest to bardziej powszechne, a inni członkowie drużyny nie musieliby tracić czasu, aby dowiedzieć się, dlaczego ktoś wybrałby liczbę wyższą niż 1.

Teraz napisz kod. ;-)

Jeśli martwisz się optymalizacją, powinieneś użyć

for (;;)

ponieważ to nie ma testów. (tryb cyniczny)

Wydaje mi się, że jest to jedno z tych pytań podczas wywiadu behawioralnego zamaskowanych jako pytanie techniczne. Niektóre firmy to robią - zadają pytanie techniczne, na które każdy kompetentny programista powinien udzielić dość łatwej odpowiedzi, ale gdy rozmówca udzieli prawidłowej odpowiedzi, ankieter powie im, że się mylą.

Firma chce zobaczyć, jak zareagujesz w tej sytuacji. Czy siedzisz tam cicho i nie naciskasz, że twoja odpowiedź jest prawidłowa z powodu wątpliwości lub strachu przed zdenerwowaniem ankietera? A może chcesz rzucić wyzwanie osobie sprawującej władzę, o której wiesz, że jest w błędzie? Chcą sprawdzić, czy jesteś gotów bronić swoich przekonań i czy możesz to zrobić w taktowny i pełen szacunku sposób.

Kiedyś programowałem C i kod asemblera z powrotem, gdy ten rodzaj bzdur mógł coś zmienić. Kiedy zrobiło to różnicę, napisaliśmy to na Zgromadzeniu.

Gdybym zadał to pytanie, powtórzyłbym słynny cytat Donalda Knutha z 1974 r. O przedwczesnej optymalizacji i poszedłbym, gdyby rozmówca się nie śmiał i nie ruszył dalej.

Może osoba przeprowadzająca wywiad celowo zadała takie głupie pytanie i chciała, abyś zrobił 3 punkty:

1. Podstawowe rozumowanie. Obie pętle są nieskończone, trudno mówić o wydajności.
2. Wiedza na temat poziomów optymalizacji. Chciał usłyszeć od ciebie, jeśli pozwolisz kompilatorowi wykonać dla ciebie jakąkolwiek optymalizację, zoptymalizuje to warunek, szczególnie jeśli blok nie będzie pusty.
3. Wiedza na temat architektury mikroprocesorów. Większość architektur ma specjalną instrukcję procesora do porównania z 0 (choć niekoniecznie szybciej).

Oto problem: jeśli faktycznie piszesz program i mierzysz jego prędkość, prędkość obu pętli może być inna! Dla pewnego rozsądnego porównania:

unsigned long i = 0;
while (1) { if (++i == 1000000000) break; }

unsigned long i = 0;
while (2) { if (++i == 1000000000) break; }

z dodanym kodem, który drukuje czas, jakiś losowy efekt, taki jak położenie pętli w jednej lub dwóch liniach pamięci podręcznej, może mieć znaczenie. Jedna pętla może przypadkowo znajdować się całkowicie w obrębie jednej linii pamięci podręcznej lub na początku linii pamięci podręcznej, lub może obejmować dwie linie pamięci podręcznej. W rezultacie to, co twierdzi ankieter, jest najszybsze, może faktycznie być najszybsze - przez przypadek.

Scenariusz najgorszego przypadku: Kompilator optymalizacyjny nie wie, co robi pętla, ale stwierdza, że ​​wartości wytworzone podczas wykonywania drugiej pętli są takie same, jak wartości wytworzone przez pierwszą. I wygeneruj pełny kod dla pierwszej pętli, ale nie dla drugiej.

Oba są równe - to samo.

Zgodnie ze specyfikacjami wszystko, co nie jest 0, jest uważane za prawdziwe, więc nawet bez jakiejkolwiek optymalizacji, a dobry kompilator nie wygeneruje żadnego kodu dla while (1) lub while (2). Kompilator wygeneruje proste sprawdzenie != 0.

Sądząc po ilości czasu i wysiłku, jaki ludzie spędzili na testowaniu, udowadnianiu i odpowiadaniu na to bardzo proste pytanie, twierdzę, że obaj spóźnili się, zadając to pytanie.

Aby spędzić na tym jeszcze więcej czasu ...

„while (2)” jest śmieszne, ponieważ,

„while (1)” i „while (true)” są historycznie używane do tworzenia nieskończonej pętli, która oczekuje, że „przerwa” zostanie wywołana na pewnym etapie wewnątrz pętli w oparciu o warunek, który z pewnością wystąpi.

„1” jest po prostu po to, aby zawsze oceniać na prawdę, a zatem powiedzenie „while (2)” jest tak samo głupie, jak powiedzenie „while (1 + 1 == 2)”, które również będzie oceniać na true.

A jeśli chcesz być całkowicie głupi, po prostu użyj:

while (1 + 5 - 2 - (1 * 3) == 0.5 - 4 + ((9 * 2) / 4)) {
    if (succeed())
        break;
}

Chciałbym pomyśleć, że twój programista napisał literówkę, która nie wpłynęła na działanie kodu, ale jeśli celowo użył „2” tylko po to, by być dziwnym, to spuść go, zanim wprowadzi dziwny sh! T przez cały kod, co utrudnia czytać i pracować z.

To zależy od kompilatora.

Jeśli zoptymalizuje kod lub jeśli oceni 1 i 2 na wartość true przy użyciu tej samej liczby instrukcji dla określonego zestawu instrukcji, szybkość wykonywania będzie taka sama.

W rzeczywistych przypadkach zawsze będzie tak samo szybko, ale można by sobie wyobrazić konkretnego kompilatora i konkretnego systemu, gdyby był on oceniany inaczej.

Mam na myśli: tak naprawdę nie jest to pytanie związane z językiem (C).

Ponieważ ludzie, którzy chcą odpowiedzieć na to pytanie, chcą najszybszej pętli, odpowiedziałbym, że oba kompilują się w tym samym kodzie asemblera, jak podano w innych odpowiedziach. Niemniej jednak możesz zasugerować ankieterowi za pomocą „rozwijania pętli”; pętla do {} while zamiast pętli while.

Ostrożnie: musisz upewnić się, że pętla przynajmniej raz uruchomi się raz .

Pętla powinna mieć stan pęknięcia w środku.

Również dla tego rodzaju pętli osobiście wolałbym używać do {} while (42), ponieważ każda liczba całkowita, z wyjątkiem 0, wykonałaby zadanie.

Oczywista odpowiedź brzmi: jak napisano, oba fragmenty uruchomiłyby równie zajętą ​​nieskończoną pętlę, co czyni program nieskończenie wolnym .

Chociaż redefiniowanie słów kluczowych C jako makr technicznie miałoby nieokreślone zachowanie, jest to jedyny sposób, w jaki mogę wymyślić szybki fragment fragmentu kodu: możesz dodać ten wiersz powyżej 2 fragmentów:

#define while(x) sleep(x);

rzeczywiście będzie while(1)dwa razy szybszy (lub o połowę wolniejszy) niż while(2).

Jedyny powód, dla którego mogę wymyślić, dlaczego while(2)byłoby wolniej, to:

1. Kod optymalizuje pętlę do

   cmp eax, 2

2. Kiedy następuje odejmowanie, zasadniczo odejmujesz

   za. 00000000 - 00000010 cmp eax, 2

   zamiast

   b. 00000000 - 00000001 cmp eax, 1

cmpustawia tylko flagi i nie ustawia wyniku. Więc na najmniej znaczących bitach wiemy, czy musimy pożyczyć, czy nie za pomocą b . Podczas gdy przy pomocy musisz wykonać dwa odejmowania, zanim otrzymasz pożyczkę.