Discussion :

[Astraya]

Salut,

Tu n'as sans doute qu'une information manquante: comment savoir si un nombre est pair ou impair. Et, cela, c'est simple: tu regarde s'il est divisible par 2. Et comment tu peux le savoir grâce à ce que l'on appelle le modulo, qui calcule le reste de la division entre deux nombres. En C et en C++, modulo est représenté par le symbole %. si bien que si tu fais un test proche de if(nombre%2 == 0), tu sauras si ton nombre est pair ou impair

Le reste, c'est à toi de voir comment faire le calcul qui va bien

Ou if(nombre&1) si on chipote sur la performance

[ternel]

Non, ca, ce n'est pas une bonne optimisation, le compilateur est capable de la faire, et le code est moins lisible.

[Astraya]

Tu peux me sortir un benchmark? car pour le moment, dans tout les moteurs nécessitant des performances élever le modulo et la division sont a proscrire au maximum.
Comment es-tu sur à 100% de ce que le compilateur va faire? De la version de ton compilateur? De ton compilateur?

Le code est tout à fait lisible, où il faut revoir ces compétences sur le masquage.

CF : https://software.intel.com/en-us/for...r/topic/298589

Ce genre d'optimisation compte énormément lorsque tu travailles avec un système qui doit rouler rapidement ( Car utiliser par une équipe ) et en debug ( Pour dump les callstacks par exemple ). Je pense à une configuration release avec information de débogage tu as besoin de ce genre de chose.
Après si c,Est pour un logiciel lamba, ça ne fera rien gagné, mais pour la connaissance général il est toujours bon de ne pas oublier ceci.

J'admets une limitation : Le type de "number" doit est unsigned

[prgasp77]

Tu peux me sortir un benchmark?

Je vous retournerais la question : l'optimisation à priori étant la racine de tous les maux, j'attendais d'un bon développeur qu'il écrive if (valeur % 2 == 0) à moins que celui-ci puisse me prouver via profiling que :

1. cette instruction en particulier coîte du temps d'exécution
2. ET une autre forme soit plus efficace.

Mais vous laissant le bénéfice du doute, et en dépis du fait que je suis persuadé que n'importe quel compilateur décent génère le même assembleur dans les deux cas, j'ai fait le test. Surprise : https://godbolt.org/g/XJcyxw

Code :

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

1
2
3
bool f1(int value) { return value % 2 == 0; }
 
bool f2(int value) { return ! (value & 1); }

Code :

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

1
2
3
4
5
6
7
8
9
10
f1(int):
        mov     eax, edi
        not     eax
        and     eax, 1
        ret
f2(int):
        mov     eax, edi
        not     eax
        and     eax, 1
        ret

[Astraya]

Passe le sur MSVC 19 2017 RTW sans optimisation pour voir... On ne peut être sur de rien...
Bien sur le compilateur peut optimiser le modulo 2 et heureusement, mais une instruction div en plus est très couteux dans certains cas.

[prgasp77]

Passe le sur MSVC 19 2017 RTW sans optimisation pour voir... On ne peut être sur de rien...

J'ai dit un compilateur décent.

Bien sur le compilateur peut optimiser le modulo 2 et heureusement, mais une instruction div en plus est très couteux dans certains cas.

dans certains cas.

Je maintiens donc mes attentes : un bon développeur devrait écrire if (valeur % 2 == 0) à moins que celui-ci puisse prouver via profiling que :

1. cette instruction en particulier coîte du temps d'exécution
2. ET une autre forme soit plus efficace.

[Kannagi]

Non, ca, ce n'est pas une bonne optimisation, le compilateur est capable de la faire, et le code est moins lisible.
[...]
Bref, dans le cadre du sous-forum "Débuter en C++" de notre communauté, enseigner la lisibilité est plus important.

Pour l'optimisation sûrement , mais lisibilité je pense que c'est relatif je trouve les 2 lisibles et compréhensibles.
Le ET est peut être moins 'connu' mais il est facilement compréhensible (preuve en l'apprend dans des bac pro ou STI donc loin d’être des bruts en math ! ).

car pour le moment, dans tout les moteurs nécessitant des performances élever le modulo et la division sont a proscrire au maximum.

Cela était vrai a une époque ( les divisions/multiplications n'existait pas sur les processeurs ou qu'il prenait trop de cycle ).
Pour les divisions (et je dirait les multiplications aussi) entier ou float , ce n'est plus trop vrai tu peux avoir des divisions/multiplications qui ne te coûte qu'un cycle
Encore plus incroyable , certain processeur permettent de faire des calcul vectoriel/matriciel sur un cycle !

Heu, depuis quand la taille de l'assembleur généré est un indicateur fiable des performances d'un code ???

C'est important de le dire , je rajouterait que sans avoir la pipeline en tête d'un processeur donné il est très compliqué de connaître son optimisation réel ! (mais je peux en tout cas dire que le faire manuellement c'est très pénible).

Après il est vrai que le compilateur réfléchira en tout cas moins pour l'instruction ET (tout les processeurs possède l'instruction AND a ma connaissance) pour l'optimisation le compilateur saura choisir.

Je trouve beaucoup de débat pour un truc qui n'en vaut pas la peine , l’optimisation il faut y réfléchir sur du code critique (un truc exécuter 10 000/ 100 000/ 1 000 000 par seconde).
Si pour l'initialisation tu fait du code un peu lent et que tu perd 1 voir 2 cycle bon c'est vraiment s'énerver contre du vent

NT: Alors je me suis renseigné sur le x86 , l'instruction DIV permet de récupérer le modulo et comme de nos jours grâce a la pipeline cette instruction peut être l'équivalent d'un cycle , je crois que vous avez votre réponse