Discussion :

[jennings]

Bonjour

Savez-vous quel est le plus rapide en éxécution ? La différence est-elle significative ou négligeable ?

Code :

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

1
2
3
4
5
6
 
if machin then
  if truc then
     ' traitement
  endif
endif

ou

Code :

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

1
2
3
4
 
if (machin and truc) then
  traitement
endif

Si la réponse dépend du langage alors j'irai poser cette question sur le forum DOTNET (je bosse en vb.net)


Merci

[Laurent Gomila]

C'est le genre de question qu'on ne devrait jamais avoir à se poser. Si c'est ce genre d'instruction qui ralentit les perfs de ton appli, c'est que le reste de ton programme doit être écrit en ASM ultra optimisé.

Je pense que la bonne réponse dans ce cas est la suivante : adopte la syntaxe qui soit la plus claire et la plus explicite pour les gens qui vont lire le code.

Pour tout de même répondre à ta question, il faudrait regarder le code généré par le compilo mais à mon avis c'est identique dans les deux cas.

[jennings]

Merci LOULOU

Ce n'est donc pas là que je pourrai gagner du temps d'éxécution.
C'était mon avis, mais je préférais avoir une confirmation


Merci

[chicorico]

Bonjour,

La réponse ne dépend pas du langage, puisqu'au final tout est compilté en Assembleur .

La deuxieme méthode est plus rapide, car elle necessite qu'un seul saut conditionel ('je' en assembleur).

La deuxieme méthode est plus lente. Cependant, il est possible que le compilateur optimise ce genre de code et le rende au final aussi rapide .

Voila ce que le Vb.NET génére comme code machine :

Méthode 1 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
        If (a) Then
00000025  test        esi,esi 
00000027  je          00000030 
            If (b) Then
00000029  test        ebx,ebx 
0000002b  je          0000002F 
                c = False
0000002d  xor         edi,edi 
            End If
0000002f  nop              
        End If

Méthode 2 :

Code :

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

1
2
3
4
5
6
7
8
 
        If (a And b) Then
00000025  mov         eax,esi 
00000027  and         eax,ebx 
00000029  je          0000002D 
            c = False
0000002b  xor         edi,edi 
        End If

Je sais qu'on est dans le forum algo et qu'il ne devriait pas avoir de code assembleur, mais il faut le considerer comme une simple illustration à ma réponse

Ce n'est donc pas là que je pourrai gagner du temps d'éxécution

Ca dépend, si ce code est contenu dans 3 ou 4 boucles imbriqué, ou si il est répeté des milliers de fois, ca peut jouer ...

Sinon , c'est négligable, d'ailleurs d'un point de vue algo et comprehension, si ton code se résume à ca (pas de else dans la deuxieme condition), il vaut mieux utiliser la deuxieme méthode

A+

[Mac LAK]

Savez-vous quel est le plus rapide en éxécution ? La différence est-elle significative ou négligeable ?

Ca dépend de beaucoup de choses... En fait, la question que tu te poses pourrait être reformulée ainsi : "Est-il rentable de ne pas faire d'évaluations booléennes complètes ?", et la réponse est en général "Oui".

Donc, cette forme est en moyenne et en général (j'insiste bien sur ces deux mots !!) plus efficace :

Code :

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

1
2
3
4
5
if machin then
  if truc then
     ' traitement
  endif
endif

En fait, j'utilise ce genre de choses lorsque je n'ai pas envie (ou que je ne me rappelles plus) l'ordre d'évaluation d'une condition, ou que je veux forcer une évaluation tronquable même dans les langages qui ne le supportent pas.

Cependant, si tu veux gagner du temps à ce niveau, plusieurs facteurs sont à prendre en compte :
- Les tests ne doivent pas, si possible, avoir de clauses "else" : ça complexifie l'arrangement manuel des expressions.
- Il faut connaître la probabilité "être faux" de chaque condition, et tester la plus fréquente en premier.
- Il faut connaître le temps de calcul, même approximatif, de chaque condition, et tester la plus lente en dernier.
- Il faut connaître l'interdépendance des conditions entre elles, et bien sûr ne pas tester une dépendance avant son prérequis.
- Il faut savoir combien de fois est exécuté le test général : si c'est une seule fois dans le programme, laisse le test tranquille. Si c'est 200 fois par milliseconde, ça devient rentable.

On peut pousser plus avant si tu en as besoin, mais je pense que tu t'es déjà rendu compte que ça demandait des calculs de probas, de vitesse d'exécution et de nombre d'exécutions... Bref, ça ne s'optimise pas "comme ça".
Pour la même raison, le gain est extrêmement variable... Ca peut être 0.3 ns de gain (ridicule), ou 200 ms (rentable), tout dépend de tes conditions, de leur temps de calcul et de leur probabilité d'être évaluées "fausses".

Mais surtout, comprends bien que c'est un gain moyen : sur certains tests (les plus nombreux si tu l'as bien fait), ce sera un gain, mais ce sera toujours une perte lorsque toutes les conditions seront vraies !! Tu comprends donc bien l'intérêt des probabilités !

chicorico Un saut conditionnel non-exécuté ne coûte que très très peu de cycles CPU, car on ne vide pas le pipeline d'exécution. Ton exemple n'est valide que parceque ce sont deux variables, avec un seul test "simple". Essaie avec "a And (Not(b))", ou transforme "b" en appel de fonction et ce sera la première méthode la plus rapide.
Entre parenthèses, pour l'instruction de saut, on écrit plutôt "jz" (Jump if Zero) plutôt que "je" (Jump if Equal), c'est plus mnémotechnique, même si l'opcode généré est le même.

[PRomu@ld]

Pour completer un peu Mac LAK, il faut que tu sache si ton langage supporte l'évaluation paresseuse.

En effet, si tu as :

Code :

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

1
2
3
if (a and b and c and d and ... and z ) then
 fct
end if

dans ce cas, dans un langage qui ne supporte pas l'evaluation paresseuse va effectuer tous les test et même si a est faux alors il va tester les autres même si on sait que celà ne sert à rien, donc dans ce cas, il y a bien gain d temps à imbriquer les if (mais à un temps de codage plus long).

En revanche, si ton programme effectue l'évaluation paresseuse, il va effectuer le test sur chacune des variables et si l'une d'entre elle est fausse il arrête les tests. Donc en gros (je ne suis pas spécialiste dans les langages), lors de la compilation les structures :

Code :

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

1
2
3
4
 
if (a and b) then
 fct;
end if;

doit surement être transformé en

Code :

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

1
2
3
4
5
if (a) then
 if(b) then
  fct
 end if;
end if;

Donc en gros dans de tels langages que tu écrives dans un sens ou dans l'autre, il n'y a aucune différence (c'est ce que je pense, il faudrait que quelqu'un confirme).

Ta réponse dépendra donc à la fois de la probabilités de chacune des variables à être vraie ou fausse (suivant tes tests) mais aussi du langage utilisé.

PS : si ce genre de tests ne se produisent que très rarement dans ton code : ne te soucis pas de telles questions, réfléchis plus sur les algorithmes utilisés que sur la syntaxe des structures de contrôle utilisées (bien que ce soit interressant)

[jennings]

Merci à tous pour vos remarques intéressantes et très circonstanciées.

[duchere]

Bon, vous allez peut-être trouver ça bête, mais je voulais juste dire que je trouvais ce sujet intéressant à lire.

Jean.

[j.p.mignot]

en fait si on execute if ( A X B ) X etant un opérateur logique, avec delphi on peut avoir les 2 situations suivantes suvant l'insersion de {$b+} ou {$b-}

En mode {$B+}, le compilateur génère un code évaluant entièrement les expressions booléennes. Tous les opérandes des expressions booléennes contenant des opérateurs and et or sont alors évalués, même si le résultat de l'expression totale est déjà connu.
En mode {$B-}, le compilateur génère un code d'évaluation "court-circuit" des expressions booléennes. Cela signifie que l'évaluation s'arrête à partir du moment où le résultat de l'expression devient évident dans l'ordre d'évaluation de gauche à droite.

en general $b- conduit à une execution + rapide si on met en 1er la booléenne qui a le + de chance de définir de façon univoque le résultat. MAIS, si A et /ou B ne sont pas des booléennes. mais le résultat de fonction retournant une booléenne, on peut court-circuiter l'execution de routines et aller à de sérieux ennuis. D'un autre côté si l'execution de B est assujetti à un retour True de A passer $b- à $b+ conduit à des erreurs.
ici tout est question d'analyse de la situation en cours.

on note que $b peut être changé au long du source code suivant les necessites du moment.

[mat.M]

Comme le démontre Chicorico ( qui pourtant se contredit dans ses propos ) la 2ième solution semble + rapide car il n'ya qu'une seule instruction logique ( and )
Il faut voir qu'un 2ième if peut entrainer un saut en mémoire ce que montre le code ASM de Chicorico
Et les sauts en mémoires avec je , jg (i386) et compagnie ça peut ralentir les performances

[camboui]

En marge des perfs, il est parfois critique de savoir comment est évaluée une expression booléenne. Voici un exemple C/C++:

Code :

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

1
2
3
4
if (ptr && ptr->value==0)
{
...
}

De nombreux programmeurs usent et abusent de ce genre d'écriture (dont moi ). En C/C++, l'expression est évaluée de gauche à droite et s'arrête dès que la condition n'est plus vérifiée. Je n'ai pas le souvenir qu'il existe de directives de compil pour changer cela, et heureusement, sans quoi pas mal de code ne serait pas portable.
Je me souviens de l'époque du TurboPascal, où, en effet une directive permettait de choisir la manière d'évaluer les expressions booléennes.
Et j'ai enragé le jour où j'ai commencé à faire du vb car là, les expressions sont évaluées en entier

[gangsoleil]

En C/C++, l'expression est évaluée de gauche à droite et s'arrête dès que la condition n'est plus vérifiée.

Cela vient du fait que dans les langages que tu cites, l'exécution est dite "paresseuse". ce n'est pas le cas dans d'autres langages, tout simplement.
A priori, c'est configurable à la compilation dans pas mal de compilateurs.

[neguib]

jennings comme tu code VB tu peux utiliser l'operateur logique AndAlso
c'est l'équivalent de If suivi d'un autre If