rapidité d'exécution d'une fonction

Voici deux exemples de code :
code 1

Code:

---

1 2 3

int max(int a,int b) { return ((a<=b)?b:a); }

---

code 2

Code:

---

1 2 3 4 5 6 7 8 9 10

int max(int a,int b) { int resul; if ( a <= b ) { resul = b; } else { resul = a; }   return resul; }

---

Ces deux codes offrent la même fonctionnalité. Mis à part le côté pas très lisible du premier, il y a-t-il une différence de rapidité d'exécution entre ces deux codes ?

(je sais que l'exemple est un peu simpliste et je pense que s'il y a une différence, elle ne doit pas être très grande :roll:, je veux juste savoir si théoriquement, une fonction sera plus rapide que l'autre).

Il est probable qu'un bon compilateur saura optimiser de manière à minimiser la différence de performance entre les deux versions. Si tu penses que la deuxième version est plus lisible, utilise la deuxième. Ca ressemble au style que j'utiliserais sur des fonctions un poil plus compliquées. Pour cette fonction max, la première version est suffisamment lisible à mon goût.

De toute manière, à moins d'appeler massivement la fonction max() (et encore...), la différence de perf entre les deux versions est probablement insignifiante.

Un petit conseil: si tu as à choisir entre deux implantations qui diffèrent par leur lisibilité, choisis la plus lisible. Tu optimiseras plus tard et seulement si nécessaire. "Premature optimization is the root of all evil" (Donald Knuth).

Thierry

Merci Thierry pour ta réponse.

Bien sûr que je préfère coder de manière lisible, mais d'un strict point de vue de la rapidité d'exécution, et en imaginant un code beaucoup plus gros, est-ce que ce genre de modifications change quelque chose ?

En supposant que le compilateur est très bête (et qu'il n'a donc pas cherché à optimisé le code ...), la première est plus rapide car le temps qu'il faut pour créer puis de détruire la variable result n'est pas nul.

D'ailleurs il est inutile de créer une variable result. On peut directement faire un return après le if.

Citation:

---

Envoyé par Nykoo

D'ailleurs il est inutile de créer une variable result. On peut directement faire un return après le if.

---

En fait, j'ai essayé de faire les codes les plus opposés qui soit, afin d'essayer d'illustrer mon propos.

Citation:

---

Envoyé par Melem

la première est plus rapide car le temps qu'il faut pour créer puis de détruire la variable result n'est pas nul.

---

OK

Pour trouver un compromis entre rapidité et lisibilité je propose une solution

-- Les fonctions et autres procedures doivent toujours etres lisibles

Mais si dans certain cas tu as pour idée de faire usage de truc moches comme l'operateur ternaire .... Fait le mais uniquement dans le cadre d'une macro

-- Les macros tu te donne le droit de les coder en négligeant la lisibilité.

Citation:

---

Mais si dans certain cas tu as pour idée de faire usage de truc moches comme l'operateur ternaire .... Fait le mais uniquement dans le cadre d'une macro

---

Ah oui? Et pourquoi? Et pourquoi moche?

Citation:

---

Les macros tu te donne le droit de les coder en négligeant la lisibilité

---

Une macro ne devient illisible à ce point que lorsqu'on cherche à implémenter une usine à gaz avec. Qu'est-ce qu'y a d'illisible dans :

Code:

---

#define is_positif(x) ((x) > 0)

---

Citation:

---

Envoyé par Nykoo

D'ailleurs il est inutile de créer une variable result. On peut directement faire un return après le if.

---

De manière générale, je trouve que les return sauvages nuisent à la lisibilité et à la facilité de maintenance du code. 1 fonction = 1 point de sortie. Mais ce n'est que mon avis...

Thierry

Citation:

---

Envoyé par azalsup

Pour trouver un compromis entre rapidité et lisibilité je propose une solution

-- Les fonctions et autres procedures doivent toujours etres lisibles

Mais si dans certain cas tu as pour idée de faire usage de truc moches comme l'operateur ternaire .... Fait le mais uniquement dans le cadre d'une macro

-- Les macros tu te donne le droit de les coder en négligeant la lisibilité.

---

Je ne trouve pas nécessairement cette macro illisible:

Code:

---

1 2 3

/* -tc- ATTENTION aux effets de bord, les arguments de cette   macro sont evalues deux fois */ #define MAX(a, b) (((a) > (b)) ? (a) : (b))

---

Par contre, elle peut réserver des surprises. Le commentaire répond à un objectif d'information préventive.

Thierry

Merci pour ces réponses.

En fait, je voudrais que l'espace d'un instant, une fois n'est pas coutume, on laisse de côté la lisibilité du programme. Dans ce cas, des simplifications d'écriture (comme celles que j'ai essayé d'illustrer dans mon exemple mais aussi d'autres plus compliquées et moins lisibles ;)) peuvent-elles permettre un gain en rapidité ?

Il faudrait mesurer pour le quantifier, mais en désactivant toutes les optimisations du compilo, la première version est probablement légèrement plus rapide. Je pense toutefois que la différence n'est pas significative et ne mérite pas qu'on s'y intéresse, sauf évidemment si tu peux démontrer que c'est handicapant dans un contexte particulier.

Thierry

Citation:

---

Envoyé par corentin59

Dans ce cas, des simplifications d'écriture peuvent-elles permettre un gain en rapidité ?

---

Je pense qu'il est difficile d'avoir une réponse absolue, et ce quel que soit le langage.

Comme signalé plus haut, cela dépend du compilateur; est-ce qu'il va produire la même chose avec la version lisible qu'avec la version "simplifiée" ? (sans forcément rester sur ton exemple où la réponse est évidemment non).

Citation:

---

Envoyé par Thierry Chappuis

"Premature optimization is the root of all evil" (Donald Knuth).

---

En fait, cette citation a seulement été popularisée par Knuth, elle n'est pas de lui semble-t-il, elle est du logicien Hoare (le découvreur du quicksort) comme d'ailleurs le signale Knuth lui-même dans Literate Programming, chapitre sur les erreurs de TeX ("Hoare's dictum").

Citation:

---

Envoyé par c-candide

En fait, cette citation a seulement été popularisée par Knuth, elle n'est pas de lui semble-t-il, elle est du logicien Hoare (le découvreur du quicksort) comme d'ailleurs le signale Knuth lui-même dans Literate Programming, chapitre sur les erreurs de TeX ("Hoare's dictum").

---

OK, je prends note.

Thierry

salut

juste pour dire que les 2 codes donnés en exemple au début du thread sont équivalents: le listing assembleur généré sera exactement le même

corentin si tu veux avoir des réponses un peu plus précises je pense que tu devrais faire un peu d'assembleur, ça ne fait jamais de mal pour un programmeur C !

Le code assembleur généré sans optimisation (-O0) donne ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

.globl max1 .type max1, @function max1: pushl %ebp movl %esp, %ebp subl $8, %esp movl 8(%ebp), %eax movl %eax, -8(%ebp) movl 12(%ebp), %eax movl %eax, -4(%ebp) movl -8(%ebp), %eax cmpl %eax, -4(%ebp) jge .L2 movl -8(%ebp), %eax movl %eax, -4(%ebp) .L2: movl -4(%ebp), %eax leave ret

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

.globl max2 .type max2, @function max2: pushl %ebp movl %esp, %ebp subl $16, %esp movl 8(%ebp), %eax cmpl 12(%ebp), %eax jg .L5 movl 12(%ebp), %eax movl %eax, -4(%ebp) jmp .L7 .L5: movl 8(%ebp), %eax movl %eax, -4(%ebp) .L7: movl -4(%ebp), %eax leave ret

---

Les listings générés ne sont donc pas exactement les mêmes (même avec les optimisations activée par -O2), mais les différences sont minimes.

Thierry

Citation:

---

Envoyé par corentin59

En fait, je voudrais que l'espace d'un instant, une fois n'est pas coutume, on laisse de côté la lisibilité du programme. Dans ce cas, des simplifications d'écriture (comme celles que j'ai essayé d'illustrer dans mon exemple mais aussi d'autres plus compliquées et moins lisibles ;)) peuvent-elles permettre un gain en rapidité ?

---

MinGW compile les deux fonctions exactement de la même façon, même en -O0.
Il ne faut obscurcir le code que si tu sais que ça va t'apporter quelque chose, après avoir profilé ton programme.

salut

Thierry ton compilateur m'inquiète avec -O2 il devrait donner la même chose

Citation:

---

Envoyé par corentin59

Voici deux exemples de code :
Ces deux codes offrent la même fonctionnalité. Mis à part le côté pas très lisible du premier, il y a-t-il une différence de rapidité d'exécution entre ces deux codes ?

(je sais que l'exemple est un peu simpliste et je pense que s'il y a une différence, elle ne doit pas être très grande :roll:, je veux juste savoir si théoriquement, une fonction sera plus rapide que l'autre).

---

Il n'y a pas de réponse définitive. Ca dépend de l'implémentation. Tout ce qu'on peut faire, c'est définir de conditions de production code et d'exécution et de faire des mesures dans ces conditions.

La comparaison donnera une idée dans ces conditions uniquement. Il suffit qu'un facteur change pour que la réponse change (ou pas...).

Si on cherche à gagner du temps, ce genre de micro optimisation non portable ne fera rien ou peu gagner. C'est surtout sur l'algorithme qu'il faut travailler en apprenant à en évaluer la complexité. C'est un problème général de programmation qui n'a rien à voir avec le langage C.