Discussion :

[corentin59]

Voici deux exemples de code :
code 1

Code :

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

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

code 2

Code :

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

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 , je veux juste savoir si théoriquement, une fonction sera plus rapide que l'autre).

[Thierry Chappuis]

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

[corentin59]

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 ?

[Melem]

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.

[Nykoo]

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

[corentin59]

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.

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

[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é.

[Melem]

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?

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 :

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

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

[Thierry Chappuis]

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

[Thierry Chappuis]

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 :

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

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

[corentin59]

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

[Thierry Chappuis]

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

[Keihilin]

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).

[c-candide]

"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").

[Thierry Chappuis]

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

[acx01b]

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 !

[Thierry Chappuis]

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

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
.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 :

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
.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

[dapounet]

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.

[acx01b]

salut

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

[Emmanuel Delahaye]

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 , 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.