Discussion :

[dafpp]

Bonsoir, toute simple question, si je fais ça :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
int a,b,c,d =0;
...
a = b = c = d = 0;

Dans quel ordre se passe l'opération? Forcement :
d=0c=db=ca=bDonc en soit c'est pas plus rapide que:

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
int  a, b, c, d = 0;
...
a = 0;
b = 0;
c = 0;
d = 0;

?

C'est même plus lent, car il n'y a pas d'histoire de récupérer la valeur pour l'affecter. Pour le dernier, zéro est gardé, donc la valeur est déjà en mémoire et ainsi de suite.

J'y pensais aussi, est-ce que ça équivaut à :
a & b & c & d & 0?
Et normalement a & 0 est plus rapide que a = 0? Et a ^ a ou a % a?

[Obsidian]

Bonsoir,

Ce sera strictement équivalent. D'abord parce que les compilateurs d'aujourd'hui sont suffisamment intelligents pour trouver d'eux-mêmes la meilleure voie pour parvenir à un résultat, et qu'ils ont une certaine latitude pour agir entre deux points de séquence.

Vis-à-vis de l'affectation en cascade, les micro-processeurs et d'une manière générale les machines à registres font un usage poussé des accumulateurs, avec lesquels le résultat forme automatiquement la première opérande de l'opération suivante (un peu comme l'écran d'une calculatrice).

Enfin, avec 0 en particulier, les micro-processeurs disposent généralement d'une instruction CLR (« Clear ») ou assimilée pour le faire de manière implicite sans avoir besoin de faire un accès bus. Sur x86, on obtient cela avec « XOR registre,registre », puisque le résultat d'un OU exclusif d'une valeur sur elle-même donne toujours zéro.

J'y pensais aussi, est-ce que ça équivaut à :
a & b & c & d & 0?

Non, ça n'a rien à voir. Le « & » seul correspond au ET logique bit à bit. Il n'y a aucune affectation. Tes variables resteront inchangées. Par contre, l'expression elle-même est légale et peut être évaluée. Mais comme son résultat est perdu à la fin (puisque tu ne l'affectes à aucune variable ni ne la retourne à une autre fonction) et que de toutes façons, tu la termines par « & 0 » dont le résultat sera toujours nul, il est probable que ton compilo ne se donne même pas la peine de la calculer. Si tu passes des options d'optimisations explicites (par exemple « -O3 » à GCC), l'expression entière passera à la trappe comme si tu l'avais mise en commentaire.

Et normalement a & 0 est plus rapide que a = 0? Et a ^ a ou a % a?

« & », « ^ » et « = » seront aussi rapides les uns que les autres car il s'agit d'opérations logiques fondamentales : elles sont directement câblées, électroniquement, au sein du micro-processeur et le résultat apparaît immédiatement sans qu'il ait besoin de poser le calcul. À dire vrai, c'est avec des portes logique ET, OU, NON-ET, etc. que les circuits numériques en tous genres implémentent les additions et les soustractions en binaire naturel.

Pour « % », ce sera un poil plus lent car il faut effectuer une division pour obtenir le modulo. Et la division est une opération relativement difficile, d'autant plus qu'à la différence des trois autres opérations fondamentales, elle peut déclencher une exception (le cas de la division par zéro). Les x86 et autres micro-processeurs puissants la proposent directement mais elle reste plus longue à exécuter que les autres. Les micro-processeurs plus modestes auront besoin de la résoudre logiciellement (en appelant une routine écrite pour).

Cela dit, il n'y a rien qui soit ici réellement palpable sur une machine moderne (comprendre par là : âgée de moins de 20 ans tout de même !) ni qui justifie une optimisation à la main directement dans le code source.

[dafpp]

Tout compris. Très bien merci.

[Médinoc]

a ^= a sera probablement plus lent que a = 0 si a est stocké en RAM plutôt qu'un registre, vu que ça impose une lecture de la mémoire en plus de l'écriture.

[bpy1401]

Bonjour à tous.

Pour faire une réponse globale, moi je ne fais jamais confiance au compilateur (c'est du à mon expérience de programmation embarquée ou les compilo n'étaient pas forcement très fiables). Du coup je n'écrit jamais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int  a, b, c, d = 0;

mais plutot

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int a;
int b;
int c;
int d;
 
void init(void) {
  a = 0;
  b = 0;
  c = 0;
  d = 0; 
}

la fonction d'initialisation (toujours en embarqué permet d’éviter des problèmes de RESET à chaud).

Du coup, même lorsque je fait un programme sur PC , je garde les mêmes règles. Pour moi, l'initialisation n'est pas forcement l'endroit ou j’optimise en vitesse. On ne le fait qu'une fois.

Pour fnir, si tu utilise des outils qui test la qualité de ton code, ta solution risque de lever des warning.

[Obsidian]

Du coup je n'écrit jamais
[…]
mais plutot
[…]
Du coup, même lorsque je fait un programme sur PC , je garde les mêmes règles. Pour moi, l'initialisation n'est pas forcement l'endroit ou j’optimise en vitesse. On ne le fait qu'une fois.

Les globales, c'est mal.

[dafpp]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int  a, b, c, d = 0;

Mais ça ce n'est pas la même chose que a=b=c=d=0; ou même

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=0;
b=0;
c=0;
d=0;

[souviron34]

Les globales, c'est mal.

Surtout que c'est pas compliqué de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int a;
int b;
int c;
int d;
 
void init(int *a, int *b, int *c, int *d) {
  *a = 0;
  *b = 0;
  *c = 0;
  *d = 0; 
}