Question de performance

Bonjour à toutes et à tous.

Je me pose une petite question. En partant du principe que les données sont des entiers vaut-il mieux écrire

Code:

---

result = data / 2;

---

ou

Code:

---

result = data >> 1;

---

À la compilation, y-a-t-il une différence de code binaire ?

En vous remerciant par avance.

Toi seul peut répondre à cette question en consultant le code assembleur généré pour ton système (option -S pour GCC). Mais le fait est qu'il ne doit y avoir aucune différence entre les deux expressions (avec les optimisations activées en tout cas) ou ton compilateur a de sérieux défauts.

Écris le code qui te paraît le plus clair dans le contexte considéré, premature optimization is the root of all evil.

Bonjour,

aucune différence. On le constate en regardant le code généré.

Merci à vous deux pour vos réponses claires et rapides.

Effectivement je pense qu'une "trop" forte optimisation dans l'écriture peut être préjudiciable à sa lecture, voir même à son fonctionnement.

Je vais donc garder une écriture lisible ;).

Bonjour,

Si le data est signé, je suis étonné que le code soit identique car le résultat ne l'est pas
-1 / 2 ====> 0
-1 >> 1 ===> -1

Citation:

---

Envoyé par dalfab

Bonjour,

Si le data est signé, je suis étonné que le code soit identique car le résultat ne l'est pas
-1 / 2 ====> 0
-1 >> 1 ===> -1

---

remarque judicieuse et intéressante.
Il y a en effet une différence quand il s'agit de type signés. Le comportement des opérateurs de décalages lorsque la première opérande est de type signé est laissé à l'implémentation :
Norme C11 6.5.7 Bitwise shift operators section 5 :

Citation:

---

Envoyé par Norme C11

The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.

---

Par exemple GCC a choisi :

Citation:

---

Envoyé par GCC C implementation

The results of some bitwise operations on signed integers (C90 6.3, C99 and C11 6.5).
Bitwise operators act on the representation of the value including both the sign and value bits, where the sign bit is considered immediately above the highest-value value bit. Signed ‘>>’ acts on negative numbers by sign extension.

As an extension to the C language, GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed ‘<<’ as undefined. However, -fsanitize=shift (and -fsanitize=undefined) will diagnose such cases. They are also diagnosed where constant expressions are required.

---

Dans les faits pour une architecture x86 le shift d'un entier signé est implémenté avec un sar (shift signé), la division avec un shr (shift non signé).

Citation:

---

Envoyé par picodev

Dans les faits pour une architecture x86 le shift d'un entier signé est implémenté avec un sar (shift signé), la division avec un shr (shift non signé).

---

Pas exact on dirait:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

int div(int a) { return a / 2; }   int shift(int a) { return a >> 1; }   int udiv(unsigned int a) { return a / 2; }   int ushift(unsigned int a) { return a >> 1; }

---

Avec gcc -O3 -S, on obtient:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

div: .LFB0: .cfi_startproc movl %edi, %eax shrl $31, %eax addl %edi, %eax sarl %eax ret .cfi_endproc .LFE0: .size div, .-div .p2align 4,,15 .globl shift .type shift, @function shift: .LFB1: .cfi_startproc movl %edi, %eax sarl %eax ret .cfi_endproc .LFE1: .size shift, .-shift .p2align 4,,15 .globl udiv .type udiv, @function udiv: .LFB2: .cfi_startproc movl %edi, %eax shrl %eax ret .cfi_endproc .LFE2: .size udiv, .-udiv .p2align 4,,15 .globl ushift .type ushift, @function ushift: .LFB3: .cfi_startproc movl %edi, %eax shrl %eax ret

---

Donc en mode non signé, le code généré avec mon compilateur et mon architecture est le même. En mode signé, en effet, le compilateur doit utiliser un peu plus de précautions pour la division. Ceci montre que lorsqu'on en est au point de vouloir optimiser un bout de code, il faut vraiment bien définir ce que l'on passe au compilateur :).

Ceci dit: garde toujours ton code lisible jusqu'au moment où tu prouves que, par rapport à l'exécution totale du programme, c'est important d'optimiser ce bout de code. Souvent, on passe beaucoup de temps à optimiser un algorithme avant d'arriver à vouloir changer une division pour un modulo.

Citation:

---

Envoyé par fearyourself

Pas exact on dirait:
[...]

Donc en mode non signé, le code généré avec mon compilateur et mon architecture est le même. En mode signé, en effet, le compilateur doit utiliser un peu plus de précautions pour la division.

---

Oui, je parlais bien d'entiers signés dans mon message.

Citation:

---

Envoyé par fearyourself

Souvent, on passe beaucoup de temps à optimiser un algorithme avant d'arriver à vouloir changer une division pour un modulo.

---

Je rajouterai que c'est surtout une chaose à ne pas faire, en fait. Le compilo est meilleur que la plupart des humains pour «optimiser» ce genre de chose : on ne devrait même pas s'en préoccuper.
Comme tu le dis la première chose à faire est en amont, choisir le bon algorithme, puis à l'implémentation les sdd adaptées, etc.
Si on veut continuer à optimiser, en aidant le compilo à le faire, il faut profiler.