Discussion :

[gerald3d]

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 :

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

result = data / 2;

ou

Code :

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

result = data >> 1;

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

En vous remerciant par avance.

[Matt_Houston]

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.

[picodev]

Bonjour,

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

[gerald3d]

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 .

[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

[picodev]

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 :

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 :

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é).

[fearyourself]

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 :

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

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 :

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

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.

[picodev]

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.

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.