Discussion :

[Jimalexp]

Bonsoir,

J'aimerais savoir s'il y a une différence concrète au niveau du code compilé si l'on utilisé des if testant une seule condition ou si test plusieurs conditions d'affilé.

Par exemple on souhaite contrôler les paramètres en entrée d'une fonction :

Code :

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

1
2
3
4
5
6
7
8
if( a < 0 )
 return;

if( b > 0 )
 return;

if( texte != "blah")
 return;

Les mêmes conditions réunies dans un seul if :

Code :

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

1
2
if( a < 0 || b > 0 || texte != "blah" )
 return;

La dernière écriture est plus concise mais, concrétement, est-ce qu'il y a une différence entre ces deux codes après compilation ? Si oui, quel est le code le plus performant ? Quels autres différences pourrais t-il y avoir au niveau assembleur/bytecode/code machine ou durant l'exécution ?

[Garulfo]

Bonsoir,
[...]
La dernière écriture est plus concise mais, concrétement, est-ce qu'il y a une différence entre ces deux codes après compilation ? Si oui, quel est le code le plus performant ? Quels autres différences pourrais t-il y avoir au niveau assembleur/bytecode/code machine ou durant l'exécution ?

Tu parles de quel langage, de quel compilateur, de quelle version de ce dernier et de quelle plateforme ? Parce que cela dépend.

Quant à la performance, même si la dernière version n'est pas optimisée par le compilateur, la différence est tellement négligeable que s'en est ridicule.

[Jimalexp]

Hmm, disons pour le C et puis ensuite pour la Java (assembleur versus bytecode) ?

D'après ta réponse, il y aurais bien une différence, aussi négligeable soit t-elle. C'est ce que je voulais savoir en fait. Si ca n'aurais pas de valeur pratique, je considère que ca m'aide à mieux comprendre l'outil.

Disons que de manière intuitive, je sais que l'un est plus éfficace que l'autre mais je ne serais expliquer pourquoi. La question pourrais aussi s'appliquer aux if...else if.

[HerQuLe]

Code :

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

1
2
if( a < 0 || b > 0 || texte != "blah" )
 return;

Mieux vaut utiliser cette maniere je pense


Car si a < 0, les autres tests ne sont pas effectués et tu gagnes du temps


Pareil avec des &, si tu tombes sur un false des le début t'arretes sans tester le reste

[Garulfo]

Mieux vaut utiliser cette maniere je pense
Car si a < 0, les autres tests ne sont pas effectués et tu gagnes du temps

Dans son premier exemple non plus.

A priori, traduit bêtement, le deuxième pourrait être moins bon. Mais il peut être optimisé sous la forme du premier par exemple par un compilateur qui ferait la job. Sauf qu'encore une fois, c'est tellement négligeable que je me demande le réel intérêt de se poser la question.

Les problèmes de performances naissent avant tout d'une mauvaise conception et non d'optimisation locale de morceau de code.

[HerQuLe]

Dans son premier exemple non plus.

A priori, traduit bêtement, le deuxième pourrait être moins bon. Mais il peut être optimisé sous la forme du premier par exemple par un compilateur qui ferait la job. Sauf qu'encore une fois, c'est tellement négligeable que je me demande le réel intérêt de se poser la question.

Les problèmes de performances naissent avant tout d'une mauvaise conception et non d'optimisation locale de morceau de code.

Et pourquoi dans le 2eme exemple si a=-1 et b=1 on ne pourrait pas rentrer dans le 2nd if? Je comprends pas trop la...



Et puis la suite je suis pas non plus trop d'accord, bien sur si tu testes a > 0 c'est pas tres interessant c'est sur, mais des que t'as des tests un peu lourd ca peut quand meme etre interessant d'éviter de faire les tests inutiles non?

Bien sur la conception c'est important mais ca dépend aussi des applications, si tu fais des gros calculs ca peut quand meme etre interessant d'optimiser localement du code avec utilisation d'opérateurs sur les bits par exemple non?

[Jimalexp]

Sans certitudes, je pense qu'un if à conditions multiples est retranscrit sous une forme plus simple en bytecode/assembleur de sorte que cela ressemble à des if portant sur des conditions simples (peut être combiné avec des Jumps). C'est que laisse entendre Garulfo. Il faudrais voir comment certains compilateurs traduisent ce genre de code.

Sinon, à vrai dire, ce qui m'embête ce n'est pas tellement la performance que l'allure que prends une structure lorsqu'on teste plusieurs conditions de cette manière.

Voici un exemple à rallonge inspiré d'un petit mod que je suis en train de réaliser en unrealscript (il s'agit à la fois de contrôler les paramètres en entrée et des conditions extérieures) :

Code :

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

1
2
if( InstigatedBy == none || Victim == none || Victim == InstigatedBy || ( !InstigatedBy.Weapon.IsA('SniperRifle') && !InstigatedBy.Weapon.IsA('ShockRifle') && !InstigatedBy.Weapon.IsA('minigun') && !InstigatedBy.Weapon.IsA('enforcer') ) || !InstigatedBy.IsA('PlayerPawn') || Victim == lastVictim[ playerID ] || lastVictim[ playerID ] == none )
 return;

Evidemment, je n'ai pas restranscrit les choses ainsi. Dans ce cas, j'estime que ce n'est déjà pas intéressant au niveau lisibilité donc ma préférence penche déjà vers une forme plutôt que l'autre.

Bien sur la conception c'est important mais ca dépend aussi des applications, si tu fais des gros calculs ca peut quand meme etre interessant d'optimiser localement du code avec utilisation d'opérateurs sur les bits par exemple non?

Dans le cas du langage ci-dessus, tout est exécuté dans une virtual machine (unreal engine). La performance a tout de même son importance et certains pronent de quasi tout laisser en public, d'accéder directement aux attributs de classe sans passer par des méthodes intermédiaires et découragent l'utilisation de structures abstraction (genre LinkedList).

Personellement, je n'ai pas vraiment rencontré de problèmes en utilisant une approche plus puriste de l'objet mais peut être que tout cela prends son importance lorsqu'on interviens directement dans la mécanique du jeu ou qu'on souhaite intervenir dans un lapse de temps assez court.

En fait, il semblerais que le contexte (gestion, informatique industrielle ou autre) impose toute une série de conventions en matière de pratiques.

[Garulfo]

Et pourquoi dans le 2eme exemple si a=-1 et b=1 on ne pourrait pas rentrer dans le 2nd if? Je comprends pas trop la...

Je suppose que tu veux dire le 1er exemple ?
C'est parce qu'il y a un return.
Il n'y a donc pas d'autres tests.

Et puis la suite je suis pas non plus trop d'accord, bien sur si tu testes a > 0 c'est pas tres interessant c'est sur, mais des que t'as des tests un peu lourd ca peut quand meme etre interessant d'éviter de faire les tests inutiles non?

Bien sur la conception c'est important mais ca dépend aussi des applications, si tu fais des gros calculs ca peut quand meme etre interessant d'optimiser localement du code avec utilisation d'opérateurs sur les bits par exemple non?

En règle générale, non. Les problèmes de performances ne naissent quasiment jamais de ce genre de petit détail. Tu auras un problème quand tu seras en temps quadratique alors que tu peux être en linéaire. Mais ceci n'est pas une question d'optimisation de code, mais c'est une question architecturale. Il peut y avoir des exceptions. Mais elles sont extrêmement rare. Même dans les logiciels de calculs intensifs, les problèmes de performances sont en général dû à d'autre facteur que du tweaking de code. Te rends tu compte combien dans ce cas c'est minuscule comme gain? Alors qu'utiliser un algorithme quadratique là où il existe un n log n, ça ruine ton application possiblement. Comme choisir un protocole trop lourd qui surcharge ton serveur ou tout autre chose du genre.

Alors oui, si on prend l'absolu il faut aussi savoir ça. Mais si tu veux investir dans du temps bien placé, révises tes cours d'algorithmie et d'architecture. Ça sera bien plus rentable.

[HerQuLe]

Je suppose que tu veux dire le 1er exemple ?
C'est parce qu'il y a un return.
Il n'y a donc pas d'autres tests.

avais pas fais attention xD



Je suis d'accord avec toi sur la 2eme partie, seulement si on part du principe que l'algo et l'archi sont bons, on peut quand meme gagner pas mal de temps sur de l'optimisation locale de code non?

Bien sur si t'as pas choisi l'algorithme le moins couteux sur du gros volume ça peut être catastrophique.


Je veux juste dire que si faire quelques optimisations peuvent te faire gagner 20% de temps, que ca te prend 1 jour pour les faire et que ton programme tourne sur 5j, bin au final a chaque fois que tu le lances tu gagnes quand meme 1j, bien sur c'est sans doute très négligeable par rapport aux possibles milliers de jours que tu gagnes en passant d'un mauvais algo a un bon, mais bon au final c'est quand même pas rien.


Ca doit quand meme pas etre pour rien que ces opérateurs sur les bits ont été inventés, j'avais testé en cours et faire des décalages (<<) pouvaient faire gagner pas mal de temps dans certains cas. Et ca doit pas non plus etre pour rien que certaines personnes integrent des bouts d'assembleur dans leurs programmes non?

[Garulfo]

[...]
Je suis d'accord avec toi sur la 2eme partie, seulement si on part du principe que l'algo et l'archi sont bons, on peut quand meme gagner pas mal de temps sur de l'optimisation locale de code non? [...]
Je veux juste dire que si faire quelques optimisations peuvent te faire gagner 20% de temps, [...]

Gagner beaucoup ? non. Gagner un peu ? oui. Mais c'est rare que ça soit vraiment rentable. Je ne dis pas que c'est complètement à exclure, mais qu'en général tu n'y gagnera que peu ou rien. De plus en plus, il faut faire confiance aux compilateurs et ne pas micro-optimisés. Car c'est ainsi qu'on a tendance à faire entrer des erreurs de code.

C'est à mon avis utopique de croire que des petits optimisations font gagner 20% du temps machine. Encore une fois, tu as plus de risque d'introduire des erreurs ou de contrevenir à ta conception en faisant ça que de réellement gagner quelquechose.

[...]
Ca doit quand meme pas etre pour rien que ces opérateurs sur les bits ont été inventés, j'avais testé en cours et faire des décalages (<<) pouvaient faire gagner pas mal de temps dans certains cas. Et ca doit pas non plus etre pour rien que certaines personnes integrent des bouts d'assembleur dans leurs programmes non?

Rien à voir. Les opérateurs sur les bits existaient dès le début des premiers langages puisqu'on était toujours près de la machine. Et au final on intègre tous des bouts d'assembleurs

Encore une fois, c'est vrai que dans l'absolu c'est bien. Mais si tu dois choisir où investir ton temps, l'algorithmie et les méthodes de conceptions/vérification/validation sont bien plus rentables pour chercher des optimisations.

[alex_pi]

Voici un exemple à rallonge inspiré d'un petit mod que je suis en train de réaliser en unrealscript (il s'agit à la fois de contrôler les paramètres en entrée et des conditions extérieures) :

Code :

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

1
2
if( InstigatedBy == none || Victim == none || Victim == InstigatedBy || ( !InstigatedBy.Weapon.IsA('SniperRifle') && !InstigatedBy.Weapon.IsA('ShockRifle') && !InstigatedBy.Weapon.IsA('minigun') && !InstigatedBy.Weapon.IsA('enforcer') ) || !InstigatedBy.IsA('PlayerPawn') || Victim == lastVictim[ playerID ] || lastVictim[ playerID ] == none )
 return;

En même temps, en l'écrivant proprement :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
if( InstigatedBy == none 
  || Victim == none 
  || Victim == InstigatedBy 
  || ( !InstigatedBy.Weapon.IsA('SniperRifle') 
     && !InstigatedBy.Weapon.IsA('ShockRifle') 
     && !InstigatedBy.Weapon.IsA('minigun') 
     && !InstigatedBy.Weapon.IsA('enforcer') ) 
  || !InstigatedBy.IsA('PlayerPawn') 
  || Victim == lastVictim[ playerID ] 
  || lastVictim[ playerID ] == none )
 return;

C'est vachement plus clair qu'avec 42 ifs à la suite l'un de l'autre.

Bon, il serait sans doute encore mieux d'écrire une fonction "test" et de l'appeler, pas passons

[souviron34]

La dernière écriture est plus concise mais, concrétement, est-ce qu'il y a une différence entre ces deux codes après compilation ? Si oui, quel est le code le plus performant ? Quels autres différences pourrais t-il y avoir au niveau assembleur/bytecode/code machine ou durant l'exécution ?

Comma l'a dit Garulfo, aucune différence à priori.

Je suis d'accord avec toi sur la 2eme partie, seulement si on part du principe que l'algo et l'archi sont bons, on peut quand meme gagner pas mal de temps sur de l'optimisation locale de code non?

Là aussi, 100% d'accord avec Garulfo..

Non on ne gagne rien d'important... Le jour où ça deviendrait une optimisation importante, c'est qu'il faudrait jeter tous les compilos et les cartes CPU à la poubelle...

De même que dans les écritures i++ par rapport à i=i+1, c'est exactement la même chose, sauf à la lecture...

Je veux juste dire que si faire quelques optimisations peuvent te faire gagner 20% de temps, que ca te prend 1 jour pour les faire et que ton programme tourne sur 5j, bin au final a chaque fois que tu le lances tu gagnes quand meme 1j, bien sur c'est sans doute très négligeable par rapport aux possibles milliers de jours que tu gagnes en passant d'un mauvais algo a un bon, mais bon au final c'est quand même pas rien.

Voir ci-dessus..

Gagner 20% se ferait en changeant d'algorithme. Tout au plus en travaillant là-dessus gagneras-tu 0.000001 % du temps, et encore je suis gentil...

Ca doit quand meme pas etre pour rien que ces opérateurs sur les bits ont été inventés, j'avais testé en cours et faire des décalages (<<) pouvaient faire gagner pas mal de temps dans certains cas. Et ca doit pas non plus etre pour rien que certaines personnes integrent des bouts d'assembleur dans leurs programmes non?

Comme l'a dit Garulfo, ce n'est pas pour cette raison. C'est bêtement de l'électronique. Les portes et circuits physiques sur les cartes fonctionnent la plupart du temps en bits (signaux carrés). Il fallait un outil pour les utiliser. Et de plus les opérateurs de décalage servent la plupart du temps actuellement à stocker (ou relire) des valeurs dans moins d'espace (compression) , donc à gagner de la place et non à gagrer du temps.

Maintenant l'usage de l'assembleur est nécessité en général dans 2 seules occasions : interagir directement avec des "devices" électroniques, ou gagner du temps par rapport à un langage compilé (par exemple un read Fortran ou C mettra (?? en tous cas mettais) 4 fois plus de temps (car il passe à travers la bibliothèque) que un read assembleur..

C'est vachement plus clair qu'avec 42 ifs à la suite l'un de l'autre.

Avec 42, je suis pas si sûr
(ou alors ta page affiche plus que 42 lignes d'un coup)

L'autre limitation se fait quand entre 2 ifs il y a une opération différente (du style 5 ifs puis ouverture d'un fichier puis de nouveau 5 ifs)..

Bon, il serait sans doute encore mieux d'écrire une fonction "test" et de l'appeler, pas passons

Abzolument...

[Jimalexp]

En même temps, en l'écrivant proprement :

Oui, présenté de cette manière c'est plus lisible. Aussi la "lourdeur" de ce test (la raison pour laquelle je posais la question ) n'est finalement qu'apparente.

Il reste juste les particularités des langages qui peuvent jouer. En Visual Basic un cumul de conditions précédé d'un non logique ne se comporte pas de la manière qu'on s'attendrais d'un point de vue algorithmique (j'aurais un exemple sous la main d'ici peut être une semaine).

Bon, il serait sans doute encore mieux d'écrire une fonction "test" et de l'appeler, pas passons

Une fonction pour valider les paramètres en entrée d'une méthode ? Ca se fais :p ?

[souviron34]

Une fonction pour valider les paramètres en entrée d'une méthode ? Ca se fais :p ?

Ben voui

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
Boolean Weapon_Is_Not_Ok ( Weapon Weap )
{
if ( ! Weap.IsA('SniperRifle') && 
     ! Weap.IsA('ShockRifle') && 
     ! Weap.IsA('minigun') && 
     ! Weap.IsA('enforcer') )
     return True ;
else
     return False ;
}

Boolean Victim_Is_Not_OK ( Victim Vic, Victim lastVic )
{
   if ( Vic == none || 
        Vic == InstigatedBy ||
        Vic == lastVic ||
        lastVic == none )
        return True ;
   else
        return False ;
}


Boolean Instigator_Is_Not_OK ( Instigator Instig )
{
   if ( InstigatedBy == none ||
        ! InstigatedBy.IsA('PlayerPawn') )
       return True ;
   else
        return False ;
}


....

if ( Instigator_Is_Not_OK ( InstigatedBy ) ||
     Weapon_Is_Not_OK (InvestigatedBy.Weapon) ||
     Victim_Is_Not_OK ( Victim, LastVictim[playerID]) )
   return;

[Jimalexp]

Désolé de poser la question ainsi mais la manière dont a m'as enseigné l'objet semble m'avoir donné une fausse idée sur ce qui constitue une méthode. C'est une approche très élégante et qui me seras certainement très utile. Merci souviron34 .

[alex_pi]

Nan mais rien ne t'empeche de mettre ça dans une méthode et de faire

Code :

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

1
2
if(weapon.is_not_ok())
  return