Ce qui est plus rapide: while(1) ou de tout(2)?

C'était une interview à la question posée par un senior manager.

Qui est le plus rapide? 

while(1) {
    //Some code
}

ou 

while(2) {
    //Some code
}

J'ai dit que les deux ont la même vitesse d'exécution, comme l'expression à l'intérieur de while faut enfin évaluer à true ou false. Dans ce cas, à la fois d'évaluer la true et il n'y a pas extra instructions conditionnelles à l'intérieur de la while condition. Ainsi, les deux auront la même vitesse d'exécution et je préfère tout (1).

Mais l'enquêteur a dit avec confiance:
"Vérifiez vos bases. while(1) est plus rapide que while(2)."
(Il n'était pas test ma confiance)

Est-ce vrai?

Voir aussi: Est "for(;;)" plus rapide que le "while (TRUE)"? Si non, pourquoi les utiliser?

  • Une demi-décent compilateur d'optimiser à la fois les formes à rien.
  • Dans optimisé la construction de tout alors que(n), n != 0 ou for(;;) sera traduit de l'Assemblée boucle sans fin avec l'étiquette de début et de goto dans la fin. Exactement le même code, la même performance.
  • Pas étonnant, un stock d'optimiser apporte 0x100000f90: jmp 0x100000f90 (adresse varie, évidemment) pour les deux extraits. L'intervieweur probablement couvert sur un registre de test par rapport à un simple pavillon de saut. À la fois la question, et leur supposition, est boiteux.
  • Cette question de l'intervieweur tombe sous les mêmes auspices que dilbert.com/strips/comic/1995-11-17 - vous allez rencontrer quelqu'un qui croit fondamentalement ce qu'ils sont en train de dire quel que soit le quotient de la stupidité dans leur déclaration. Simplement choisissez parmi les options suivantes: une profonde breat, de jurer, de rire, de pleurer, une combinaison de ce qui précède 🙂
  • W: on peut se demander ce qu'est un compilateur doit faire: traduire un Arrêt de déclaration, ou de considérer que la boucle s'arrête après un temps infini et optimiser loin l'infini de retard ?
  • Apparemment, les compilateurs sont autorisés à optimiser disparaître complètement (voir ce c++ question ou cette discussion - de la recherche pour "C1X" pour un devis de la Norme), et certains compilateurs vraiment le faire (le dernier lien mentionne lesquels).
  • alors, comment expliquez-vous que -1 est plus lent que 0?
  • La question ne demande pas qui parcourt plus rapidement au moment de l'exécution, ou qui compile en un temps plus court. Il demande simplement à ce qui est plus rapide. Par conséquent, celui qui est premier est clairement le plus rapide des deux choix; ainsi, alors que(1) doit être plus rapide. DUH
  • Peut-être qu'ils étaient à la recherche pour vous de préciser si elles étaient à la recherche pour compiler vs temps d'exécution. Je ne suis pas certain qu'ils vont avoir le même temps de compilation, que j'ai pu voir certains compilateurs avoir un début de "while(1)" et "while(true)" et sinon, de le transmettre à un plus générique const-évaluateur d'expression.
  • Comme @MooseBoys mentionne. Ma première pensée a été également qu'il peut être de parler de temps de construction plutôt que de courir de temps. Ce serait bien si ceci pourrait être étudié en quelque sorte.
  • Cette question est peut-être juste pour attirer les votes, mais c'est justement de sujet pour Stack Overflow.
  • Mike W: Non, il allait laisser les boucles intacte. Le compilateur ne doit pas changer le sens du programme. Si le programme n'est pas arrêter, il doit rester de cette façon.
  • Je pense que c'est plus rapide à écrire while(1) que de l'écrire while(2). Il se trouve que je viens de commander une nouvelle mécanique crayon hors de Amazon. Je vais courir quelques repères dès qu'il arrive.
  • L'examinateur était mort incorrect, le plus rapide est sans aucun doute while (0) 😉
  • Cette question était tout plagié sur Quora: quora.com/Programming-Which-is-faster-while-1-or-while-2
  • C'est une vieille question, mais pour les futurs enquêteurs là: while (42) { ... } est certainement le plus lent, en vertu de tout niveau d'optimisation, avec un compilateur. Et effectivement, return 42; s'exécute plus lentement que le renvoi de toute autre valeur. Après tout... en Fait, sur une note plus sérieuse, si j'ai vraiment fait voir while (42) je voudrais savoir exactement ce que l'auteur a été de penser, et d'être en mesure de passer tout de suite de trop.
  • Vous devriez toujours demander pourquoi, lorsque vous rencontrez ce genre de chose. Il y a beaucoup de désinformation là-bas, et les enquêteurs ne sont pas à l'abri. L'intervieweur est mort à plat de mal dans ce cas. Compilateur écrivain parle ici. Il est aussi un peu stupide question d'entrevue: quelle différence cela fait-il dans la pratique? Qui se passe vraiment à écrire while (2)? Juste une occasion pour l'interviewer pour montrer son ignorance.

InformationsquelleAutor Nikole | 2014-07-20
  1. 676

    Les deux boucles sont infinies, mais nous pouvons voir que l'on prend plus d'instructions/ressources par itération.

    À l'aide de gcc, j'ai compilé les deux programmes suivants à l'assemblée, à divers niveaux d'optimisation:

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

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

    Même sans les optimisations (-O0), l'assembly généré est identique pour les deux programmes. Par conséquent, il n'y a pas de différence de vitesse entre les deux boucles.

    Pour référence, voici l'assembly généré (à l'aide de gcc main.c -S -masm=intel avec une option d'optimisation):

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

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

    Avec -O2 et -O3 (même résultat):

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

    En fait, l'assembly généré par la boucle est identique pour tous les niveaux d'optimisation:

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

    L'important bits:

    .L2:
    jmp .L2

    Je ne peux pas lire l'assemblée très bien, mais c'est évidemment une inconditionnelle de la boucle. Le jmp instruction inconditionnellement réinitialise le programme de retour à la .L2 étiquette sans même comparer une valeur à l'encontre du vrai, et bien sûr immédiatement fait à nouveau jusqu'à ce que le programme est en quelque sorte terminé. Cela correspond directement du code C/C++:

    L2:
    goto L2;

    Edit:

    Assez intéressant, même avec pas optimisations, les boucles suivantes, qui sont toutes produites exactement la même sortie (inconditionnel jmp) dans l'assemblée:

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

    Et même à mon grand étonnement:

    #include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

    Les choses deviennent un peu plus intéressantes, avec des fonctions définies par l'utilisateur:

    int x(void) {
    return 1;
}

while(x()) {}

    #include<math.h>

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

while(x()) {}

    À -O0, ces deux exemples fait appel x et d'effectuer une comparaison pour chaque itération.

    Premier exemple (retour 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"

    Deuxième exemple (de retour 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"

    Cependant, à -O1 et au-dessus, ils produisent la même assemblée que les exemples précédents (une inconditionnelle de la jmp retour à la précédente étiquette).

    TL;DR

    En vertu de la GCC, les différentes boucles sont compilés à l'identique de l'assemblée. Le compilateur évalue les valeurs de constante et n'a pas pris la peine d'effectuer toute comparaison réelle.

    La morale de l'histoire est:

    • Il existe une couche de traduction entre le C++ code source et les instructions du PROCESSEUR, et cette couche a des implications importantes pour la performance.
    • Par conséquent, la performance ne peut pas être évalué en regardant uniquement le code source.
    • Le compilateur devrait être assez intelligent pour optimiser ces cas triviaux. Les programmeurs ne devrait pas perdre leur temps à penser à eux dans la grande majorité des cas.
    • Peut-être que l'enquêteur n'était pas à l'aide de gcc
    • C'est un bon point; malheureusement je n'ai pas d'autres compilateurs installé sur mon système. Si quelqu'un peut tester clang, msvs, ou quoi que ce soit d'autre, je serais curieux de voir les résultats.
    • McNabb C'est un bon point, mais si l'enquêteur a été en s'appuyant sur le compilateur spécifique des optimisations, alors ils doivent être très explicites à ce sujet dans leur question, et ils ont besoin pour accepter la réponse "il n'y a pas de différence" comme étant correct pour certains (la plupart?) les compilateurs.
    • Pour l'amour d'enlever tout doute, j'ai testé cela dans clang 3.4.2, et les deux boucles de produire la même assemblée à chaque -O niveau.
    • Je ne trouve pas cela du tout surprenant, car tout ce que vous avez placé dans la réserve de la section de la boucle sont des constantes de compilation. En tant que tel, je soupçonne un compilateur ne voient-ils la boucle sera toujours vrai ou faux et soit respectiively simplement jmp vers le début ou la suppression de la boucle complètement.
    • Qui enlève tout doute sur le comportement de la clang 3.4.2 dans la configuration dans laquelle vous l'avez utilisé.
    • Réponse intéressante. Je me demande ce qui se passe si vous allusion au compilateur de inline l'utilisateur de votre fonction...
    • Comme pour les fonctions définies par l'utilisateur , this réponse fournit une explication.
    • Pour info, .seh_endproc et .ident "GCC: (tdm64-2) 4.8.1" ne font pas partie de l'assemblée de la langue pour la boucle. La première de ces marques à la fin de la fonction, et le second, commente le fichier objet avec l'identité du compilateur qui l'a créé. (Normalement, il y aurait une fonction "épilogue", la compensation de la frame de pile et la délivrance d'un ret instruction, entre la boucle et le .seh_endproc, mais le compilateur a réalisé que le contrôle ne sera jamais franchir la boucle infinie, et donc a omis comme inutile.)
    • so measuring their "speed" is a bit nonsensical, vous avez appelé?
    • Vous avez montré la corrélation mais a affirmé que le lien de causalité. Il se pourrait que GCC optimisé de cette façon parce qu'il a vu que rien ne se passe à l'intérieur de la boucle.
    • Je ne vois pas comment le contenu (ou l'absence des présentes) de la boucle, pourrait éventuellement l'effet de ces optimisations (à l'exception de la possibilité de break états), mais je l'ai juste testé de toute façon et non, même avec le code à l'intérieur de la boucle, le saut est absolue et inconditionnelle pour les deux while(1) et while(2). N'hésitez pas à tester les autres, vous-même si vous êtes réellement intéressé.
    • Le principe de base ici semble être: tous les compilateurs, au minimum, doit choisir cmp eax, 0 (ou la machine locale est l'équivalent de "le résultat est égal à zéro"), comme le préféré de l'algorithme, et l'analyse avancée (optimisations) sera presque certainement produire une inconditionnelle de la sauter. La cote d'un compilateur de faire quelque chose d'autre semble pratiquement absurde, puisque c'est la méthode la plus simple de mise en œuvre de tests.
    • Cet exemple de programme est trop minimaliste, lire ceci: blog.llvm.org/2011/05/... , les compilateurs sont AUTORISÉS à faire QUOI que ce soit parce que la boucle ne s'arrête pas ici. ils pouvaient l'ignorer totalement, ou de générer des papillons.
    • C'est à peu près un comportement indéfini; il ne dit rien sur les boucles infinies.
    • gcc -O0 ne veut pas vraiment dire aucun optimisations. Cela signifie juste que le minimum nécessaire pour produire braindead debugable code, toujours en passant par toutes les représentations intermédiaires gcc utilise en interne. Faire encore pire que le code -O0 qui ressemble plus à une traduction littérale de la source n'est pas une fonctionnalité quelqu'un a déjà mis en œuvre. L'objectif pour -O0 est de compiler rapidement et de rendre le code, vous pouvez toujours en une seule étape, ligne par ligne dans un débogueur. -Og est similaire: optimiser pour le débogage.
    • Si l'intervieweur n'a pas été à l'aide de gcc ils devraient avoir demandé la version est plus rapide sur mon compilateur.

    InformationsquelleAutor ApproachingDarknessFish
  2. 278

    Oui, while(1) est beaucoup plus rapide que while(2), pour un être humain de lire! Si je vois while(1) dans l'inconnu de la base de code, je sais immédiatement ce que l'auteur veut, et mes globes oculaires peuvent continuer à la ligne suivante.

    Si je vois while(2), je vais probablement arrêter dans mon élan et essayer de comprendre pourquoi l'auteur n'a pas écrit while(1). L'auteur du doigt glisser sur le clavier? Ne les responsables de ce code utiliser while(n) comme un obscur commentant le mécanisme pour faire des boucles de l'air différent? C'est un brut de solution de contournement pour une fausse alerte dans certains brisé outil d'analyse statique? Ou est-ce une idée de ce que je suis en train de lire le code généré? Est-ce un bug résultant d'une mauvaise trouvez et remplacez-la totalité ou d'une mauvaise fusion, ou d'un rayon cosmique? Peut-être que cette ligne de code est censé faire quelque chose de radicalement différent. Peut-être qu'il était censé lire while(w) ou while(x2). Je ferais mieux de trouver l'auteur dans le fichier de l'histoire et de leur envoyer un "WTF" e-mail... et maintenant, j'ai rompu mon mental contexte. Le while(2) peut consommer plusieurs minutes de mon temps, quand while(1) aurait pris une fraction de seconde!

    J'exagère, mais seulement un peu. La lisibilité du Code est vraiment important. Et qui vaut la peine de mentionner, dans une interview!

    • Mes pensées exactement, et c'est précisément pourquoi, alors que (1) est plus rapide lol Même si je pense que c'était tout simplement l'ancien cas d'un gestionnaire d'essayer de se convaincre qu'il sait à propos de codage quand il ne fait pas, que nous avons tous vu, tout le monde veut être un jedi.
    • Absolument, ce n'est PAS exagéré du tout. Certainement le svn-annotate ou git blame (ou autre) sera utilisé ici, et en général il prend quelques minutes pour charger un fichier de blâmer l'histoire. Puis vient enfin de décider "ah, je comprends, l'auteur a écrit cette ligne, fraîchement sorti de l'école secondaire", vient de perdre 10 minutes...
    • Voté contre parce que je suis malade de conventions. Le développeur a ce chétif occasion d'écrire un nombre qu'il aime, puis quelqu'un d'ennuyeux vient et nags sur pourquoi il n'est pas 1.
    • J'ai perdu beaucoup plus de temps à la lecture de ce radotage (qui n'est pas valide DONC encore de réponse obtenu 162 votes, de plus que l'excellente réponse de Keith Thompson), alors je n'aurais jamais passé à chercher à while (2). La lisibilité du Code ma joue gauche ... pour qui écrire while (true). (Et je suis très triste pour Bogdan.)
    • Downvoted en raison de la rhétorique. La lecture while(1) est exactement la même vitesse que tout(2).
    • while(l) ressemble beaucoup à while(1)... Même innocent prospectives peuvent masquer subtile de bugs.
    • Je suis passé par exactement le même processus mental comme décrit dans cette réponse, il y a une minute quand j'ai vu while(2) dans le code (en bas à considérer "les responsables de ce code utiliser while(n) comme un obscur commentant le mécanisme pour faire des boucles de l'air différent?"). Donc non, vous n'êtes pas exagérer!
    • Un décent éditeur de test permettra d'utiliser des couleurs différentes pour les numéros et les noms de variables. Même VIM a la coloration syntaxique.
    • peut-être, mais pas tous les éditeurs ne. emacs par exemple ne pas utiliser une couleur différente pour les nombres et les variables par défaut. qemacs n'en soit pas une, et ma colorisation des choix un peu différent nuance de vert pour des variables et des nombres, qui ne permet pas de résoudre l'ambiguïté. Les messages d'erreur ne sont pas toujours colorisée soit. À l'aide d'équivoque noms résout le problème en toutes circonstances.
    • Emacs par défaut ne sont pas décent. De toute façon, while (true) est plus rapide que les deux d'entre eux 🙂
    • Je préfère for(;;), qui ne nécessite pas de <stdbool.h>

    InformationsquelleAutor Chris Culter
  3. 151

    Les questions /réponses indiquant le code généré par un compilateur pour une cible particulière, avec un certain ensemble d'options ne répondent pas complètement à la question-à moins que la question a été posée dans ce contexte spécifique ("ce Qui est plus rapide en utilisant gcc 4.7.2 pour x86_64 avec les options par défaut?", pour exemple).

    Autant que la définition du langage, dans la machine abstraite while (1) évalue la constante entière 1, et while (2) évalue la constante entière 2; dans les deux cas, le résultat est comparé pour l'égalité à zéro. La langue standard ne dit absolument rien sur la performance relative des deux constructions.

    Je peux imaginer qu'une très naïf compilateur peut générer du code machine pour les deux formes, au moins lorsqu'il est compilé sans en demander l'optimisation.

    D'autre part, les compilateurs C ne doit absolument évaluer certains expressions constantes au moment de la compilation, lorsqu'ils apparaissent dans des contextes qui nécessitent une expression constante. Par exemple, ceci:

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

    nécessite un diagnostic, un paresseux compilateur n'a pas la possibilité de différer l'évaluation de 2+2 jusqu'à ce que le temps d'exécution. Depuis un compilateur doit avoir la capacité d'évaluer des expressions constantes au moment de la compilation, il n'y a aucune bonne raison de ne pas profiter de cette possibilité, même quand il n'est pas nécessaire.

    Le C standard (N1570 6.8.5p4) dit que

    Une itération d'instruction d'une déclaration appelée la corps de boucle être
    exécuté à plusieurs reprises jusqu'à ce que le contrôle de l'expression compare égal à
    0.

    Donc pertinentes des expressions constantes sont 1 == 0 et 2 == 0, qui s'évaluer à l' int valeur 0. (Ces comparaisons sont implicites dans la sémantique de la while boucle; ils n'existent pas en tant que réel C expressions.)

    Une perverse naïf compilateur pourrait générer un code différent pour les deux constructions. Par exemple, pour la première elle pourrait générer une inconditionnelle de la boucle infinie (traitement de 1 est un cas particulier), et pour le second, il pourrait générer explicite au moment de l'exécution de comparaison équivalente à 2 != 0. Mais je n'ai jamais rencontré un compilateur C qui serait effectivement se comporter de cette façon, et je doute sérieusement qu'un tel compilateur existe.

    La plupart des compilateurs (je suis tenté de dire que l'ensemble de la production-de la qualité des compilateurs) ont des options à la demande des optimisations supplémentaires. En vertu de cette option, c'est encore moins probable qu'un compilateur de générer un code différent pour les deux formes.

    Si votre compilateur génère un code différent pour les deux constructions, vérifiez d'abord que les différentes séquences de code en fait ont des performances différentes. S'ils le font, essayez de compiler à nouveau avec une option d'optimisation (si disponible). Si elles diffèrent, faire un rapport de bogue pour le fournisseur de compilateur. Ce n'est pas (nécessairement) un bug dans le sens d'une non conformité à la norme C, mais il est presque certainement un problème qui doit être corrigé.

    Ligne du bas: while (1) et while(2) presque certainement avoir les mêmes performances. Ils ont exactement la même sémantique, et il n'y a aucune bonne raison pour n'importe quel compilateur de ne pas générer de code identique.

    Et si il est parfaitement légal pour un compilateur de générer plus rapidement le code pour while(1) que pour while(2), il est tout aussi légal pour un compilateur de générer plus rapidement le code pour while(1) que pour une autre occurrence de while(1) dans le même programme.

    (Il y a une autre question implicite dans l'un vous demande: Comment faites-vous face avec un enquêteur qui insiste sur une mauvaise technique. Ce serait sans doute une bonne question pour le lieu de Travail).

    • "Dans ce cas, la (implicite) des expressions constantes sont de 1 != 0 et 2 != 0, à la fois de ce qui s'évaluer à la valeur int 1" ... C'est trop compliqué, et inexactes. La norme précise simplement que le contrôle de l'expression de while doit être de type scalaire et le corps de la boucle est répétée jusqu'à ce que l'expression compare égal à 0. Cela ne veut pas dire qu'il n'y est implicite expr != 0 qui est évalué ... qui obligerait le résultat de cette -- 0 ou 1 -- être à son tour par rapport à 0, à l'infini. Non, l'expression n'est par rapport à 0, mais cette comparaison ne produit pas de valeur. P. S. je upvoted.
    • Je comprends votre point, et je vais mettre à jour ma réponse pour l'aborder. Ce que je voulais dire, cependant, est que le standard de la formulation "... jusqu'à ce que le contrôle de l'expression compare égal à 0" implique l'évaluation de <expr> == 0; qu'est ce que "compare égal à 0" moyen en C. Cette comparaison est une partie de la sémantique de la while boucle. Il n'y a pas d'implication, soit dans la norme ou dans ma réponse, que le résultat doit être comparé à 0 de nouveau. (Je l'aurais écrit == plutôt que !=.) Mais cette partie de ma réponse n'était pas claire, et je vais le mettre à jour.
    • ""compare égal à 0" signifie, C" -- mais que la langue est dans le standard, pas en C ... la mise en œuvre de la comparaison, il ne génère pas de langage C de comparaison. Vous écrivez "qui s'évaluer à la valeur int 1" -- mais aucune évaluation de ce type se produit jamais. Si vous regardez le code généré pour while (2), while (pointer), while (9.67), par le plus naïf, unoptimized compilateur, vous ne verrez pas de code généré des rendements 0 ou 1. "Je l'aurais écrit == plutôt que !=" -- non, cela n'aurait pas fait sens.
    • Hmmm. Je ne veux pas dire par là que le "compare égal à 0" implique l'existence d'une ... == 0 C expression. Mon point est que les deux "compare égal à 0" requis par la norme de description de while boucles et explicite x == 0 expression impliquent logiquement la même opération. Et je pense que un douloureusement naïf C compilateur peut générer du code qui génère une int valeur de 0 ou 1 pour tout while boucle -- bien que je ne crois pas que le compilateur réel est tout à fait naïf.
    • "Je ne veux pas dire par là" ... mais vous l'avez fait exactement cela, et vous faire à nouveau quand vous écrivez "je pense qu'un douloureusement naïf C compilateur peut générer du code qui génère un int valeur de 0 ou 1 pour tout alors que la boucle". Voir le code d'un réel douloureusement naïf compilateur génère dans anatolyg réponse: une comparaison explicite -- dans la machine cible, pas en C -- entre le contrôle de l'expression et de zéro. C'est ce que la norme appelle, pas l'évaluation de certains C une expression qui a un rendement de 0 ou 1. Si vous ne l'obtenez pas, la poursuite de la discussion ne sert à rien, donc je me suis fait ici.
    • Ne serait pas de la définition du langage de permettre à un compilateur de faire absolument tout ce qu'il veut avec l'une des expressions? Personnellement, je méprise l'idée de faire des effets secondaires sans les boucles infinies UB (je pense à une bien meilleure définition serait de dire qu'un compilateur n'a pas besoin d'effectuer tout calcul jusqu'à ce que ses résultats seraient affecter les effets secondaires produits par un programme, et de temps d'exécution, même si l'infini, n'est pas considéré comme un effet secondaire). Pour avez défini le comportement, le code devrait au minimum définir un mondial volatile unsigned variable et de l'incrémenter à l'intérieur de la boucle.
    • Il n'est pas un comportement indéfini. C11 a ajouté une nouvelle règle (N1570 6.8.5p6) provoquant certains les boucles infinies à avoir un comportement indéfini, mais il ne s'applique que lorsque le contrôle de l'expression n'est pas une expression constante. Le comportement de int main(void){while (1){}} est bien défini; il n'a pas d'effets secondaires et ne s'arrête pas.
    • Serait la règle de rendre int shouldHang; while(1) if (!shouldHang) break; différente de while(shouldHang); [reconnaissant que, dans les deux cas, si shouldHang est observée vrai, une fois, un compilateur serait soumis à aucune obligation de préavis, si sa valeur est de l'extérieur modifiée]. Aussi, est-il rien qui précise que "en supposant que la boucle s'arrête" est équivalent à "en supposant que la boucle s'arrête pour une raison quelconque admis par la norme"? Que penseriez-vous de ma proposition de règle ou de précisions?
    • Personnellement, je pense que l'arrêt ou non de résiliation doit être considéré comme un effet secondaire. Apparemment le comité (sans doute influencé par les éditeurs de compilateurs), a estimé que les possibilités d'optimisation mis à disposition par la rupture de cette hypothèse en vaut le coût. Je n'aime pas le "peut être assumée par la mise en œuvre pour mettre fin à" libellé de la norme doit décrire la manière dont les programmes sont nécessaires (ou ne doit pas) se comportent, et de l'exprimer dans les termes du compilateur interne "hypothèses" est à mon humble avis bâclée. Si ça ne tenait qu'à moi, je ne le ferais pas "améliorer" la règle, j'avais l'anéantir.
    • Il est l'utilité de permettre à un code qui est séquencé par rapport à l'autre code peut être exécuté en parallèle avec ce code, et en permettant un compilateur pour envisager un effet secondaire de la boucle tant que séquencé par rapport à n'importe quel code qui ni calcule les valeurs utilisées par la boucle (et doit donc précéder l'), ni utilise les valeurs calculées dans la boucle (et doit donc suivre). La valeur de cette dernière allocation si les compilateurs sont autorisés à examiner les boucles non, même dans les cas où le compilateur ne peut pas prouver que les boucles de résilier. Note que je propose de la spec, ...
    • ...les compilateurs qui serait nécessaire pour produire un résultat cohérent avec le fait d'avoir le compilateur commencer une nouvelle exécution en parallèle de l'unité exécuter le code dans la boucle, à chaque fois que le thread principal atteint le point de départ de cette boucle.
    • Remarque: C'est déjà un Travail question: workplace.stackexchange.com/questions/4314/...
    • c'est une lecture tout le monde doit avoir à l'esprit lorsque l'on parle de résiliation et optimisations possibilités: blog.llvm.org/2011/05/... et: blog.regehr.org/archives/140

    InformationsquelleAutor Keith Thompson
  4. 138

    Attendez une minute. L'interviewer, avait-il ressembler à ce mec?

    Ce qui est plus rapide: while(1) ou de tout(2)?

    Il est assez mauvais que l'enquêteur lui-même a échoué cette interview,
    que faire si d'autres programmeurs à ce société de "faire passer" ce test?

    Pas. Évaluer les déclarations 1 == 0 et 2 == 0 devrait être tout aussi rapide. Nous pourrait imaginer pauvres compilateur implémentations où l'on peut être plus rapide que les autres. Mais il n'y a pas bonne raison pour laquelle on devrait être plus rapide que l'autre.

    Même si il y a un peu obscures circonstances où la réclamation serait vrai, les programmeurs ne doit pas être évaluée en se basant sur la connaissance de l'obscur (et dans ce cas, flippant) de trivia. Ne vous inquiétez pas au sujet de cette entrevue, le meilleur choix ici est à pied.

    Avertissement: Ce n'est PAS un original de bande dessinée Dilbert. Ce n'est qu'un mashup.

    • Ce serait drôle, si c'était à aussi contient une réponse à la question.
    • non mais vraiment, nous pouvons tous imaginer assez facilement que tous les compilateurs écrits par des entreprises sérieuses produira raisonnable code. prenons le "non optimisé cas" /O0, peut-être que ça va finir comme anatolyg a posté. Alors une question de CPU, le cmp opérande exécuter en moins de cycles de la comparaison de 1 à 0 de 2 à 0 ? combien de cycles faut-il pour exécuter cmp en général ? est-il variable selon les modèles de bits ? sont-ils plus "complexe" modèles de bits qui ralentissent cmp ? Je ne connais pas personnellement. on pourrait imaginer un super idiot de mise en œuvre de la vérification, bit par bit de rang 0 à n (par exemple n=31).
    • C'est mon point de trop: la cmp opérande doit être aussi rapide pour 1 et 200. Probablement que nous pourrait imaginer idiot implémentations où ce n'est pas le cas. Mais peut-on imaginer un non idiot mise en œuvre où while(1) est plus rapide que while(200)? De même, si dans certains pré-historique de l'âge, de la seule mise en œuvre était idiot comme ça, devrions-nous l'histoire aujourd'hui? Je ne le pense pas, c'est pointu à poil entretien de patron, et l'un des joyaux à ce!
    • la cmp opérande exécuter en moins de cycles de la comparaison de 1 à 0 de 2 à 0" -- Non. Vous devez apprendre ce qu'est un cycle. "Je ne connais pas personnellement. on pourrait imaginer un super idiot de mise en œuvre de la vérification, bit par bit de rang 0 à n" -- ou dans l'autre sens, toujours en train de faire l'interviewer un ignorant, imbécile. Et pourquoi vous soucier de vérifier, peu à peu? La mise en œuvre pourrait être un homme dans une boîte qui décide de prendre une pause déjeuner dans le milieu de l'évaluation de votre programme.
    InformationsquelleAutor janos
  5. 79

    Votre explication est correcte. Cela semble être une question qui teste votre confiance en soi en plus de connaissances techniques.

    Par ailleurs, si vous avez répondu

    Les deux morceaux de code sont tout aussi rapides, parce que les deux prendre un temps infini pour compléter

    l'intervieweur dire

    Mais while (1) pouvez faire plus d'itérations par seconde; pouvez-vous expliquer pourquoi? (ce qui est un non-sens; le contrôle de votre confiance encore une fois)

    Donc par répondre comme vous l'avez fait, vous avez économisé un peu de temps dont vous auriez autrement des déchets sur l'examen de cette question.

    Voici un exemple de code généré par le compilateur sur mon système (MS Visual Studio 2012), avec les optimisations éteint:

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

    Avec les optimisations activée:

    xxx:
    jmp xxx

    De sorte que le code généré est exactement le même, au moins avec un compilateur optimisant.

    • cmp eax, 1 (or 2, depending on your code) - qui n'est pas entièrement vrai. L'opérande pour while est de type booléen, donc qu'il ne correspond pas complètement à l'opération sur des nombres entiers dans l'assemblée (même si elle peut, aussi longtemps que la sémantique est préservée).
    • Ce code est vraiment ce que le compilateur sorties sur mon système. Je ne l'ai pas inventée.
    • Je n'ai pas dit que vous l'avez fait (bien, votre compilateur ne valait sûrement pas la sortie de la partie entre parenthèses), juste pour dire que comparer à 1,2,3, ou 10 000 n'ont pas de correspondance 1-1 à la while (some boolean value) logique. Votre compilateur peut choisir cette mise en œuvre, s'il conserve le fucntionality
    • Quel compilateur/compiler réglages avez-vous utilisé?
    • bloc - "L'opérande de tout est de type booléen" -- une absurdité totale. Êtes-vous l'interviewer? Je vous suggère de vous familiariser avec le langage C et de son niveau avant de faire de telles revendications.
    • "Je n'ai pas." -- Merci de ne pas prêter attention à bloc, qui est de dire des sottises. C n'a pas de type booléen (il n'ont _Bool dans stdbool.h, mais ce n'est pas la même, et la sémantique de l' while longtemps précédé) et l'opérande de while n'est pas de booléen ou _Bool ou de tout autre type spécifique. L'opérande de while peut être aucun expression ... le tout se brise sur 0 et continue sur la non-0.
    • "Les deux morceaux de code sont tout aussi rapides, parce que les deux prendre un temps infini pour achever" m'a fait penser à quelque chose d'intéressant. La seule façon de mettre fin à une boucle infinie serait un peu le point d'être renversé par une particule chargée ou le matériel défaillant: la modification de la déclaration de while (00000001) {} à while (00000000) {}. Le plus vrai bits que vous avez le moins de chance de la valeur de retournement de faux. Malheureusement, 2 n'a qu'un seul vrai bits. 3, cependant, serait pour beaucoup plus longtemps. Cela ne s'applique à un compilateur, ce qui n'est pas toujours d'optimiser cette distance (VC++).
    • Est-il plus petite possible d'optimisation pourrait atteindre en éliminant les valeurs qui pourrait être retournée/toggle?
    • nope. Pour qu'une inversion de bits à fait se traduire par quelque chose comme cela, vous êtes en parle de temps d'exécution dans des dizaines de milliers d'années. Un simple expérience de pensée. Si vous êtes originaire d'une race immortelle, vous souhaiterez peut-être utiliser -1 pour éviter bit de basculement d'affecter votre programme.
    • souhaiterez peut-être utiliser -1" -- je voudrais utiliser un compilateur optimise loin de la constante, qui est presque tous d'entre eux.
    • "L'opérande de tout peut être aucun expression" - je l'ai ajoutée "de type scalaire".
    • Il m'a fait me poser cette question idiote parce que vous dites 3 bits irait beaucoup plus longtemps que les 2 bits.
    • Quelle est donc la bonne réponse si c'est un auto-test de confiance? Les codificateurs ont pour tester des hypothèses, chaque jour, d'être trop confiant est une recette pour un désastre.
    • Vous tous omis de parler de la CPU, le code est le même, mais que dire de la cmp opération ? personne n'a dit qu'il avait une constante de temps d'exécution quelle que soit la valeur de l'opérande pour l'instant. Vous avez à dire, et de le prouver, ALORS votre argument serait fini. Les compilateurs sont une chose, c'est très important, mais l'histoire ne s'arrête pas là tout de suite.
    • Le non-optimale de la version 32 bits, mais l'optimisation de peut-être 64 du code, donc peut-être que cela fonctionnera plus lentement parce que le jmp prendra plus de temps que le registre est plus grande? 🙂
    • En toute confiance aller à l'encontre de l'enquêteur semble être une stratégie risquée pour moi. Il est possible qu'il est juste "test de votre confiance" mais c'est de l'OMI beaucoup plus probable qu'il croit vraiment ce qu'il dit.
    • Saut dans nouveau quelques années plus tard."C n'a pas de type booléen (il n'ont _Bool dans stdbool.h, mais ce n'est pas la même, et sur le plan sémantique, alors que pendant longtemps l'ont précédé)". C, en commençant par le C99, a un type booléen, appelé _Bool. Il n'est pas défini dans <stdbool.h>, c'est prédéfinie comme int est. <stdbool.h> définit bool comme un alias pour _Bool. D'autre part, de l'égalité et de comparaison les opérateurs de produire des résultats de type int, pas de type _Bool -- mais je ne dirais pas que les causes _Bool de ne pas être un type booléen.

    InformationsquelleAutor anatolyg
  6. 60

    L'explication la plus probable de la question est que le journaliste pense que le processeur vérifie que les bits des nombres, un par un, jusqu'à ce qu'il frappe une valeur non nulle:

    1 = 00000001
2 = 00000010

    Si l' "est égal à zéro?" algorithme commence à partir de la droite du nombre et de vérifier chaque morceau jusqu'à ce qu'il atteint zéro, les bits, les while(1) { } boucle aurait pour vérifier deux fois plus de bits par itération que l' while(2) { } boucle.

    Cela nécessite un très mauvais modèle mental de la façon dont les ordinateurs fonctionnent, mais il a sa propre logique interne. Une façon de vérifier serait de demander si while(-1) { } ou while(3) { } serait tout aussi rapide, ou si while(32) { } serait encore plus lente.

    • Je suppose que l'intervieweur malentendu serait plus un "2 est un int qui doit être converti en une valeur de type boolean pour être utilisé dans une expression conditionnelle, alors que le 1 est déjà booléenne."
    • plus cette probabilité : stackoverflow.com/questions/24848359/...
    • Et si la comparaison de l'algorithme commence à partir de la gauche, c'est l'autre manière autour.
    • +1, c'est exactement ce que je pensais. vous pourrait parfaitement imaginer quelqu'un de croire que, fondamentalement, la cmp algorithme d'un PROCESSEUR est un linéaire de contrôle de bit, avec un début de sortie de boucle sur la première différence.
    • Il semble avoir besoin d'un modèle mental qui suppose quelque chose comme: le PROCESSEUR de l'horloge de la longueur du cycle est le temps qu'il faut de l'électricité pour parcourir la distance pour effectuer la plus simple opération logique (comme passer à travers le premier niveau de portes XOR ou quelque chose). Bien sûr, l'horloge de la longueur du cycle est en fait un arbitraire contrainte de temps basé sur la physique de la CPU, un quantum contre le CPU fabricant de construire un catalogue des instructions de différentes horloge coûts de cycle. À bien y penser, peut-être que le modèle mental est juste que les Processeurs ne pouvez pas effectuer d'opérations électriques sur le registre bits en parallèle?
    • Voici un beau rappel sur l'équivalence de la fonction qui, lorsqu'il est combiné avec un "Grand ET", produit d'un circuit de comparer bytes: calculemus.org/logsoc03/bramki/LogGates1.html
    • Je n'avais même pas pensé que quelqu'un pourrait penser de cette façon. Tout bon compilateur émet le code qui utilise une inconditionnelle de la branche pour une boucle infinie. La question dans mon esprit est de savoir si il existe des compilateurs tellement stupides qu'ils ne reconnaissent while(1) (et peut-être while(42)) comme infini-boucle d'idiomes, pas le cas général d'une non-zéro constante à la compilation.
    • Selon analotlyg réponse, MSVC en mode debug vraiment ne parviennent pas à reconnaître comme une boucle infinie, et rend le code à zéro d'un registre et de le comparer avec une immédiate 1, qui est hilarant. Mais encore l'égalité de la taille du code et de la vitesse d'exécution pour les deux. Dépendant des données temps d'exécution sont très rares sur n'importe quel CPU pour le commun des instructions simples. C'est le cas pour des instructions complexes (comme div. Dans certains Processeurs, peut-être mul.) lente mais constante de temps est commun dans certaines conceptions, dépendant des données n'est pas. (esp. en dehors de l'ordre de Processeurs, de la planification est dur avec latence variable.)
    • le but de unoptimized code compilé dans un contexte de débogage devient plus clair quand vous pensez à ce sujet les difficultés d'un débogueur en mode pas à pas grâce à l'optimisation de code. (Ce morceau de code n'cette ligne de source, je suis en rupture sur correspondent à? Il ne correspond à aucune des instructions à tous?)
    • À droite, mais rien de vous empêche de l'optimisation de certains dans un C déclaration comme gcc et clang faire dans leur mode debug (-O0). par exemple, l'optimisation de while(1) { } à un jmp au bas de la boucle. Mais chaque déclaration encore compilées à un bloc contigu de l'asm. Comme vous pouvez le voir sur le Compilateur de l'Explorateur de couleur de la surbrillance (godbolt.org/z/Xoegb4) les instructions sont toujours appariés à des blocs de l'asm dans un façon saine. En essayant de définir un point d'arrêt sur la while(1) lui-même vous donnera le haut de la boucle, ce qui est bien.
    • Ou la manière de la gcc/clang de regarder dans leur représentation interne, while(1) n'est pas une condition à tous, il vient de est une inconditionnelle de la boucle. De la même façon les programmeurs de le regarder. Cela ne prend pas l'asm à mettre en œuvre, autre que la boucle de la branche.
    • vous faites un bon point. Mais apparemment, MSVC ne fonctionne pas comme ça. Je n'ai pas recherché si le C ou C++ spécifications besoin pour évaluer loin dans le code résultant. Je soupçonne qu'ils ne le font pas et, par conséquent, MSVC ne serait pas mal dans la production d'un tel code. Tant qu'il évalue pleinement des expressions constantes dans les contextes où la norme exige qu'elle, il n'y a pas de problème. (vous ne pouvez pas utiliser std::log10 ou d'autres fonctions mathématiques comme constexprdans MSVC). Si vous voulez une libération efficace, vous n'allez pas le compiler en mode de débogage, de toute façon.
    • ICO C/C++ spécifier rien du tout au sujet de toute sorte de "mode debug". C'est purement une mise en œuvre de la fonctionnalité. Les normes ISO donner de la mise en œuvre complète de la liberté, tant que le programme qui produit le même observables résultats que le C++ machine abstraite. (C'est le "comme-si" la règle.) La seule chose qui vient de loin, c'est que volatile accès doivent vraiment se passer comme à l'écrit. Le fait que les données des courses sur des non-atomique variables sont UB (dans le C11 modèle de mémoire) signifie que même l'ordre de l'évolution des variables globales ne compte pas "observables".
    • Je n'ai jamais entendu personne (autre que vous) affirment que la gcc ou clang est -O0 de sortie n'est pas assez littérale. Et fait amusant: gcc même des optimisations comme Pourquoi ne GCC utilisent la multiplication par un nombre étrange dans la mise en œuvre de division entière? au -O0 quand il est dans un état unique. voir, par exemple, Pourquoi la division entière par -1 (négatif) résultat de la FPE?. Et BTW, le débogage en mode performance est parfois pertinent pour les jeux ou d'autres choses qui en temps réel les exigences pour être utilisable à tous.
    • jamais entendu quelqu'un (autre que vous) affirment que la gcc ou clang est -O0 de sortie n'est pas assez littérale." Je n'ai jamais dit une telle chose et je n'ai pas de gcc ou clang dans l'esprit à tous. Vous devez être erreur de lecture, moi. Je ne suis pas de votre avis que MSVC produit est hilarant.
    • tout ce que je voulais dire, c'est que vous disiez que la boucle doit être plus complexe que gcc/ clang faire. Je ne voulais pas vous accuser de quoi que ce soit.
    • vous pouvez très bien instruire MSVC pour produire un code optimisé lors du débogage, vous pouvez donc le while (1) optimisé loin, même alors. Cependant, il y a une véritable différence entre les deux points d'arrêt mis à la pendant et immédiatement après la { l'intérieur de la boucle, au moins dans MSVC. La première sera de briser une seule fois, avant l'entrée dans la boucle et l'autre au début à chaque itération, ce qui peut être important lorsque la boucle de contenu n'est pas trivial. Et si vous activez les optimisations pour le débogage, le premier point d'arrêt sera disparu. Il n'est pas besoin pour être aussi complexe que cela, mais il peut aider.
    • intéressant. GCC / clang ont le même effet, mais seulement pour les boucles avec un non-trivial condition. Après gcc -g -O0, si vous utiliser GDB pour définir un point d'arrêt sur la while(1) ligne il s'applique en fait à la première ligne du corps de la boucle. Mais un point d'arrêt sur la while(x) est effectivement juste avant de la boucle. En asm, c'est une pause sur l'adresse de l' jmp avant la boucle appropriée qui saute de la condition de la boucle du bas. (Pourquoi boucles toujours compilé dans "do...while" style " (queue de saut)?). Je suis curieux de ce que l'adresse de MSVC allait se briser sur.
    • J'ai eu tort, dans MSVC un point d'arrêt sur la while(1) ne fait pas de pause avant la boucle, mais sur l'expression. Mais encore, elle s'effondre à l'intérieur de la boucle lors de l'optimisation de l'expression à l'écart. Prendre ce code avec de nombreuses pauses. Dans unoptimized mode de débogage, vous obtenez ceci. Lors de l'optimisation, de nombreux points d'arrêt automne ou même des répercussions sur la fonction suivante (l'IDE montre le résultat des points d'arrêt lors du débogage) - correspondant démontage.

    InformationsquelleAutor Ryan Cavanaugh
  7. 32

    Bien sûr, je ne connais pas les intentions réelles de ce gestionnaire, mais je propose une vision complètement différente: Lors de l'embauche d'un nouveau membre dans une équipe, il est utile de savoir comment il réagit à des situations de conflit.

    Ils vous ont poussé dans le conflit. Si cela est vrai, ils sont intelligents et que la question est bonne. Pour certaines industries, comme les services bancaires, de poster votre problème de Pile Overflow pourrait être un motif de rejet.

    Mais bien sûr, je ne sais pas, je viens de proposer une option.

    • Il est en effet excellente, mais alors que(2) vs while(1) n'est évidemment prise à partir de dilbert comics. Il NE peut pas être inventé par quelqu'un dans son esprit droit (comment quelqu'un de venir avec tout(2) comme une chose possible, d'écrire, de toute façon ?). Si votre hypothèse était vraie, certainement vous donner un problème de façon unique que vous pouvez google pour elle. Du genre "c'est tout(0xf00b442) plus lent que le while(1)", la manière dont la banque serait de trouver le inerviewee la question autrement ? pensez-vous qu'ils sont de la NSA, et d'avoir accès à keyscore ?
    InformationsquelleAutor Tõnu Samuel
  8. 25

    Je pense que l'indice se trouve dans "demandé par un senior manager". Cette personne évidemment cessé de programmation lorsqu'il est devenu directeur et puis il a fallu lui plusieurs années pour devenir un gestionnaire principal. Jamais perdu l'intérêt dans la programmation, mais n'a jamais écrit une ligne depuis ces jours. Donc sa référence n'est pas "tout compilateur décent là-bas" que certaines réponses mentionnent, mais "le compilateur cette personne a travaillé avec de 20 à 30 ans".

    À cette époque, les programmeurs ont passé une partie considérable de leur temps à essayer différentes méthodes pour faire de leur code plus rapide et plus efficace que le temps CPU de la "centrale d'un mini ordinateur" était tellement précieuses. Comme l'ont fait les gens de l'écriture de compilateurs. Je suppose que le seul compilateur sa société disponibles à l'époque optimisé sur la base de la "rencontre fréquemment des déclarations qui peuvent être optimisés" et a pris un peu un raccourci lors de la rencontre d'un certain temps(1) et de les évaluer tout le reste, y compris un certain temps(2). Ayant eu une telle expérience pourrait expliquer sa position et sa confiance en elle.

    La meilleure approche pour obtenir que vous avez embauché est probablement celui qui permet au senior manager de se laisser emporter et la leçon de 2-3 minutes sur "le bon vieux temps de la programmation" avant de VOUS douceur le conduire vers la prochaine entrevue sujet. (Bon timing est important ici - trop vite et vous êtes interrompre l'histoire - trop lent et que vous êtes étiqueté comme quelqu'un avec attention insuffisante). Ne lui dis à la fin de l'entrevue que vous serais très intéressé d'en apprendre plus sur ce sujet.

    InformationsquelleAutor OldFrank
  9. 19

    Vous devriez lui ai demandé comment était-il parvenu à cette conclusion. En vertu de tout bon compilateur là, les deux compiler à la même asm instructions. Donc, il devrait vous ai dit que le compilateur pour commencer. Et même alors, vous devez connaître le compilateur et de plate-forme très bien à même de faire une partie théorique d'une hypothèse. Et à la fin, il n'a pas vraiment d'importance dans la pratique, puisqu'il existe d'autres facteurs externes comme la fragmentation de la mémoire ou de la charge du système, qui aura une influence sur la boucle de plus de ce détail.

    • Si vous avez donné votre réponse, et ils vous disent que vous vous trompez, il n'y a aucune raison que vous ne pouvez pas leur demander d'expliquer pourquoi. Si Anatolyg est correct et c'est un test de votre auto confiance, alors vous devriez être en expliquant pourquoi vous avez répondu de cette façon que vous avez fait et leur demander la même chose.
    • Je voulais dire que la première chose à vous dire. Il ne peut pas être "Pourquoi est x plus vite?" "Je ne sais pas; pourquoi est x plus vite?". Évidemment, en ayant répondu correctement, vous pouvez alors demander.
    InformationsquelleAutor Valentin Radu
  10. 18

    Pour le bien de cette question, je dois ajouter que je me souviens de Doug Gwyn à partir de C Comité de rédaction que certains des premiers compilateurs C sans l'optimiseur de passer permettrait de générer un test de l'assemblée de la while(1) (en comparant à for(;;) qui ne l'ont pas).

    Je voudrais répondre à l'enquêteur en donnant cette note historique et ensuite de dire que même si je serais très surpris n'importe quel compilateur l'a fait, un compilateur pourrait avoir:

    • sans optimiseur de passer au compilateur de générer un test pour les deux while(1) et while(2)
    • avec l'optimiseur de passer le compilateur est invité à optimiser (avec un saut inconditionnel) tous les while(1) parce qu'ils sont considérés comme idiomatiques. Cela laisserait le while(2) avec un test et en fait donc une différence de performance entre les deux.

    Je serais bien sûr ajouter à l'intervieweur que n'envisage pas while(1) et while(2) la même construction est un signe de faible-l'optimisation de la qualité que ce sont les équivalents des constructions.

    InformationsquelleAutor ouah
  11. 9

    Une autre prise sur une telle question serait de voir si vous avez le courage de dire à votre gestionnaire qu'il/qu'elle est fausse! Et comment doucement, vous pouvez la communiquer.

    Mon premier réflexe aurait été de générer de l'assemblée de sortie pour afficher le gestionnaire de tout bon compilateur doit prendre soin d'elle, et si elle n'est pas ainsi, vous allez vous présenter le prochain patch pour elle 🙂

    InformationsquelleAutor UncleKing
  12. 8

    De voir tant de gens se plonger dans ce problème, montre exactement pourquoi cela pourrait très bien être un test pour voir combien de temps vous voulez micro-optimiser choses.

    Ma réponse serait; il n'a pas beaucoup d'importance, j'ai plutôt l'accent sur le problème de l'entreprise qui nous sont les problèmes. Après tout, c'est ce que je vais être payé pour.

    De plus, j'opterais pour while(1) {} parce qu'il est plus commun, et d'autres coéquipiers n'aurait pas besoin de passer du temps à comprendre pourquoi quelqu'un ferait pour un nombre plus élevé que 1.

    Allez maintenant écrire le code. 😉

    • Sauf si vous êtes payée pour optimiser en temps réel les code pour laquelle vous avez besoin de se raser juste 1 ou 2 millisecondes pour s'adapter à son temps d'exécution de la demande. Bien sûr, c'est un travail de l'optimiseur, diraient certains - c'est si vous avez un optimiseur pour votre architecture.
    InformationsquelleAutor Bart Verkoeijen
  13. 5

    Si vous êtes inquiet au sujet de l'optimisation, vous devez utiliser

    for (;;)

    car qui n'a pas de tests. (cynique) de mode

    • C'est pourquoi il est sage d'utiliser while(2), il laisse de la place pour l'optimisation, il vous suffit de passer à for (;;) lorsque vous êtes prêt pour un gain de performance.
    InformationsquelleAutor Tom Tanner
  14. 4

    Il me semble que c'est l'une de ces questions d'entrevue comportementales masqué sous la forme d'une question technique. Certaines entreprises ne sont - elles se posera une question technique qui devrait être assez facile pour n'importe quel programmeur compétent pour répondre, mais lorsque la personne interrogée donne la bonne réponse, l'enquêteur va leur dire qu'ils sont mauvais.

    La société veut voir comment vous allez réagir dans cette situation. Vous êtes-vous assis là tranquillement et ne poussez pas que votre réponse est correcte, en raison soit de doute de soi ou la peur de déplaire à l'interviewer? Ou êtes-vous prêt à défier une personne en autorité qui tu sais, c'est mal? Ils veulent voir si vous êtes prêts à défendre vos convictions, et si vous pouvez le faire dans un de tact et de respect.

    InformationsquelleAutor pacoverflow
  15. 3

    J'ai utilisé pour programmer en C et assembleur de retour quand ce genre de non-sens aurait peut-être fait une différence. Quand il a fait faire une différence, nous l'avons écrit dans l'Assemblée.

    Si je pose cette question, j'aurais répété Donald Knuth célèbre de 1974 à propos de l'optimisation prématurée et marcha si l'interviewer n'a pas de rire et de se déplacer sur.

    • Étant donné qu'il a également déclaré: "Dans les disciplines de l'ingénierie d'une amélioration de 12%, obtient facilement, n'est jamais considéré comme marginal et je crois que le même point de vue qui doit prévaloir dans l'ingénierie du logiciel", je pense que vous la marche n'est pas injustifiée.
    InformationsquelleAutor Peter Wooster
  16. 3

    Peut-être l'intervieweur pose une telle question stupide intentionnellement et je voulais vous faire 3 points:

    1. Le raisonnement de base. Les deux boucles sont infinies, il est difficile de parler de la performance.
    2. Connaissances sur l'optimisation des niveaux. Il voulait entendre de vous, si vous laisser le compilateur faire aucune optimisation pour vous, il serait d'optimiser l'état, en particulier si le bloc n'était pas vide.
    3. Connaissances sur l'architecture des microprocesseurs. La plupart des architectures ont un CPU d'instruction pour la comparaison avec la valeur 0 (tout n'est pas nécessairement plus rapide).
    InformationsquelleAutor Rok Kralj
  17. 2

    Voici un problème: Si vous écrivez un programme et de mesurer sa vitesse, la vitesse de chacune des deux boucles pourrait être différent! Pour certains comparaison raisonnable: 

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

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

    avec un peu de code ajouté que les estampes de l'époque, certains des effets aléatoires, comme la façon dont la boucle est placée à l'intérieur d'une ou deux lignes de cache pourrait faire une différence. Une boucle peut par hasard être entièrement à l'intérieur d'une ligne de cache, ou au début d'une ligne de cache, ou à cheval sur deux lignes de cache. Et ainsi, quelle que soit l'interviewer revendications est plus rapide pourrait en fait être plus rapide qu'une coïncidence.

    Pire des cas: Une optimisation du compilateur n'est pas à comprendre ce que la boucle n', mais les chiffres que les valeurs produites lors de la deuxième boucle est exécutée sont les mêmes que produite par la première. Et de générer le code complet pour la première boucle, mais pas pour le second.

    • Les "lignes de cache" raisonnement ne fonctionne que sur une puce qui a un très petit cache.
    • C'est à côté de la question. Des Questions à propos de la vitesse d'assumer "toutes choses égales par ailleurs".
    • Mal. Le problème n'est pas de savoir si le code s'inscrit dans le cache ou pas - bien sûr, une boucle serrée, l'ajustement sera parfait. Le problème est que les transformateurs doivent chercher des instructions à partir de la mémoire, généralement par le biais de cache, dans le décodeur d'instruction. Et généralement, le décodeur d'instruction ne peut récupérer des instructions à partir d'une ligne de cache à la fois. Donc, aller chercher les mêmes dix octets des instructions à partir d'une seule ligne de cache sera plus rapide que d'aller chercher lorsqu'il s'est étalé sur deux lignes de cache.
    • Ce n'était pas une question de vitesse, c'était une question à propos d'un argument avec un enquêteur. Et la possibilité de faire un test pourrait s'avérer l'interviewer "droit" - pour des raisons qui n'ont rien à voir avec son argument, mais sont de la pure coïncidence. Qui vous mettrait dans une situation embarrassante si vous avez essayé de prouver qu'il avait tort.
    • Je vois votre point de maintenant. Oui, cela pourrait faire une différence.
    • Tous les arguments logiques à part, le cas de coïncidence, qui vous parlez serait intéressant de regarder. Mais encore aveuglément croire un tel cas existe n'est pas seulement naïf, mais stupide. Tant que vous n'avez pas expliquer le quoi, le comment ou le pourquoi de ce qui allait se passer cette réponse est inutile.
    • n'était pas une question de vitesse" - je ne discuterai pas les gens qui emploient des malhonnêtes procédés rhétoriques.
    • Télécharger Agner Brouillard est une excellente optimisation de manuel de agner.org/optimize . Une optimisation de la technique est l'alignement de boucles dans les lignes de cache à réduire le nombre d'instructions extrait. Obtenez un vieux PowerPC manuel. Le processeur G4 a une branche de cache cible en tenant les deux instructions de mots à la direction de la destination, et la vitesse d'exécution est optimale si une boucle se composait du 64 bits dans la CTB, plus 128 bits à partir de la prochaine ligne de cache. Est-ce suffisant des éléments de preuve?
    • Et puis il y a le processeur 68020, qui a en fait réussi à exécuter le même de la boucle de différents nombres de cycles, selon opaques de l'état interne du processeur. Et je veux dire la même boucle, pas une copie de la boucle avec les mêmes instructions. En général, le nombre de cycles par itération pourrait changer, de retour après une interruption matérielle.
    • Vous êtes juste spéculer que le cache de l'optimisation serait de le faire fonctionner différemment. Il affecte tous les deux, quelle est donc la différence dans les performances. Pour le deuxième exemple, êtes-vous sérieusement de me dire la gestion des interruptions aurait une incidence sur les performances et la cause de la différence. Je n'achètent pas votre lunatique sens de la comparaison. Ne soyons pas de débat entre les accepté de façons de faire une comparaison et de vos moyens.
    • Je suis sérieux vous dire. Peut-être que je devrais vous dire que j'ai optimisé le code à la fin des années 70. Et l'optimisation du code sur le 68020 à la fin des années 80. Et mesuré. Sur les machines où les interruptions peut être éteint. Et trouvé des boucles que deux et parfois trois itération fois avec des interruptions éteint, et la variable de temps avec des interruptions sous tension.
    • Pour la première partie de votre commentaire: Vous ne semblez pas être très bon lors de la lecture. J'ai dit que l'optimisation du cache de l'alignement peuvent améliorer la vitesse de code. La conséquence est que le code non optimisé aléatoire cache alignement peut fonctionner à des vitesses différentes en fonction aléatoire cache de l'alignement. Et qu'est ce que par exemple Intels propre "Intel ® 64 et IA-32 Optimisation des Architectures Manuel" vous indique.

    InformationsquelleAutor gnasher729
  18. 2

    Ils sont tous les deux égaux - même.

    Selon les spécifications de tout ce qui n'est pas 0 est considérée comme vraie, de sorte que même sans aucune optimisation, et un bon compilateur ne génère aucun code
    pour tout(1) ou de tout(2). Le compilateur génère une simple case pour != 0.

    • car ils ont tous deux prendre 1 cycle du processeur.
    • Le compilateur constante plis, donc il n'est même pas évalué au moment de l'exécution.
    InformationsquelleAutor Nikolay Ivanchev
  19. 2

    À en juger par la quantité de temps et d'effort gens qui ont passé des tests, ce qui prouve, et de répondre à cette question simple que je dirais que les deux se sont faites très lent par poser la question.

    Et ainsi de passer encore plus de temps sur elle ...

    ", tandis que (2)" est ridicule, car,

    "while (1)", et "while (true)" sont historiquement utilisé pour faire une boucle infinie qui s'attend à "casser" d'être appelé à un certain stade, à l'intérieur de la boucle basée sur une condition qui va certainement se produire.

    Le "1" est simplement là pour toujours avoir la valeur true et donc, de dire que "tout (2)" est à peu près aussi idiot que de dire "while (1 + 1 == 2)", ce qui permettra également d'évaluer la valeur true.

    Et si vous voulez être complètement stupide suffit d'utiliser: -

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

    Id aiment à penser que votre codeur fait une faute de frappe qui n'a pas d'effet sur le fonctionnement du code, mais si il l'a volontairement utilisé le "2", juste pour être bizarre, puis le sac avant qu'il mette bizarre sh!t au moyen de votre code, ce qui rend difficile à lire et à travailler avec.

    • La restauration vous faites revient modifier par un très haut-représentant de l'utilisateur. Ces gens savent généralement les politiques de très bien, et ils sont là pour leur enseigner à vous. Je trouve la dernière ligne de vous post en ajoutant rien d'utile pour votre post. Même si j'ai eu la blague, je suis évidemment manquant, je pense qu'il serait trop bavard, pas la peine de le de paragraphe supplémentaire.
    • Merci pour le commentaire. J'ai trouvé que le même gars édité beaucoup de mes posts, surtout que pour l'élimination de la signer. J'ai donc pensé qu'il était juste une réputation de troll, et donc sa réputation. A des forums en ligne appauvri la langue et de la commune de politesses - tant que nous ne signe plus de nos écrits? peut-être que je suis un peu vieille école, mais il semble juste impoli d'omettre bonjours et au revoir. Nous sommes en utilisant les applications, mais nous sommes encore des êtres humains.
    • Sur Stack Exchange, salutations, slogans, merci etc. ne sont pas les bienvenus. La même chose est mentionné dans centre d'aide, plus précisément dans comportement attendu. Aucune partie de Stack Exchange, pas même Stack Overflow, est un forum de discussion – ils sont Q&Un des sites. Edition est l'un des différences. Aussi les commentaires ne doivent servir qu'à fournir de la rétroaction sur le post, pas de discussion (Débordement de Pile de Chat). Et il y a beaucoup d'autres façons de Q&A est différent d'un forum. Plus que dans centre d'aide et sur Meta Stack Overflow.
    • Notez que lorsque vous avez plus de 2000 rep (modifier le privilège), vous gagnez de représentant pas plus de modifications. En cas de doute pourquoi et modifier vous êtes en désaccord avec a été appliqué à votre poste, ou vous voyez quelqu'un de mauvaise conduite, demandez sur Meta Stack Overflow. Si l'éditeur a fait quelque chose de mal, ils pourraient être averti par un mod (peut-être qu'ils ne réalisent pas) ou même puni d'une certaine manière (si le problème a été délibérément malveillants). Sinon vous avez des pointeurs à l'explication pourquoi modifier/comportement est correct. Inutile de restauration encombre révision de l'histoire et que vous pouvez obtenir dans la restauration de la guerre. Je ne restaurer que quand vraiment sûr de le modifier est incorrect.
    • Enfin, à propos de la signature, de voeux, ...: Il peut sembler impoli de ne pas inclure ces formalités, mais il augmente le rapport signal sur bruit et aucune information n'est perdue. Vous pouvez choisir n'importe quel surnom vous voulez, c'est votre signature. Dans la plupart des endroits que vous avez votre avatar, trop.
    • Mes modifications m'ont valu pas de rep; j'ai été tout simplement le nettoyage de vos messages. Je n'ai pas tout simplement supprimer ta signature, je fixe tout d'orthographe et de fautes de grammaire que j'ai remarqué. En cas de doute, vous devriez faire comme les autres. Voyez-vous une seule autre personne, n'importe où sur ce site, l'utilisation des signatures dans leurs postes? Ce n'est pas parce qu'ils sont grossiers, ils ont juste à comprendre la convention ici est de ne pas les utiliser, pas plus que vous pouvez vous attendre à voir les signatures et les salutations dans un article de Wikipédia. J'ai manipulé les restaurations; j'ai assez efficace lors de l'exécution d'un grand nombre de modifications à ce point.
    • Vous devez remplacer == par != dans votre état pour le rendre true
    • LOL je ne peux pas croire que vous m'avez fait une double vérification haha! Vous devriez regarder de nouveau, sa bonne. Le calcul de la gauche et sur la droite de chaque évaluer à 1.

    InformationsquelleAutor ekerner
  20. 1

    Qui dépend du compilateur.

    Si il permet d'optimiser le code, ou si on les évalue 1 et 2 de la vraie avec le même nombre d'instructions pour un particulier, l'instruction, la vitesse d'exécution sera le même.

    Dans des cas réels, il sera toujours aussi rapide, mais il serait possible d'imaginer un particulier compilateur et d'un système particulier, si cela peut être évaluée différemment.

    Je veux dire: ce n'est pas vraiment un langage (C) liés à la question.

    InformationsquelleAutor user143522
  21. 0

    Puisque les gens qui cherchent à répondre à cette question, veulent le plus rapide de la boucle, j'aurais répondu que les deux sont également de la compilation dans le même assembly code, comme indiqué dans les autres réponses. Néanmoins, vous pouvez suggérer à l'interviewer à l'aide de 'déroulement de la boucle'; un do {} while au lieu de la boucle while.

    Prudent: vous devez Vous assurer que la boucle serait au moins toujours exécuter une fois.

    La boucle doit avoir une condition d'arrêt à l'intérieur.

    Aussi pour ce genre de boucle, je serais personnellement préfèrent l'utilisation d'un do {} while(42) depuis tout entier, à l'exception de 0, pour faire le travail.

    • Pourquoi aurait-il suggérer un do{}while? While(1) (ou alors que(2)) fait la même chose.
    • faire tout en supprime un saut donc de meilleures performances. Bien sûr, dans le cas où vous savez que la boucle sera exécuté au moins une fois
    InformationsquelleAutor Antonin GAVREL
  22. 0

    La réponse est évidente: comme il est posté, les deux fragments irait tout aussi remplie de boucle infinie, ce qui rend le programme infiniment lent.

    Bien que la redéfinition de mots-clés de C en tant que macros serait techniquement avoir un comportement indéfini, c'est la seule façon que je peux penser à faire fragment de code rapide à tous: vous pouvez ajouter cette ligne au-dessus de la 2 fragments:

    #define while(x) sleep(x);

    il va en effet faire while(1) deux fois plus vite (ou de la moitié plus lent) que while(2).

    • en effet, la macro truc doit être encore plus tordu. Je pense que la nouvelle version devrait fonctionner, bien que n'étant pas garanti par la Norme.
    InformationsquelleAutor chqrlie
  23. -4

    La seule raison pour laquelle je peux penser à pourquoi la while(2) serait plus lente:

    1. Le code optimise la boucle de

      cmp eax, 2

    2. Lors de la soustraction se produit, vous êtes essentiellement en soustrayant

      un. 00000000 - 00000010 cmp eax, 2

      au lieu de

      b. 00000000 - 00000001 cmp eax, 1

    cmp définit uniquement des drapeaux et ne fixe pas de résultat. Donc, sur les bits de poids faible-nous savoir si nous avons besoin de l'emprunter ou pas avec b. Alors qu'avec un vous devez effectuer deux soustractions avant d'obtenir un emprunt.

    • cmp va prendre 1 cycle du processeur indépendamment dans les deux cas.
    • Ce code serait incorrect. Bon code serait de charger 2 ou à 1 dans le registre eax, puis de comparer eax à 0.
    InformationsquelleAutor hdost