Probleme d'efficacite d'un programme

Tout d'abord, desole du titre peu explicite mais je savais pas trop marquer...

Un 2eme desole mais je suis sur un clavier anglais donc sorry pour les amoureux des accents...

En fait, je fais du C++ depuis quelques annees et je suis dans un Master d'Informatique en Ecosse.

Le professeur nous a demande de programmer des bouts de code tres faciles sauf que je me confronte a un probleme moral tres intense... :?

En fait, j'ai le choix entre deux modelisation differentes :

1.

Code:

---

1 2 3 4 5 6 7

for for prog   for for prog

---

2.

Code:

---

1 2 3 4 5 6 7

for for if prog else prog

---

La question est la suivante, laquelle est la mieux ?

Etant donne qu'il y a une tempo dans 1 "prog" de chaque, je m'en fous pas mal de la vitesse.

En fait, y a t'il une maniere que prefere le compilateur ?

Merci d'avance pour vos reponses.

Xavier

Salut,

En fait, il faut surtout savoir si, les deux programmes doivent être effectués de manière conditionnelle, de manière "séquentielles" (d'abord toutes les boucle du premier puis toutes les boucle du deuxième) ou même l'un apres l'autre, de manière inconditionnelle (l'un puis l'autre, dans la même boucle).

Les deux exemple que tu site ne sont en effet pas du tout équivalent... je manque de temps pour une réponse plus précise :oops:, je te la donnerai en rentrant ;)

Dans le premier cas, chaque boucle for dure la moitie du temps d'execution du programme.

Dans le deuxieme cas, le if dure la moitie du temps et le else dure la moitie du temps egalement.

En esperant avoir repondu a ta question.

Xavier

Citation:

---

Envoyé par valinor4

Dans le premier cas, chaque boucle for dure la moitie du temps d'execution du programme.

Dans le deuxieme cas, le if dure la moitie du temps et le else dure la moitie du temps egalement.

En esperant avoir repondu a ta question.

Xavier

---

Bon, enfin rentré :P...

Pour commencer, je vais "modifier" un peu tes exemples pour qu'ils soient plus parlants;)

Code:

---

1 2 3 4 5 6 7

for n1 for m1 prog1   for o for p prog2

---

ou

Code:

---

1 2 3 4 5 6

for n2 for m2 if test prog1 else prog2

---

Dans le premier cas, si tu déroules tes boucles tu auras une suite d'appels ressemblant à

Code:

---

1 2 3 4 5 6 7 8 9 10

prog1 prog1 prog1 ... un total de (n1*m1) appels à prog1   prog2 prog2 prog2 ... un total de (o*p) appels à prog2

---

alors que, dans l'autre tu aura un résultat proche de

Code:

---

1 2 3 4

prog1 ou prog2 (en fonction du resultat de test) prog1 ou prog2 (en fonction du resultat de test) prog1 ou prog2 (en fonction du resultat de test) ... un total de (n*m) appel à prog1 ou à prog2 (en fonction du resultat de test)

---

Le seul cas dans lequel tu peux envisager que les deux codes pourraient donner une résultat identique de manière certaines c'est si:

1. n2 = n1+o
2. m2 = m1+p
3. test vérifie que n2 > n1 ET m2 > m1

(si les trois conditions ne sont pas remplies en même temps les codes ne fourniront pas un résultat identique)

Ceci dit, et si tu es dans les conditions pour que le résultat reste identique, on peut estimer, de prime abord, que la première version sera plus rapide à l'exécution, en dehors de toute optimisation que le processeur pourrait nous sortir "de derrière les fagots" :roll:

En effet, la deuxième version nécessitera l'utilisation, au niveau des instructions processeur, de trois comparaisons, et de trois sauts (je dirais de prime abord un saut conditionnel et deux sauts inconditionnels), et que ces instructions supplémentaire ont un cout en nombre de fréquence d'horloge du processeur...

Sauf que....

• C'est sans compter sur "l'intelligence" du compilateur, et plus d'un ont déjà été bluffés par les raccourcis qu'il arrive à prendre :lol:
• Au pire, ces six instructions supplémentaires vont demander... une trentaine de fréquence d'horloge :question:... au grand maximum :arrow:
• Au vu des fréquences atteintes par les processeurs actuels, et même en regardant les processeurs "vieux" de 7 ans, il faudrait que le produit n2 * m2 s'élève à plusieurs (dizaines de) millions pour que l'on *commence* à remarquer une différence de l'ordre de ... quelque milisecondes :P

On ne le répétera jamais assez

Citation:

---

Early optimisation is the root of all evil (une optimisation apparaissant trop tôt est le chemin vers tous les maux)

---

Moralite:
Avant de commencer à t'inquiéter des performances, commence en priorité absolue par créer un code qui est facile à lire, qui fonctionne, et qui fait ce que tu attends de lui.

Si, vraiment, ton programme ne présente pas les performances souhaitées, il s'agira de faire un audit en profondeur du code pour y trouver les "goulots d'étranglement", en vue de modifier cette partie du code uniquement, et, surtout, de confirmer le gain de performances par un benchmark...

Si le seul résultat d'une modification apportée est de rendre le code plus difficile à lire, elle doit être abandonnée sur le champs et sans remords ;)

Merci beaucoup de ta reponse qui est pour le moins complete et claire.

Sujet resolu. :king:

Xavier