Pourquoi n++ exécuter plus rapidement que n=n+1?

En langage C, Pourquoi ne n++ l'exécution est plus rapide que n=n+1?

(int n=...;  n++;)
(int n=...;  n=n+1;)

Notre instructeur posé cette question dans la séance d'aujourd'hui. (ce n'est pas de devoirs)

Ce qui est n? ___
Comment avez-vous trouvé ça? Sur le compilateur/OS/plate-forme/architecture?
Ce n'est pas, en général. Vous ne pouvez pas faire une déclaration significative que "a est plus rapide que b" (où a et b C sont des expressions). Il n'a de sens que de dire que "a est plus rapide que b sur le matériel c lorsqu'il est compilé avec la version d de compilateur e avec des options d'optimisation f" (et quelques autres exigences).
C'est clairement ce qui est demandé ici de l'exemple; tout simplement parce que la réponse semble évidente ne signifie pas que vous devriez la fermer. +1 pour les rouvrir.
Oui, je pense qu'il doit être rouvert..
Ce n'est pas une vraie question, car il se demande pourquoi un sens l'énoncé est vrai. Il pourrait aussi bien demander: "Pourquoi avez-green ideas sleep furiously?".
Canon: Au moins, il est vrai, parfois, dans le passé..
Donc l'interlocuteur devrait être corrigé dans la réponse. C'est toujours une bonne question, parce que quelqu'un d'autre peut venir à travers la même désinformation plus tard, et cette question sera d'aider à les trier
aussi, si vous vous sentez vraiment que la question ne devrait pas poser une fausse déclaration, n'hésitez pas à modifier pour qu'il "Est n++ plus vite que n = n + 1, et pourquoi?". C'est beaucoup plus constructif que de simplement fermer sans discussion 🙂
double possible de (C) Quelle est la différence entre ++i et i++
À moins que vous fournir un certain type de contexte, s'il vous plaît arrêter de rouler des modifications que le lien à des questions qui sont clairement liés à ce que vous demandez.
Et pour cette question, s'il vous plaît arrêter de revenir tente d'en faire une plus claire et pédagogique de la question; à moins d'y ajouter un commentaire si vous êtes en désaccord avec les modifications.
Je ne pense pas que cela devrait être dans le wiki de la communauté..
Trop tard. DONC convertit automatiquement une question à la Communauté Wiki si 5 personnes ou plus modifier une question.
Vote pour le rouvrir. Je ne vois pas comment ce n'est pas une vraie question. Tout simplement parce que l'OP a un mauvais enseignant, ne signifie pas que la question n'est pas légitime.
n++; et n=n+1; sera presque certainement compiler le même code machine sur n'importe quel compilateur moderne. Sur les premiers compilateurs C ce n'était pas le cas et que le compilateur serait seulement de réaliser qu'il pouvait utiliser le processeur cible de l'incrément de l'enseignement si vous lui avez dit n++. Sinon, il pourrait ne plus générale, à ajouter de l'instruction qui aurait été une plus grande instruction ou ont été deux instructions. Si votre instructeur vraiment vous a dit qu'il était plus rapide et n'était pas en parler en étant plus rapide pour vous de type "n++" que "n=n+1", puis il est mauvais. Essayez gcc -S prog.c;less prog.s
Il a été fermé, puis on les fixe dans une vraie question et rouvert, alors que l'OP est revenue et la question a été de nouveau fermé. Franchement, si l'OP va tirer ce genre de comportement, alors à mon humble avis il doit rester fermé.
Je crois que ce n'est pas une vraie question, car elle postule une fausse situation, et n'a pas de réponse. "Pourquoi les zèbres sont plus grandes que les éléphants?"
WTF pourquoi quelqu'un a mis une prime sur un wiki de la communauté avec l'accepté de répondre et de façon flagrante les prémisses fausses?!
La vraie question est: Pourquoi votre université permettre à un incompétent professeur pour enseigner?
Pour répondre à ma propre question: le fait d'avoir un bounty fait une question unclosable. Donc, apparemment, gcc mettre le bounty sur elle pour nous empêcher de le fermer.
Hey, je suis d'accord que ++n est plus optimisé que le n++. Mais n=n+1? LOL!
Soit vous vous moquez ou que vous avez raté que cette question est étiqueté C et pas du C++....
Je ne sais pas à propos de l'exécution, mais la compilation peut prendre en plaisantant petite quantité de moins de temps, puisque n=n+1; faudrait 2 octets de plus que n++; pour entrer dans la mémoire. Encore une fois cette hypothèse est peut-être vrai que pour certains pré-âge de pierre, ère, que nous avons maintenant de bloquer les lectures et les écritures et les choses...
Cette même question est sur la NASCAR blog "Mon frère de l'ami de l'oncle dit que sa voiture est plus rapide si c'est le numéro 01 de 10".
Wow je peux donner 5 +1? Vous avez failli m'a fait cracher mon café en riant.
double possible de quelle est la différence en termes d'efficacité de l'aide i++/++i/i+=1/i=i+1 si aucun optimisation du compilateur est utilisé

InformationsquelleAutor |

c micro-optimization optimization performance

102

Ce serait vrai si vous travaillez sur un "âge de pierre" compilateur...

En cas de "âge de pierre":

++n est plus rapide que n++ est plus rapide que n=n+1

Machine ont généralement increment x ainsi que add const to x
- En cas de n++, vous aurez 2 accès mémoire seulement (lire n, inc n, écrire n )
- En cas de n=n+1, vous avez 3 accès à la mémoire (lecture n, const lire, ajouter n et const, écrire n)
Mais aujourd'hui, le compilateur va automatiquement convertir n=n+1 à ++n, et cela ne sera plus que vous pouvez imaginer!!

Également aujourd'hui de processeurs -malgré le cas de "âge de pierre" compilateur d'exécution ne peuvent pas être affectées à tous les dans de nombreux cas!!

Liées
- Pourquoi serait-il essayer sur un "âge de pierre" du compilateur?
- Parce que c'est pas assez intelligent pour convertir automatiquement n=n+1 à n++; elle ferait de l'ensemble de la charge, d'exploiter, de stocker des affaires comme si 1 une valeur constante.
- Non, il n'est pas toujours instruction machine différence, mais c'est toujours l'accès à la mémoire un!
- Non, vous ne devriez PAS dire cela. Il faut vous dire, "Il devrait y avoir aucune différence entre les deux. L'optimisation des compilateurs ont géré ce genre de choses depuis des décennies, depuis au moins le Bonheur-11 compilateur décrit dans "la Conception d'un Compilateur Optimisant", par Wulf et al."
- Sur l'ordinateur je l'ai appris à, ++n et n++ était exactement à la même vitesse, il n'est pas à charge de l'incrément magasin, et la seule différence de vitesse que vous voyez dépend de la n a été stocké dans un registre ou mémoire (pas que n qui est arrivé à être dans un registre dès maintenant, mais si oui ou non ses de stockage alloué était dans un registre), par exemple move (n)+,r0 se déplace n pour inscrire zéro, l'incrémentation de n après le déménagement. (VAX-11 de l'assemblée)
- +1 pour le fait de répondre à la question de manière utile, plutôt que de simplement dire qu'ils sont les mêmes, ce qui est utile de savoir, mais de ne pas l'information que l'OP a probablement voulu.
- Dire au compilateur "convertir n=n+1 à ++n" est tout simplement fausse, ou même non-sens. C'est comme dire un traducteur "convertir it is à it's" lors de la traduction de l'anglais vers le français. La distinction entre les deux est un artefact de la langue source.
- J'ai été enseigné. ++n peut être plus rapide, mais n'est jamais plus lent que n++. Pour tout matériel.
- pourriez-vous préciser ce "++n peut être plus rapide que n++ car elle ne nécessite pas la précédente valeur de n doit être copiée, enregistrée au cours de l'incrément, et s'en retourna."?
- C'est un standard C++ de la classe mantra qui a été reporté à C et à devenir non-sens dans le processus. Notez qu'en C il n'y a pas de chose telle que l'application soit ++ opérateur "d'un grand et cher-pour-copie de type de données". Mais même si il n'y avait, pas de copie est en cause. L'incrémentation se passe en tout temps après l'opérateur de post-incrémentation, mais avant que la prochaine fois que la valeur est utilisée, longtemps après la valeur qui a été utilisée dans l'expression actuelle.
- veuillez noter que R, a déclaré dans C pas C++ parce que cette question est à propos de C pas C++. en C il n'y a pas une telle chose comme une surcharge. ++ pouvez seulement être appliquée aux types numériques en C donc il n'y a jamais besoin de copier quoi que ce soit.
- oups - vous avez raison - nonsense commentaires supprimés
- Si la constante est 0 au lieu de 1? si son n=n+0 au lieu de n=n+1?
- Un "âge de pierre' compilateur ne (lire n; const lire; écrire n), alors qu'un bon compilateur verrez immédiatement que c'est un no-op, et de ne pas ajouter quoi que ce soit à l'assemblée.
InformationsquelleAutor Betamoo

Sur GCC 4.4.3 pour les architectures x86, avec ou sans optimisations, ils compiler le même code assembleur, et ainsi prendre la même quantité de temps à s'exécuter. Comme vous pouvez le voir dans l'assemblée, GCC, convertir n++ en n=n+1, puis il optimise l'une instruction add (dans l'-O2).

Votre instructeur de la suggestion que n++ est plus rapide ne s'applique qu'à de très anciens, non-optimisation des compilateurs, qui n'ont pas été assez intelligent pour sélectionner la mise à jour des instructions pour n = n + 1. Ces compilateurs sont obsolètes dans le monde PC depuis des années, mais peut encore être trouvé pour bizarre propriétaire plateformes embarquées.

Code C:

int n;

void nplusplus() {
    n++;
}

void nplusone() {
    n = n + 1;
}

Assembly de sortie (pas d'optimisations):

    .file   "test.c"
    .comm   n,4,4
    .text
.globl nplusplus
    .type   nplusplus, @function
nplusplus:
    pushl   %ebp
    movl    %esp, %ebp
    movl    n, %eax
    addl    $1, %eax
    movl    %eax, n
    popl    %ebp
    ret
    .size   nplusplus, .-nplusplus
.globl nplusone
    .type   nplusone, @function
nplusone:
    pushl   %ebp
    movl    %esp, %ebp
    movl    n, %eax
    addl    $1, %eax
    movl    %eax, n
    popl    %ebp
    ret
    .size   nplusone, .-nplusone
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

Assembly de sortie (avec -O2 optimisations):

    .file   "test.c"
    .text
    .p2align 4,,15
.globl nplusplus
    .type   nplusplus, @function
nplusplus:
    pushl   %ebp
    movl    %esp, %ebp
    addl    $1, n
    popl    %ebp
    ret
    .size   nplusplus, .-nplusplus
    .p2align 4,,15
.globl nplusone
    .type   nplusone, @function
nplusone:
    pushl   %ebp
    movl    %esp, %ebp
    addl    $1, n
    popl    %ebp
    ret
    .size   nplusone, .-nplusone
    .comm   n,4,4
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

+1 pour le test, GCC est assez muet sur -O0 mais cela ne fonctionne toujours présent...

InformationsquelleAutor bdonlan

14

Le compilateur d'optimiser n + 1 dans le néant.

Voulez-vous dire n = n + 1?

Dans ce cas, de compiler à l'identique de l'assemblée. (En supposant que les optimisations sont et qu'ils sont des états, pas des expressions)

InformationsquelleAutor SLaks
5

Qui dit qu'il fait? Votre compilateur optimise tout de suite, vraiment, en faisant un point discutable.

InformationsquelleAutor Mahmoud Al-Qudsi
3

Les compilateurs modernes doivent être capables de reconnaître les deux formes équivalentes et de les convertir vers le format qui fonctionne le mieux sur votre plate-forme cible. Il existe une exception à cette règle: la variable d'accès qui ont des effets secondaires. Par exemple, si n est de la mémoire mappée matériel de registre, de lecture et d'écriture peuvent faire plus que simplement le transfert d'une valeur de données (lecture claire une interruption, par exemple). Vous devez utiliser la volatile mot-clé pour permettre au compilateur de savoir qu'il faut être prudent sur l'optimisation de l'accès à n, et dans ce cas, le compilateur peut générer du code à partir de n++ (opération d'incrémentation) et n = n + 1 (lire, ajouter, et les opérations de banque). Toutefois, pour les variables normales, le compilateur doit optimiser les deux formes de la même chose.
- Cette réponse est fausse. volatile n'entraîne pas de différence entre ++n et n=n+1. La fois le résultat en une seule lecture et une écriture unique, et ni est atomique. Si vous voulez atomicité, volatile ne peut pas les lui fournir; attendre _Atomic types de C1x.
- Je n'ai jamais prétendu que "volatile", à condition atomicité. Le reste de votre commentaire n'est pas vrai dans le cas général (enregistrer la dernière phrase); les détails de la façon dont un compilateur optimise le code est spécifique à l'implémentation. Ma réponse explique simplement comment utiliser 'volatile' peut affecter optimisation du compilateur en général.
InformationsquelleAutor bta
2

Il n'a pas vraiment. Le compilateur va apporter des modifications spécifiques à l'architecture cible. Micro-optimisations comme cela a souvent douteux avantages, mais, surtout, sont certainement pas la peine de le programmeur du temps.

InformationsquelleAutor Puppy
2

En fait, la raison est que l'opérateur est défini différemment pour le post-fix qu'il est pour le pré-fix. ++n incrémenter "n" et de renvoyer une référence à "n" alors que n++ incrémenter "n" retour d'un const copie de "n". Par conséquent, le membre de phrase n = n + 1 sera plus efficace. Mais je suis d'accord avec les affiches ci-dessus. Bon les compilateurs doivent optimiser loin d'un retour non utilisé objet.
- -1 pour le C++ réponse C question.
- Il a été initialement marqué C/C++.
- et plus au point en regardant l'histoire, il a été édité une étonnante 13 fois complète avec changement de titre, étiquette de changements, et à la question des changements. Pour me marquer vers le bas tout en ne prenant pas le contexte historique est assez pauvre. Normalement, je ne serait pas aussi arrogants mais est-ce à dire j'ai besoin d'aller à travers tous mes réponses pour vous assurer que la question n'a pas été modifié au point où je pourrais obtenir downvoted plusieurs mois plus tard?
- Désolé, je n'étais pas au courant. Je voudrais supprimer l'-1 si je le pouvais.
- Pourquoi ne peut-on pas supprimer le -1?
- Après il est là depuis un certain temps, vous ne pouvez changer votre vote si la réponse est édité.
InformationsquelleAutor wheaties
2

En langage C les effets secondaires de n++ expressions est par définition équivalent à l'effet secondaire de n = n + 1 expression. Depuis votre code s'appuie sur les effets secondaires, il est immédiatement évident que la réponse correcte est que cette expression n'ont toujours exactement les mêmes performances. (Peu importe les paramètres d'optimisation du compilateur, BTW, puisque la question n'a absolument rien à voir avec toutes les optimisations.)

Un écart de rendement de ces expressions n'est possible que si le compilateur est intentionnellement (et malicieusement!) essaie d'introduire de la divergence. Mais dans ce cas, il peut aller de toute façon, bien sûr, c'est à dire selon la manière dont le compilateur de l'auteur a voulu biaiser il.
- -1: le vieux compilateurs utilisés pour émettre des instructions différentes pour les différents énoncés, parce qu'ils n'étaient pas assez avancés à l'optimisation...
- Ce que vous dites est un non-sens absolu, basé sur un ridicule légende urbaine selon laquelle les compilateurs d'une certaine manière de traduire le code en C en code machine dans certains littérale de la mode. En réalité, si la définition de la sémantique des deux expressions est le même, le code sera le même. Il n'a absolument rien à voir avec l'optimisation. Si votre compilateur produit un code différent dans ce cas, cela signifie simplement que votre compilateur a été cassé, pas qu'il n'était pas "assez avancés d'optimisation".
- Non, beaucoup de simples compilateurs vraiment faire une traduction littérale, comme toujours à l'aide d'un complément d'instruction pour l'opérateur"+", même dans les cas où INC serait mieux. Par exemple, il a utilisé pour être commun à utiliser manuellement ">>" à la division par une puissance de deux, parce que le compilateur aurait recours à un très lent DIV instruction si vous avez utilisé l'opérateur"/".
- Newby: Que signifierait un naïf non-production de qualité compilateur. I. e. un compilateur écrit par des gens qui ne comprennent pas ce qu'ils faisaient. Les gens, qui ont mis en œuvre leurs propres idées fausses sur le langage C à la place de la spécification du langage C. Pourquoi quelqu'un utiliser un "compilateur" est au delà de moi. En réalité, il n'y a pas une telle chose comme "traduction littérale", dans C. Rien dans le langage de spécification implique que + devrait être mis en œuvre qu'à AJOUTER et que ++ devrait être mis en œuvre par INC.
- Non, cela signifie juste un simple compilateur, qui est encore commun pour les microcontrôleurs et excentrique systèmes. Il y a toute compilateur entreprises pour des niches de plates-formes qui ont le moins d'employés que le Visual C++ équipe d'optimisation, et leurs produits sont très utiles, bien que le code de l'ordinateur de l'efficacité laisse à désirer. De plus C a été conçu de sorte que les opérateurs de la carte directement à la commune des instructions machine, si simple traduction directe serait de produire un compilateur complet.
- Avoir moins d'employés n'est pas une excuse pour l'échec complet pour comprendre le langage C. Souhaitez-vous embaucher quelqu'un qui ne veut pas comprendre l'allemand pour traduire de l'allemand vers l'anglais? Alors, pourquoi voulez-vous embaucher quelqu'un qui ne comprend pas C pour écrire un compilateur C?
- Que quelque chose n'est pas mandaté par le standard ne veut pas dire qu'il n'est pas fait normalement et destinés à être fait de cette manière. Un signe de la destinée relativement simple traduction de la source à l'objet du code est la quantité de choses qui n'est pas défini par la norme, de sorte que vous pouvez simplement accepter ce que le matériel n'est naturellement dans cette cartographie simple. Par exemple, le signe du comportement de % n'est pas spécifiée, afin de savoir si votre matériel vous donne un unsigned modulo ou potentiellement signé reste comme une instruction machine, vous pouvez toujours la carte de l'opérateur assez simple instruction machine.
- Il n'y a rien de gauche "undefined" dans ce cas. En fait, la norme définit explicitement/implique l'équivalence entre ++ variante et + 1 variante, qui est l'ensemble de point. La raison pour laquelle la norme a tellement de trucs à gauche indéfini est de donner au compilateur de plus de liberté dans l'optimisation du code. Ironiquement, dans la plupart des cas (y compris celui-ci) c'est en fait l'opposé de la primitive approche de traduction lors de la C des opérations sont juste carrément mappé à l'exploitation des machines.
- l'équivalence fonctionnelle est obligatoire. Identiques de mise en œuvre (et de la performance) ne l'est pas. Une mise en œuvre différente ne signifie pas un résultat différent. Les compilateurs peuvent choisir de mettre en œuvre ++ différemment à +=1 et, en particulier, historiquement, ont souvent fait. Il y a une histoire que je me souviens vaguement (aucune garantie de précision) à propos de l'origine compilateur C y compris le préfixe et le suffixe variantes de l' ++ et -- les opérateurs spécifiquement pour exploiter spécialisé modes d'adressage pour les plateformes cibles code machine lorsqu'il est utilisé pour les pointeurs qui ont également été déréférencé, et les indices utilisés avec [].
- En fait, un compilateur peut mettre en œuvre x++; y++; de telle manière que l'on utilise INC, l'autre utilise ADD 1. L'enfer, il peut utiliser SUB -1 si il voulait vraiment. Le point est, même pour littéralement identiques code C, le code généré peut différer d'instance en instance. Seulement la sémantique de la matière en fin de compte. Je voudrais quelqu'un pour mettre en œuvre un -O-1 option de GCC un de ces jours deoptimize code 😀
InformationsquelleAutor AnT
1

Je pense que c'est plus une question de matériel plutôt que logiciel... Si je me souviens corectly, dans les Processeurs plus anciens n=n+1 nécessite deux emplacements de mémoire, où l' ++n est tout simplement un microcontrôleur commande... Mais je doute que cela s'applique pour les architectures modernes...

InformationsquelleAutor
0

Toutes ces choses dépend du compilateur/processeur/directives de compilation. Donc, faire toutes les hypothèses "ce qui est plus rapide en général" n'est pas une bonne idée.

InformationsquelleAutor

Vous devez vous connecter pour publier un commentaire.