Was ist schneller: während (1) oder während (2)?

Dies war eine Interviewfrage, die von einem Senior Manager gestellt wurde.

Welche ist schneller?

while(1) {
    // Some code
}

oder

while(2) {
    //Some code
}

Ich sagte, dass beide die gleiche Ausführungsgeschwindigkeit haben, da der Ausdruck im Inneren whileschließlich zu trueoder ausgewertet werden sollte false. In diesem Fall bewerten beide trueund es gibt keine zusätzlichen bedingten Anweisungen innerhalb der whileBedingung. Beide haben also die gleiche Ausführungsgeschwindigkeit und ich bevorzuge while (1).

Aber der Interviewer sagte zuversichtlich: "Überprüfen Sie Ihre Grundlagen. Ist while(1)schneller als while(2)." (Er hat mein Vertrauen nicht auf die Probe gestellt)

Ist das wahr?

Siehe auch: Ist "for (;;)" schneller als "while (TRUE)"? Wenn nicht, warum benutzen die Leute es?

Beide Schleifen sind unendlich, aber wir können sehen, welche mehr Anweisungen / Ressourcen pro Iteration benötigt.

Mit gcc habe ich die beiden folgenden Programme für die Montage auf verschiedenen Optimierungsstufen kompiliert:

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

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

Auch ohne Optimierungen ( -O0) war die generierte Assembly für beide Programme identisch . Daher gibt es keinen Geschwindigkeitsunterschied zwischen den beiden Schleifen.

Als Referenz ist hier die generierte Assembly (unter Verwendung gcc main.c -S -masm=inteleines Optimierungsflags):

Mit -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"

Mit -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"

Mit -O2und -O3(gleiche Ausgabe):

    .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"

Tatsächlich ist die für die Schleife generierte Baugruppe für jede Optimierungsstufe identisch:

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

Die wichtigen Punkte sind:

.L2:
    jmp .L2

Ich kann Assembly nicht sehr gut lesen, aber dies ist offensichtlich eine bedingungslose Schleife. Die jmpAnweisung setzt das Programm bedingungslos auf das .L2Label zurück, ohne einen Wert mit true zu vergleichen, und tut dies natürlich sofort wieder, bis das Programm irgendwie beendet ist. Dies entspricht direkt dem C / C ++ - Code:

L2:
    goto L2;

Bearbeiten:

Interessanterweise erzeugten die folgenden Schleifen auch ohne Optimierungenjmp in der Montage genau dieselbe Ausgabe (bedingungslos ):

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) {}

Und sogar zu meinem Erstaunen:

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

Mit benutzerdefinierten Funktionen wird es etwas interessanter:

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

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

while(x()) {}

Bei -O0diesen beiden Beispielen wird tatsächlich xein Vergleich für jede Iteration aufgerufen und durchgeführt.

Erstes Beispiel (Rückgabe 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"

Zweites Beispiel (Rückkehr 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"

Bei -O1und darüber produzieren beide jedoch dieselbe Baugruppe wie die vorherigen Beispiele (eine bedingungslose jmpRückkehr zum vorhergehenden Etikett).

TL; DR

Unter GCC werden die verschiedenen Schleifen zu identischen Baugruppen kompiliert. Der Compiler wertet die konstanten Werte aus und führt keinen tatsächlichen Vergleich durch.

Die Moral der Geschichte lautet:

• Es gibt eine Übersetzungsebene zwischen C ++ - Quellcode und CPU-Anweisungen, und diese Ebene hat wichtige Auswirkungen auf die Leistung.
• Daher kann die Leistung nicht nur anhand des Quellcodes bewertet werden.
• Der Compiler sollte intelligent genug sein, um solche trivialen Fälle zu optimieren. Programmierer sollten in den allermeisten Fällen nicht ihre Zeit damit verschwenden, über sie nachzudenken.

Ja, while(1)ist viel schneller als while(2), für einen Menschen zu lesen! Wenn ich while(1)in einer unbekannten Codebasis sehe, weiß ich sofort, was der Autor beabsichtigt hat, und meine Augäpfel können mit der nächsten Zeile fortfahren.

Wenn ich sehe while(2), werde ich wahrscheinlich in meinen Spuren stehen bleiben und versuchen herauszufinden, warum der Autor nicht geschrieben hat while(1). Ist der Finger des Autors auf der Tastatur gerutscht? Verwenden die Betreuer dieser Codebasis while(n)einen obskuren Kommentierungsmechanismus, um Schleifen anders aussehen zu lassen? Ist es eine grobe Problemumgehung für eine falsche Warnung in einem defekten statischen Analysewerkzeug? Oder ist dies ein Hinweis darauf, dass ich generierten Code lese? Ist es ein Fehler, der aus einem schlecht beratenen Finden und Ersetzen aller oder einer schlechten Verschmelzung oder einem kosmischen Strahl resultiert? Vielleicht soll diese Codezeile etwas dramatisch anderes bewirken. Vielleicht sollte es lesen while(w)oder while(x2). Ich finde den Autor besser im Verlauf der Datei und sende ihnen eine "WTF" -E-Mail ... und jetzt habe ich meinen mentalen Kontext gebrochen.while(2)while(1) hätte einen Bruchteil einer Sekunde gedauert!

Ich übertreibe, aber nur ein bisschen. Die Lesbarkeit des Codes ist wirklich wichtig. Und das ist in einem Interview erwähnenswert!

Die vorhandenen Antworten, die den von einem bestimmten Compiler für ein bestimmtes Ziel mit einem bestimmten Satz von Optionen generierten Code anzeigen, beantworten die Frage nicht vollständig - es sei denn, die Frage wurde in diesem bestimmten Kontext gestellt ("Was mit gcc 4.7.2 für x86_64 schneller ist mit Standardoptionen? ", zum Beispiel).

In Bezug auf die Sprachdefinition wertet die abstrakte Maschine in der abstrakten Maschinewhile (1) die Ganzzahlkonstante 1und while (2)die Ganzzahlkonstante aus 2; In beiden Fällen wird das Ergebnis auf Gleichheit mit Null verglichen. Der Sprachstandard sagt absolut nichts über die relative Leistung der beiden Konstrukte aus.

Ich kann mir vorstellen, dass ein extrem naiver Compiler möglicherweise unterschiedlichen Maschinencode für die beiden Formulare generiert, zumindest wenn er kompiliert wird, ohne eine Optimierung anzufordern.

Andererseits müssen C-Compiler zur Kompilierungszeit unbedingt einige konstante Ausdrücke auswerten , wenn sie in Kontexten erscheinen, die einen konstanten Ausdruck erfordern. Zum Beispiel:

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

erfordert eine Diagnose; Ein fauler Compiler hat nicht die Möglichkeit, die Auswertung 2+2bis zur Ausführungszeit zu verschieben. Da ein Compiler die Fähigkeit haben muss, konstante Ausdrücke zur Kompilierungszeit auszuwerten, gibt es keinen guten Grund, diese Fähigkeit nicht zu nutzen, selbst wenn sie nicht benötigt wird.

Der C-Standard ( N1570 6.8.5p4) besagt dies

Eine Iterationsanweisung bewirkt, dass eine Anweisung, die als Schleifenkörper bezeichnet wird , wiederholt ausgeführt wird, bis der steuernde Ausdruck gleich 0 ist.

Die relevanten konstanten Ausdrücke sind also 1 == 0und 2 == 0, die beide den intWert ergeben 0. (Dieser Vergleich ist implizit in der Semantik derwhile Schleife enthalten; sie existieren nicht als tatsächliche C-Ausdrücke.)

Ein pervers naiver Compiler könnte unterschiedlichen Code für die beiden Konstrukte generieren. Zum einen könnte es zum einen eine bedingungslose Endlosschleife erzeugen ( 1als Sonderfall behandeln ), und zum anderen könnte es einen expliziten Laufzeitvergleich erzeugen, der äquivalent zu ist 2 != 0. Aber ich bin noch nie auf einen C-Compiler gestoßen, der sich tatsächlich so verhält, und ich bezweifle ernsthaft, dass es einen solchen Compiler gibt.

Die meisten Compiler (ich bin versucht zu sagen, dass alle Compiler in Produktionsqualität) haben Optionen, um zusätzliche Optimierungen anzufordern. Bei einer solchen Option ist es noch weniger wahrscheinlich, dass ein Compiler unterschiedlichen Code für die beiden Formulare generiert.

Wenn Ihr Compiler für die beiden Konstrukte unterschiedlichen Code generiert, überprüfen Sie zunächst, ob die unterschiedlichen Codesequenzen tatsächlich eine unterschiedliche Leistung aufweisen. Versuchen Sie in diesem Fall erneut, mit einer Optimierungsoption zu kompilieren (falls verfügbar). Wenn sie sich immer noch unterscheiden, senden Sie einen Fehlerbericht an den Compilerhersteller. Es ist nicht (notwendigerweise) ein Fehler im Sinne einer Nichteinhaltung des C-Standards, aber es ist mit ziemlicher Sicherheit ein Problem, das behoben werden sollte.

Fazit: while (1)und mit while(2) ziemlicher Sicherheit die gleiche Leistung haben. Sie haben genau die gleiche Semantik, und es gibt keinen guten Grund für einen Compiler, keinen identischen Code zu generieren.

Und obwohl es für einen Compiler völlig legal ist, schnelleren Code für while(1)als für zu generieren while(2), ist es für einen Compiler ebenso legal, schnelleren Code für while(1)als für ein anderes Vorkommen while(1)im selben Programm zu generieren .

(In der von Ihnen gestellten Frage ist eine weitere Frage enthalten: Wie gehen Sie mit einem Interviewer um, der auf einem falschen technischen Punkt besteht. Dies wäre wahrscheinlich eine gute Frage für die Workplace-Site. )

Warte eine Minute. Der Interviewer, sah er aus wie dieser Typ?

Es ist schon schlimm genug, dass der Interviewer selbst dieses Interview nicht bestanden hat. Was ist, wenn andere Programmierer dieser Firma diesen Test "bestanden" haben?

Bewertung der Aussagen 1 == 0und 2 == 0 sollte gleich schnell sein. Wir könnten uns schlechte Compiler-Implementierungen vorstellen , bei denen eine schneller als die andere sein könnte. Aber es gibt keinen guten Grund, warum einer schneller sein sollte als der andere.

Selbst wenn es einen obskuren Umstand gibt, unter dem die Behauptung wahr wäre, sollten Programmierer nicht auf der Grundlage des Wissens über obskure (und in diesem Fall gruselige) Trivia bewertet werden. Mach dir keine Sorgen um dieses Interview, der beste Schritt hier ist, wegzugehen.

Haftungsausschluss: Dies ist KEIN Original-Dilbert-Cartoon. Dies ist nur ein Mashup .

Ihre Erklärung ist richtig. Dies scheint eine Frage zu sein, die neben technischem Wissen auch Ihr Selbstvertrauen auf die Probe stellt.

Übrigens, wenn Sie geantwortet haben

Beide Codeteile sind gleich schnell, da beide unendlich lange dauern

der Interviewer würde sagen

Aber while (1)kann mehr Iterationen pro Sekunde tun; kannst du erklären warum? (Das ist Unsinn. Testen Sie Ihr Vertrauen erneut.)

Wenn Sie also wie Sie geantwortet haben, haben Sie einige Zeit gespart, die Sie sonst für die Diskussion dieser schlechten Frage verschwenden würden.

Hier ist ein Beispielcode, der vom Compiler auf meinem System (MS Visual Studio 2012) mit deaktivierten Optimierungen generiert wurde:

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

Mit aktivierten Optimierungen:

xxx:
    jmp xxx

Der generierte Code ist also genau der gleiche, zumindest mit einem optimierenden Compiler.

Die wahrscheinlichste Erklärung für die Frage ist, dass der Interviewer denkt, dass der Prozessor die einzelnen Bits der Zahlen nacheinander überprüft, bis sie einen Wert ungleich Null erreichen:

1 = 00000001
2 = 00000010

Wenn das "Null ist?" Der Algorithmus beginnt auf der rechten Seite der Zahl und muss jedes Bit prüfen, bis es ein Bit ungleich Null erreicht. Die while(1) { }Schleife müsste doppelt so viele Bits pro Iteration prüfen wie die while(2) { }Schleife.

Dies erfordert ein sehr falsches mentales Modell der Funktionsweise von Computern, hat jedoch eine eigene interne Logik. Eine Möglichkeit zur Kontrolle wäre, wenn zu fragen , while(-1) { }oder while(3) { }würde gleich schnell sein, oder wenn while(32) { }sei sogar noch langsamer .

Natürlich kenne ich die wahren Absichten dieses Managers nicht, aber ich schlage eine völlig andere Sichtweise vor: Wenn Sie ein neues Mitglied in ein Team einstellen, ist es hilfreich zu wissen, wie es auf Konfliktsituationen reagiert.

Sie haben dich in einen Konflikt getrieben. Wenn dies wahr ist, sind sie klug und die Frage war gut. Für einige Branchen wie das Bankwesen kann das Posten Ihres Problems in Stack Overflow ein Grund für die Ablehnung sein.

Aber natürlich weiß ich nicht, ich schlage nur eine Option vor.

Ich denke, der Hinweis liegt in "von einem Senior Manager gefragt". Diese Person hat offensichtlich aufgehört zu programmieren, als sie Manager wurde, und dann hat sie mehrere Jahre gebraucht, um Senior Manager zu werden. Nie das Interesse an Programmierung verloren, aber seit diesen Tagen nie mehr eine Zeile geschrieben. Seine Referenz ist also nicht "irgendein anständiger Compiler da draußen", wie einige Antworten erwähnen, sondern "der Compiler, mit dem diese Person vor 20 bis 30 Jahren zusammengearbeitet hat".

Zu dieser Zeit verbrachten Programmierer einen beträchtlichen Prozentsatz ihrer Zeit damit, verschiedene Methoden auszuprobieren, um ihren Code schneller und effizienter zu machen, da die CPU-Zeit des „zentralen Minicomputers“ so wertvoll war. Wie die Leute, die Compiler schreiben. Ich vermute, dass der einzige Compiler, den sein Unternehmen zu diesem Zeitpunkt zur Verfügung stellte, auf der Grundlage von "häufig angetroffenen Aussagen, die optimiert werden können" optimiert wurde und bei einer Weile eine Abkürzung nahm (1) und alles auswertete sonst, einschließlich einer Weile (2). Eine solche Erfahrung gemacht zu haben, könnte seine Position und sein Vertrauen in sie erklären.

Der beste Ansatz, um Sie einzustellen, ist wahrscheinlich einer, der es dem Senior Manager ermöglicht, sich mitreißen zu lassen und Sie 2-3 Minuten über "die guten alten Tage des Programmierens" zu unterrichten, bevor SIE ihn reibungslos zum nächsten Interviewthema führen. (Gutes Timing ist hier wichtig - zu schnell und Sie unterbrechen die Geschichte - zu langsam und Sie werden als jemand mit unzureichendem Fokus bezeichnet). Sagen Sie ihm am Ende des Interviews, dass Sie sehr daran interessiert wären, mehr über dieses Thema zu erfahren.

Sie hätten ihn fragen sollen, wie er zu diesem Schluss gekommen ist. Unter jedem anständigen Compiler da draußen kompilieren die beiden nach denselben asm-Anweisungen. Also hätte er dir auch sagen sollen, dass der Compiler anfangen soll. Und trotzdem müsste man den Compiler und die Plattform sehr gut kennen, um überhaupt eine theoretisch fundierte Vermutung anstellen zu können. Und am Ende spielt es in der Praxis keine Rolle, da andere externe Faktoren wie Speicherfragmentierung oder Systemlast die Schleife stärker beeinflussen als dieses Detail.

Um dieser Frage willen sollte ich hinzufügen, dass ich mich daran erinnere, dass Doug Gwyn vom C-Komitee schrieb, dass einige frühe C-Compiler ohne den Optimierungsdurchlauf einen Assembler-Test für das generieren würden while(1)(im Vergleich zu for(;;)dem, der es nicht hätte).

Ich würde dem Interviewer mit dieser historischen Notiz antworten und dann sagen, dass selbst wenn ich sehr überrascht wäre, dass ein Compiler dies getan hat, ein Compiler Folgendes haben könnte:

• Ohne Optimierer-Pass generiert der Compiler einen Test für beide while(1)undwhile(2)
• Mit Optimizer Pass wird der Compiler angewiesen, alle zu optimieren (mit einem bedingungslosen Sprung), while(1)da sie als idiomatisch angesehen werden. Dies würde das while(2)mit einem Test belassen und macht daher einen Leistungsunterschied zwischen den beiden.

Ich möchte dem Interviewer natürlich hinzufügen, dass das Nicht-Berücksichtigen while(1)und while(2)das gleiche Konstrukt ein Zeichen für eine Optimierung von geringer Qualität ist, da dies äquivalente Konstrukte sind.

Eine andere Möglichkeit, eine solche Frage zu beantworten, wäre zu sehen, ob Sie den Mut haben, Ihrem Manager zu sagen, dass er / sie falsch liegt! Und wie leise Sie es kommunizieren können.

Mein erster Instinkt wäre gewesen, eine Assembly-Ausgabe zu generieren, um dem Manager zu zeigen, dass jeder anständige Compiler sich darum kümmern sollte, und wenn dies nicht der Fall ist, werden Sie den nächsten Patch dafür einreichen :)

Um zu sehen, wie sich so viele Menschen mit diesem Problem befassen, wird genau gezeigt, warum dies ein Test sein kann, um festzustellen, wie schnell Sie die Dinge mikrooptimieren möchten .

Meine Antwort wäre; es ist nicht so wichtig, ich konzentriere mich eher auf das Geschäftsproblem, das wir lösen. Schließlich werde ich dafür bezahlt.

Außerdem würde ich mich dafür entscheiden, while(1) {}weil es häufiger vorkommt und andere Teamkollegen keine Zeit aufwenden müssten, um herauszufinden, warum sich jemand für eine höhere Zahl als 1 entscheiden würde.

Schreiben Sie jetzt einen Code. ;-);

Wenn Sie sich Sorgen um die Optimierung machen, sollten Sie diese verwenden

for (;;)

denn das hat keine tests. (zynischer Modus)

Es scheint mir, dass dies eine dieser Verhaltensinterviewfragen ist, die als technische Frage maskiert sind. Einige Unternehmen tun dies - sie stellen eine technische Frage, die für jeden kompetenten Programmierer relativ einfach zu beantworten sein sollte. Wenn der Befragte jedoch die richtige Antwort gibt, teilt der Interviewer ihnen mit, dass sie falsch liegen.

Das Unternehmen möchte sehen, wie Sie in dieser Situation reagieren werden. Sitzen Sie ruhig da und drängen Sie nicht darauf, dass Ihre Antwort richtig ist, entweder aus Selbstzweifeln oder aus Angst, den Interviewer zu verärgern? Oder sind Sie bereit, eine autoritäre Person herauszufordern, von der Sie wissen, dass sie falsch ist? Sie wollen sehen, ob Sie bereit sind, für Ihre Überzeugungen einzutreten, und ob Sie dies taktvoll und respektvoll tun können.

Früher habe ich C- und Assembly-Code zurückprogrammiert, wenn diese Art von Unsinn einen Unterschied gemacht haben könnte. Als es einen Unterschied machte, haben wir es in Assembly geschrieben.

Wenn mir diese Frage gestellt worden wäre, hätte ich Donald Knuths berühmtes Zitat von 1974 über vorzeitige Optimierung wiederholt und wäre gegangen, wenn der Interviewer nicht gelacht und weitergemacht hätte.

Vielleicht hat der Interviewer absichtlich eine so dumme Frage gestellt und wollte, dass Sie 3 Punkte machen:

1. Grundlegende Argumentation. Beide Schleifen sind unendlich, es ist schwer, über Leistung zu sprechen.
2. Kenntnisse über Optimierungsstufen. Er wollte von Ihnen hören, wenn Sie den Compiler eine Optimierung für Sie durchführen lassen, würde dies die Bedingung optimieren, insbesondere wenn der Block nicht leer wäre.
3. Kenntnisse über Mikroprozessorarchitektur. Die meisten Architekturen haben einen speziellen CPU-Befehl zum Vergleich mit 0 (obwohl nicht unbedingt schneller).

Hier ist ein Problem: Wenn Sie tatsächlich ein Programm schreiben und dessen Geschwindigkeit messen, kann die Geschwindigkeit beider Schleifen unterschiedlich sein! Für einen vernünftigen Vergleich:

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

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

Wenn ein Code hinzugefügt wird, der die Zeit druckt, kann ein zufälliger Effekt wie die Positionierung der Schleife innerhalb einer oder zweier Cache-Zeilen einen Unterschied bewirken. Eine Schleife kann sich zufällig vollständig innerhalb einer Cache-Zeile oder am Anfang einer Cache-Zeile befinden oder zwei Cache-Zeilen überspannen. Infolgedessen könnte alles, was der Interviewer für am schnellsten hält, tatsächlich am schnellsten sein - zufällig.

Worst-Case-Szenario: Ein optimierender Compiler findet nicht heraus, was die Schleife tut, stellt jedoch fest, dass die Werte, die bei der Ausführung der zweiten Schleife erzeugt werden, dieselben sind wie die der ersten. Und generieren Sie vollständigen Code für die erste Schleife, aber nicht für die zweite.

Sie sind beide gleich - gleich.

Gemäß den Spezifikationen wird alles, was nicht 0 ist, als wahr angesehen, also auch ohne Optimierung, und ein guter Compiler generiert keinen Code für while (1) oder while (2). Der Compiler würde eine einfache Prüfung für generieren != 0.

Gemessen an der Zeit und Mühe, die die Leute damit verbracht haben, diese sehr einfache Frage zu testen, zu beweisen und zu beantworten, würde ich sagen, dass beide durch das Stellen der Frage sehr langsam gemacht wurden.

Und um noch mehr Zeit damit zu verbringen ...

"while (2)" ist lächerlich, weil,

"while (1)" und "while (true)" werden historisch verwendet, um eine Endlosschleife zu erstellen, die erwartet, dass "break" irgendwann innerhalb der Schleife aufgerufen wird, basierend auf einer Bedingung, die sicherlich auftreten wird.

Die "1" ist einfach da, um immer als wahr zu bewerten, und daher ist "während (2)" ungefähr so ​​albern wie "während (1 + 1 == 2)" zu sagen, was ebenfalls als wahr bewertet wird.

Und wenn Sie völlig albern sein wollen, verwenden Sie einfach: -

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

Ich würde gerne glauben, dass Ihr Codierer einen Tippfehler gemacht hat, der die Ausführung des Codes nicht beeinflusst hat. Wenn er jedoch absichtlich die "2" verwendet hat, um seltsam zu sein, entlassen Sie ihn, bevor er seltsame Dinge durch Ihren Code steckt, was es schwierig macht lesen und arbeiten mit.

Das hängt vom Compiler ab.

Wenn der Code optimiert wird oder wenn 1 und 2 mit der gleichen Anzahl von Befehlen für einen bestimmten Befehlssatz als wahr ausgewertet werden, ist die Ausführungsgeschwindigkeit gleich.

In realen Fällen wird es immer gleich schnell sein, aber es wäre möglich, sich einen bestimmten Compiler und ein bestimmtes System vorzustellen, wenn dies anders bewertet würde.

Ich meine: Dies ist nicht wirklich eine sprachbezogene Frage.

Da Leute, die diese Frage beantworten möchten, die schnellste Schleife wünschen, hätte ich geantwortet, dass beide gleichermaßen in denselben Assembler-Code kompiliert werden, wie in den anderen Antworten angegeben. Trotzdem können Sie dem Interviewer vorschlagen, "Loop Unrolling" zu verwenden. eine do {} while-Schleife anstelle der while-Schleife.

Vorsicht: Sie müssen sicherstellen, dass die Schleife mindestens immer einmal ausgeführt wird .

Die Schleife sollte innen eine Unterbrechungsbedingung haben.

Auch für diese Art von Schleife würde ich persönlich die Verwendung von do {} while (42) bevorzugen, da jede Ganzzahl außer 0 den Job erledigen würde.

Die offensichtliche Antwort lautet: Wie veröffentlicht, würden beide Fragmente eine gleichermaßen ausgelastete Endlosschleife ausführen, was das Programm unendlich langsam macht .

Obwohl die Neudefinition von C-Schlüsselwörtern als Makros technisch undefiniertes Verhalten hätte, ist dies die einzige Möglichkeit, eines der Codefragmente überhaupt schnell zu machen: Sie können diese Zeile über den beiden Fragmenten hinzufügen:

#define while(x) sleep(x);

es wird in der Tat while(1)doppelt so schnell (oder halb so langsam) machen wie while(2).

Der einzige Grund, warum ich mir vorstellen kann, warum das while(2)langsamer sein würde, ist:

1. Der Code optimiert die Schleife auf

   cmp eax, 2

2. Wenn das Subtrahieren auftritt, subtrahieren Sie im Wesentlichen

   ein. 00000000 - 00000010 cmp eax, 2

   anstatt

   b. 00000000 - 00000001 cmp eax, 1

cmpsetzt nur Flags und setzt kein Ergebnis. Auf den niedrigstwertigen Stellen wissen wir also, ob wir mit b ausleihen müssen oder nicht . Während mit a müssen Sie zwei Subtraktionen durchführen, bevor Sie eine Ausleihe erhalten.