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.

[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

[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?