Discussion :

[Blustuff]

Quand j'ai commenc� l'asm, je me suis rendu compte que le compilateur fesait tout mieux que moi. Mais apr�s quelque experience, en fait, j'arrivais a ecrire certaine partie parfois plus de deux fois plus rapide d'execution que ce que pouvait faire le compilateur. L'optimisation devient parfois tellement complexe, qu'il est impossible de cr�er une methode syst�matique d'optimisation.

[LeGreg]

Quand j'ai commenc� l'asm, je me suis rendu compte que le compilateur fesait tout mieux que moi. Mais apr�s quelque experience, en fait, j'arrivais a ecrire certaine partie parfois plus de deux fois plus rapide d'execution que ce que pouvait faire le compilateur. L'optimisation devient parfois tellement complexe, qu'il est impossible de cr�er une methode syst�matique d'optimisation.

je ne parlais pas d'assembleur..

Tu sais l'algo ?? ces trucs qu'on apprend a l'ecole ? Plus d'autres trucs qu'on apprend sur le tas..

LeGreg

[LeGreg]

Quand j'ai commenc� l'asm, je me suis rendu compte que le compilateur fesait tout mieux que moi. Mais apr�s quelque experience, en fait, j'arrivais a ecrire certaine partie parfois plus de deux fois plus rapide d'execution que ce que pouvait faire le compilateur. L'optimisation devient parfois tellement complexe, qu'il est impossible de cr�er une methode syst�matique d'optimisation.

Il existe des methodes systematiques
l'optimisation ce n'est pas encore de la magie noire..

LeGreg

[Xiao-An]

Bonne analyse -> Bonne conception -> Bonne algorithme -> Bon codage = Rapidite du code

D'ailleurs n'oublions pas qu'un algorithme doit pouvoir s'appliquer a n'importe quel language de programmation.
Bien sur a chaque language ses performances dans un domaine d'application....

[Blustuff]

Je n'ai d'une part jamais dit qu'il n'y avait aucune methode syst�matique. J'ai simplement dit que beacoup d'optimisations du code au niveau de l'asm ne sont pas effectu�es par le compilateur.

Je n'ai pas non plus dit qu'il ne fallait pas optimiser l'algorithme. Et le compilateur n'optimise pas les algorithmes. (du moins je ne consid�re pas ces optimisations comme optimisation d'algorithme)

Le sujet de l'algorithme a �t� abord� plus avant dans le sujet, et pour vous ressituer, c'est la premi�re chose a faire. Je suis navr� que vous n'ayez pas lu ce post en entier. Vous auriez pu y voir que je parle notement sur un exmple de l'optimisation d'algorithme.

[Blustuff]

enfin si, je l'ai dit :)) Mais c'est un peu ambigue, ce que je voulais dire, c'est que beacoup d'optimisations de code ne peuvent pas �tre faite de mani�re syst�matique. Juste consid�rent "les optimisations" et non pas "l'optimisation". Enfin je me suis mal exprim�. Mais je n'ai jamais fait d'�cole justement, c'est peut etre pour ca.

[Xiao-An]

A propos meme du codage en C++, une bonne connaissance de son compilateur permet d'optmiser le code qu'il compilera.

En effet, en tenant des regles de priorites, des formats des types, des classes de stockage, des regles de portee en fonction de son compilateur, on peut obtenir de bons resultats en performances.

[Metal Tom]

En parlant de carrence algorithmique, regardez le code que j'ai d�j� vu dans un programme :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
int i, j;
j=0;
for (i=0 ; i<MAX ; i++)
{
     A[i] = B[j];
     j++;
}

Si y'en a qui arrivent faire des choses comme �a, imaginez quand �a se complique un peu ...

[Argh!]

euh juste pour les copie par memcpy, je suis pas sur quel soit r�element plus rapide sur des petits tableau. je m'explique, kan on debug un memcpy, on trouve plein d'instruction de controle de partouts ki font des trucs ke jai pas cherch� a comprendre, donc pour copier un tableaa de 50 char, je pense qu'il vaut mieux faire 50 = q'un memcpy. le mieux ce serait l'asm inline avec un bon

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
mov cx, 50/4
mov si, source
mov di, destination
rep movsd

mais c vrai ke c plus rapide a coder un memcpy et ya moins de chance de se planter.
si je me plante (c probable), merci de me prevenir.

[Metal Tom]

T'inqui�te pas le compilateur il optimise bien du moment que ton algo est bien foutu. Dans le cas d'un memcpy si c'est pas bien optimis� je ne vois pas l'int�r�t du C. Je crois que �a doit �tre une des premi�res instructions qui ont �t� optimis�es � mort.

[Blustuff]

Pour copier un tableau de 550 �l�ments, il n'y aucunement besoin d'optimisation, une simple boucle for suffira. Pour conscision, memcopy sera amplement suffisant, m�me si les calculs pr�cedant et succedant la copie sont nombreux, je pense que vous n'aurez jamais a resentir ces effets.

[Argh!]

blustuff, je suis tout a fait d'accord avec toi ca ne sert a rien, mais en fait on parle depuis le d�but d'optimisation qui n'ont jamais un effet super
(ki peut dire en regardant un programme tourner si les x *= 2^y ont �t� remplac� par x << y ?), la difference de vitesse est infime, mais elle est la comme m�me.
d'accord je pinaille mais c le sujet du forum : comment pinailler 3 heures pour gagner 3 millisecondes a l'execution. (mis a part kan on touche aux algorithmes...)

[Blustuff]

Non, non, il y a des optimisations serieuses. Je sais que parfois j'ai r�ussi a augmenter de plus du double la vitesse d'execution d'un programme. Mais l� sur le dernier sujet, c'est une question visiblement superflue.

En fait il n'est pas inutile de jetter un coup d'oeil de temps en temps au code asm que cr�e le compilateur, pour donner une id�e des optimisations qu'il peut faire, et de celles qu'il ne fait pas.

[Metal Tom]

(ki peut dire en regardant un programme tourner si les x *= 2^y ont �t� remplac� par x << y ?), la difference de vitesse est infime, mais elle est la comme m�me.

C'est testable. T'en fais 100.000.000 � la suite : tu verras facilement la diff�rence. Surtout en utilisant une machine lente.

[Elrond]

...
(ki peut dire en regardant un programme tourner si les x *= 2^y ont �t� remplac� par x << y ?), la difference de vitesse est infime, mais elle est la comme m�me.
...

Un tel changement est sans interet...

Sauf s'il y en a une utilisation massive. Dans ce cas il peut etre utile et eventuellement avoir un effet visible par l'utilisateur.

C'est aussi ca qu'il faut voir. Chaque optimisation peut paraitre infime. Le tout est de savoir quel niveau d'utilisation en est faite, quelle quantite d'optimisations realiser, quel est le gain (temps d'execution/memoire) et la perte (temps d'execution/memoire/temps de developpement/maintenance) de chacune.

[Causa Sui]

Voici un petit r�sum� de ce qui pr�c�de, fait pas quelqu'un (mais qui?) il y a quelque temps:

Voici quelques conseils pour am�liorer la vitesse d'�x�cution des programmes et les rendres plus "propres":
1. Bien qu'une l�gende veuille qu'on utilise des d�calages explicitement plutot que de multiplications (dans le cas de multiplication par des multiples de 2); cela est tout a fait inutil avec la plupart des compilateurs, qui ont "l'inteligence" de faire la conversion. En plus les d�calages rendent le code plus compliqu� � lire, et ne fonctionnent qu'avec des entiers.
2. Utiliser de variables enti�res (de pr�f�rence int).
3. Ne pas prendre des variables trop importantes en taille sans que ce ne soit utile.
4. Quand vous utilisez des constantes, utilser "const", ce qui repr�sente un gain de place et de vitesse.
5. Pr�calculer ce qui peut l'�tre. Si vous avez besoin de sinus dans un programme, utilisez un tableau avec les sinus des angles de 0 � 2pi radians (0 � 360 degr�s).
6. Ne faites pas des optimisation si votre code est mauvais! Ca ne sert � rien! La base d'un bon code est un bon algorithme. C'est la qu'est le secret d'un code rapide... et puissant.

[ShootDX]

Enti�rement d'accord avec le point 6. Je l'aurais m�me mis en premi�re position.

[hegros]

Optimiser pour gagner 1sec je trouve que c'est du temps perdu surtout si ca doit prendre la journ�e

Il m'arrive souvent et c normal je pense quand j'ecris une ligne de code ou deux d'essayer de trouver la fa�on la plus efficace , lisible de le faire
Pourtant je suis sur que j'ai du passer outre et perdre 4-5nanosecondes

Biensur multipli� 1 seconde perdu par instruction surr 1 million l'instruction(rarement vu �a)ca fait beaucoup

Il faut vraiment se pencher sur le probleme de l'optimisation de 1 microseconde si l'application le demande(je pense au temps reel ou 1miiliseconde peut tout faire pencher)

Toutes les applications ne demande pas ce genre d'optimisation que je lis dans vos derniers posts

D�velopper un logiciel pour la gestion d'une pharmacie par exemple
La meuf qui est au comptoir si elle cherche le prix d'un medicament en ayant saisi le code barre( suppos� une grosse bdd) Franchement le temps de reponse n'est pas une contrainte a l'application.Que cela mette 1secondes ou 3 secondes cela convient tout a fait au niveau et a l'environnent de l'utilisateur.

Enfin vous me comprenez....

PS:Je sais plus qui a dit qu'on lui avait demand� d'optimiser une boucle for pour un entretien d'embauche mais le mec devait etre sur les nerfs ce jour la

Mais c'est vrai que c'est interessant de voir cela dans la mesure ou on apprends des choses , on voit mieux ce qu'on programme enfin....

[Blustuff]

Lire tout c'est bien, mais il ne faut pas lire trop vite. L'entretiens, �tait, et ca a �t� dit par la personne concern�e, pour savoir si on connaissait les optimisations faites par le compilateur. Ce test a pour but de savoir si la personne n'optimise pas pour rien. Quand vous ecrivez :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
n = (((y << 4) + (y << 3) + y) << 5) + x;
n += n <<2;

au lieu de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
n = (y * 800 + x) * 3;

Non seulement vous perdez du temps, mais, en plus, le compilateur fait quelque chose de plus rapide que vous. Le comp�lateur, va faire un d�calage de bits, et trois lea (pour ceux qui connaissent, lea peut �tre utilis� pour les multiplications par 2, 3, 4, 5, 8 et 9), ce qui est plus rapide. Et en plus vous auriez tort d'optimiser, parce que la solution la plus rapide, est effectivement de faire la multiplication par 800 explicitement en assembleur. Ce genre d'optimisation est une perte de temps inutile. (Cette expression � n�anmoisn besoin d'�tre optimis�e, mais que dans les cas, rarissimes ou vous codez une librairie graphique pour un mode graphique 800*600*24bits)


Comme dit dans le post, il faut bien savoir si le code a besoin d'�tre optimis� ou non. Ca ne remet pas en cause ce qui a �t� dit dans ce post, mais, ajoutez tout de m�me a la liste, tout en haut en premier : "Se demander si il est interessant d'optimiser le code". C'est une optimisation tr�s importante, celle de votre temps. Et il ne s'agit pas l� seulement de reagarder si c'est optimisable ou non, mais de savoir combien on doit optimiser. La premi�re optimisation, qui ne figure pas dans la liste, est celle de l'algorithme. Elle est tr�s rapide en g�n�ral, quand les algorithmes sont simples. C'est moins visibles souvent en POO, mais quand vous n'�tes plus dans le cadre objet, mais que vous faites abstraction du reste, par exemple lorsque vous codez une fonction a part, c'est de r�flechir comme si vous �tiez un processeur, et de vous dire, par exemple "Ah, la je fais deux fois la boucle pour rien". Pass� cette optimisation qui se fait tr�s bien par tous avec un peu d'experience, les autres optimisation, ne feront jamais, gagner beacoup plus de temps, a moins de vous en faire perdre beacoup a vous, donc, il faut que ca vaille le coups. Donc pour revenir a ce que j'ai dit, il est important de se demander jusqu'a quel point il faille optimiser.

[LeGreg]

Enti�rement d'accord avec le point 6. Je l'aurais m�me mis en premi�re position.

Oui il est surtout plein de vide son point 6:
"Si votre code est mauvais, jetez-le."

Je vais jouer l'avocat du diable et d�fendre les points un par un.

1- les decalages. Je les utilise tous les jours. Pire je stocke plusieurs flags dans une variable enti�re et j'y acc�de par des masks pr�d�finis sur certains bits. Pourquoi faire x << n plutot que x * 2 ^n ? Tout simplement parce que x << n est toujours plus rapide et plus simple � �crire qu'une mise � la puissance, fut-elle de deux (d'ailleurs 2^n s'�crit de mani�re optimale 1 << n, donc on tourne autour du pot).
La raison pour laquelle on utilise les puissances de deux dans certains algorithmes (adressage de textures, fourier transform) est justement pour pouvoir utiliser ce genre d'astuce pour faire du code plus rapide. (que ce soit sur le processeur central ou grav� dans du silicium).

�videmment, je ne parle pas du boulet qui va aller dans tout son code � la recherche des * 2 pour les remplacer par des << 1. Ca compte pour une "d�soptimisation" �a.

2 - utilisez les types dont vous avez besoin. C'est quoi cette histoire de pr�f�rer les types entiers. on ne "pr�f�re" pas utiliser tel ou tel type, on a "besoin" d'utiliser un type float plutot qu'un type int. Je ne sais pas qui a pondu cette r�gle.
Par ailleurs pour parler d'�fficacit� il faut juste se rappeler que utiliser des types float sur un processeur moderne est aussi rapide que d'utiliser des int (multiplication addition, je ne parle pas de la multiplication par une puissance de deux dont on a parl� plus haut). il peut �tre couteux par contre de faire la conversion int/float et vice versa trop souvent par ligne de code...

3- Rien � redire au 3, sauf que je pense que personne ne pensera � prendre de la m�moire dont il n'a pas besoin.
Ah si certains d�butants allouent 1 Go sur la pile. Mais c'est d�finitivement pas bien. (attention on vous regarde !)

4- Const n'a jamais repr�sent� un gain de place et de vitesse.
A moins qu'il n'allie �a avec la r�gle 2, pour dire que toutes les constantes d'un programme sont des const int ?
Au moins utiliser un #define ne posera jamais de probleme de collision de nom au linkage et utiliser un enum permettrait au moins d'avoir le nom de la constante au deboguage (et la v�rification des types)..
Pour ce qui est des const *, const & et const tartempion, il faut les utiliser mais certainement pas pour ces soi-disant gains de place et de vitesse.
C'est une b�quille du programmeur, pas un outil d'optimisation !

5 - Il fut un temps ou pr�calculer les cosinus etait bien vu par toutes les machines. A l'heure actuelles certaines machines sont tellement compliqu�es que vouloir y appliquer des r�gles simples ne t'apporteront aucun benefice.
Par exemple les processeurs modernes ont un moyen de calculer les sinus et cosinus d'un angle en une seule instruction au cout d'un nombre consequent de cycles. Et lire depuis un tableau assez important en taille mais qui n'�tait pas dans le cache lors de la lecture entraine un cout en cycles encore plus important. Choisissez votre camp.

Mon conseil: limitez les calculs de cosinus au strict n�cessaire et ne faites le coup du tableau pr�calcul� que si vous avez montr� par A+B que cette solution vous apportera le gain n�cessaire sans perdre la pr�cision dont vous avez besoin.

Et pour savoir si vous y gagnez r�llement une seule solution:
profilez, profilez et profilez encore.

LeGreg