Discussion :

[souviron34]

je suis totalement d'accord avec toi ol9245.. Pour une fois désolé PRomu@ld

Mais je met moi aussi le code à la poubelle si je vois ça, et je ne vois aucun cas qui puiisse comme tu dis "dans la vie de tous les jours" justifier un tel comportement.

ça peut être lisible ou non, mais c'est le principe même qui est en cause.

Comme les

Code :

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

for ( i = 0 ; j < 4 , opt=opt+1, pt=pt++, dcl--, .... ; i++ )

...

De plus, si tu fais du code "industriel", ce n'est pas maintenable (et je ne parle pas de maintenance "à long terme", mais par exemple par quelqu'un su SAV).

Bon on s'est un peu écarté du sujet, mais c'est juste que (et ol9245 et pseudocode comme moi j'en suis certain) on a tous vu de telles horreurs qu'on est assez sensibilisé à de la belle écriture....

Compact ne veut pas dire optimisé.

Enfin dernier point sur le sujet : il est évident que lorsqu'on optimise du code dans ses derniers retranchements la lecture peut devenir ardue... Mais elle est cependant rendue plus facile si l'écriture suit certaines règles de bon sens.
L'optimisation se fait sur l'algorithme, les données, ou leur représentation, mais l'écriture de l'algorithme n'est pas touchée....

Maintenant, il est évident que calculer la complexité exacte peut être utile... Cependant dans l'écrasante majorité des cas, le calcul de complexité sert uniquement de base d'ordre de grandeur pour savoir si : 1) l'algo est efficace 2) si on augmente la machine est-ce que cela ira plus vite ? et enfin 3) donner une limite prévisionnelle du temps de calcul : 1 seconde, 1 minute, 1 heure, 1 jour, 1 semaine, 1 an... soit pour satisfaire un client, soit pour demander du temps sur une machine ultra-puissante (je me souviens qu'en thèse, sur un HP1000, j'avais à faire un Simplex sur 1000 étoiles, et j'avais calculé un an 1/2 de calcul. D'où achat d'une heure de Cray.. )

[PRomu@ld]

Mais je met moi aussi le code à la poubelle si je vois ça, et je ne vois aucun cas qui puiisse comme tu dis "dans la vie de tous les jours" justifier un tel comportement.

Le coût d'une racine carré est un peut plus que celui d'une division qui elle est 5 fois plus lente qu'une muliplication (en terme de cycle processeur).

Comme je l'ai dis, je me suis enflamé lorsque j'ai dis tous les jours mais ce genre de trucs je le fais quasi-quotidiennement (accompagné d'une dose de commentaires conséquents). J'ai eu tord de généraliser mon propre cas, excusez-moi ...

Compact ne veut pas dire optimisé

.

Ca n'est absolument pas ce que j'ai dis.

on a tous vu de telles horreurs qu'on est assez sensibilisé à de la belle écriture....

absolument d'accord. Sorti de mon domaine, je suis relativement pointilleux là dessus.

[pseudocode]

J'avais bien saisi le message, il arrive dans un contexte de performance pure (j'ai eu le tord de penser que mon domaine avait énormément d'importance ) que l'on veuille limiter les opérations couteuses comme la racine carrée, et c'est pour cela que je voulais dire que les commentaires était nécessaires.

Code :

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

1
2
3
for (i=0 ; i*i < n ; ++i) {
...
}

Code :

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

1
2
3
4
int racine_de_n = (int)sqrt(n) ;
for (i=0 ; i<racine_de_n ; ++i) {
...
}

C'est sur, pour les performances, il vaut mieux se taper une multiplication a chaque tour de boucle, plutot que de calculer une seule fois une racine carrée...

[PRomu@ld]

Bon, il est vrai qu'ici, c'est pas très judicieux. (même ridicule)

Mais je suis convaincu qu'une écriture parfois moins claire permet d'améliorer les performances.

A titre d'exemple, je fais de la synthèse d'image, je passe d'une image générée en un peu moins de 10 secondes à presque 6-7 images par secondes (et presque une vingtaine avec des instuctions SSE). l'algorithme utilisé étant scrupuleusement le même, la complexité est la même.

[pseudocode]

Oui, mais dans ton cas il s'agit d'optimisation d'implémentation, et pas d'optimisation d'algorithme. Effectivement dans ces cas la, tu peux ecrire du code "moins optimal" en sachant que le compilateur (ou le hardware) accelerera le traitement.

Ca me rappelle la glorieuse epoque du codage des "Demos" en assembleur sur Atari où, pour faire defiler 100 etoiles (=100 pixels), il etait plus performant de dupliquer 100 fois une ligne plutot que de faire une boucle.


PS: Je m'en voudrait de dire au responsable de la rubrique () qu'il participe a faire partir ce thread en total hors-sujet....Donc je le dirais rien

[PRomu@ld]

PS: Je m'en voudrait de dire au responsable de la rubrique () qu'il participe a faire partir ce thread en total hors-sujet....Donc je le dirais rien

Oui, c'est le week-end, il y a un peu de relachement , d'autant plus que je fais la chasse à ce genre de pratique. Je suis désolé .

Et puis c'était pas totalement hors-sujet, ça montre que la complexité n'est qu'une indication et qu'elle ne reflète pas forcément la réalité. Entre deux algorithmes en O(n log n) il peut exister des différences notables en pratique (du fait des constantes cachées)