Discussion :

[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

[LeGreg]

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

C'est � moi qu'on a demand� �a.

Je ne sais pas si le recruteur �tait sur les nerfs, c'�tait chez Electronic Arts et j'ai eu une offre (que j'ai d�clin�e).

Le but ce n'est pas d'optimiser une boucle. La plupart des questions pos�es en entretien n'ont aucune application concrete. Au moins pour les questions demand�es aux d�butants ce sont souvent des probl�mes d�j� r�solus mais qui permettent juste de jauger de la r�activit� d'un candidat.
Mais bon si je l'ai cit�e plus haut c'est juste parce que je trouvais l'id�e interessante.

En general il y a peu de questions d'optimisations dans les entretiens que j'ai pass�, surtout de la correction de code, beaucoup de calculs math�matiques formels ou l'�criture d'algos non triviaux en temps limit�.
L'optimisation c'est la cerise sur le gateau et ce sont souvent des trucs de coll�giens, probablement pour jauger ta "culture de programmation".

LeGreg

[LeGreg]

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.

Le Memcpy g�n�rique n'est pas particuli�rement optimis�, meme si c'est vrai que le code est simple.
Avec une r��criture qui utilise le support MMX (pr�sent depuis de nombreuses ann�es dans les processeurs), le memcopy de base va deux fois plus vite.

Ce n'est certes pas un gain tel qu'on change d'ordre de grandeur comme faire le memcopy en temps logarithmique du nombre de cases m�moires (mais qui sait un jour peut-etre). Mais deux fois plus vite si c'est pour copier de grandes zones de donn�es ou des images, ce n'est pas � cracher dessus.

LeGreg

[ShootDX]

Pour parcourir tous les �l�ments d'une cha�ne termin�e par un '\0' ('\0'-terminated string), au lieu de faire:

Code :

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

for (int i = 0; i < strlen(str); i++) {}

on peut faire:

Code :

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

for (const char* cur = str; *cur != '\0'; cur++) {}

Effectivement, strlen() doit forc�ment parcourir toute la cha�ne pour trouver un '\0', incr�menter un compteur, etc.

[amiro]

je veux savoir comment le parcours d'un tableau a l'aide de pointeur est plus rapide qu'un int i;
merci

[ShootDX]

je veux savoir comment le parcours d'un tableau a l'aide de pointeur est plus rapide qu'un int i;
merci

Ca revient au m�me (optimisation de la part du compilateur).

[el muchacho]

Pour parcourir tous les �l�ments d'une cha�ne termin�e par un '\0' ('\0'-terminated string), au lieu de faire:

Code :

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

for (int i = 0; i < strlen(str); i++) {}

on peut faire:

Code :

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

for (const char* cur = str; *cur != '\0'; cur++) {}

Effectivement, strlen() doit forc�ment parcourir toute la cha�ne pour trouver un '\0', incr�menter un compteur, etc.

Honn�tement, je ne vois pas trop dans quel cas pratique on a besoin de parcourir un tableau de char. Si on se met � �crire du code comme celui-l�, il faut se demander si on n'a pas int�r�t � utiliser la classe std::string. Dans 99% des cas, la r�ponse est oui.

* Pour continuer sur les cha�nes de caract�res, �viter au maximum les printf, sprintf et d�riv�s, qui sont des usines � gaz. Leur pr�f�rer si possible puts (bcp plus simples car pas de formatage) et les op�rateurs de C++ cin/cout<< (qui font un maximum de boulot du formatage � la compilation).

* Retarder/limiter le plus possible les op�rations de fichier, forc�ment lentes, en cr�ant des buffers si n�cessaire.

* Utiliser la STL = plus de g�n�ricit� et moins de bugs dans les algos.
Et dans ce cas, utiliser les bons conteneurs et les bons algorithmes aux bons moment.
std::vector (ou pire un tableau C) n'est pas le conteneur le plus adapt� pour faire un dictionnaire (acc�s en O(n)). Un std::map (en O(log n)) ou mieux, un std::hash_map sera nettement plus indiqu� (O(1)). De m�me, pour les grosses allocations, std::deque peut s'av�rer plus int�ressant que std::vector (ou pire un tableau C).
A part pour des domaines tr�s sp�cifiques, d�s qu'on a affaire � un traitement un peu compliqu� (recherche dans un tableau, merge, recherche d'inclusions, etc), v�rifier si l'algo n'existe pas d�j� dans la STL ou dans des librairies existantes.

* Eviter de cr�er des hi�rarchies de classes de hauteur trop profonde. Au-dela de 4 niveaux, il faut commencer � se poser des questions et chercher � "�taler" une hi�rarchie horizontalement. L'accumulation des constructeurs et des destructeurs finit par tuer les performances (voir les librairies java), sans parler de la gestion des exceptions qui peut devenir rapidement probl�matique. En g�n�ral, faire des hi�rarchies compliqu�es n'est pas bon signe en OO, -en C++ en tout cas-.
L'utilisation de classes param�tr�es (class templates), peut parfois aider. Mais attention � ne pas en abuser, car les templates ne remplacent pas les classes : pas de hi�rarchie possible, et le code devient vite illisible, donc une bonne r�gle � respecter est qu'il faut ne les utiliser qu'avec les types de base en param�tre (int, char, float, boo et int*, char*, float*, bool*l).

Et profiler, profiler, bien �videmment.

ps : l'optimisation du code ne doit pas �tre une excuse pour ne pas utiliser les techniques connues pour am�liorer la robustesse du code, comme les auto_ptr, l'usage de const, des classes stack-based, etc.

[fabien.raynaud]

En terme de rapidit� de code, le premier aspect � aborder est l'efficacit� de l'algorithme utilis� ainsi que les collections utilis�es selon le nombre de donn�es et l'acc�s qu'on y fera (liste simple, chain�es, hash table, etc.)
Apr�s �a, les autres am�liorations perfos restent minimes par rapport au temps consacr�.

[maxlef]

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.

th�oriquement on peux utiliser l'un ou l'autre.... mais il arrive que l'on soit oblig� de pr�f�rer l'un � l'autre...

d'ailleurs je ne sais pas s'il est plus rapide de convertir les float en int afin de travailler plus rapidement avec les int, ou de rester en float ?

[ShootDX]

Code :

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

d'ailleurs je ne sais pas s'il est plus rapide de convertir les float en int afin de travailler plus rapidement avec les int, ou de rester en float ?

Si tes floats sont enti�res (exposant >= 0), alors je dirais que �a d�pend du nombre d'op�rations et de leur type:
1. Pour additionner deux flottants ou trouver leur diff�rence, il faut aligner leurs exposants (pas besoins pour les multiplications/divisions).
2. Pour convertir un flottant en entier, on ne prend que les (m-e) premiers bits du mantisse en consid�ration, o� m est le nombre de bits de celui-ci et e l'exposant du flottant.

Si tes floats ne sont pas enti�res, il faut voir du c�t� des d�cimaux � virgule fixe (exemple: tous les nombres � manipuler sont d�j� align�s sur le m�me exposant, on ne fait que des op�rations sur le mantisse).

[salseropom]

Bonjour, j'avoue ne pas avoir lu les 8 pages de r�ponses alors j'esp�re que je ne vais pas r�p�ter quelqu'un.
Pour vioir les fonctions qui prennent le plus de temps d'ex�cution, il faut utiliser le profiler (lors de la compilation, il faut compiler avec l'option -pg

Ce profiler renvoie le temps d'ex�cution de chacune des fonctions utilis�es. Ainsi, on sait tout de suite qu'elle partie du prgm retravailler.

[Caine]

Pour parcourir tous les �l�ments d'une cha�ne termin�e par un '\0' ('\0'-terminated string), au lieu de faire:

Code :

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

for (int i = 0; i < strlen(str); i++) {}

on peut faire:

Code :

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

for (const char* cur = str; *cur != '\0'; cur++) {}

Effectivement, strlen() doit forc�ment parcourir toute la cha�ne pour trouver un '\0', incr�menter un compteur, etc.

Honn�tement, je ne vois pas trop dans quel cas pratique on a besoin de parcourir un tableau de char. Si on se met � �crire du code comme celui-l�, il faut se demander si on n'a pas int�r�t � utiliser la classe std::string. Dans 99% des cas, la r�ponse est oui.

Des exemples:

Impl�menter un parser de langage ou un g�n�rateur de code.

Reconnaitre dans un flux de caract�res les mots r�serv�s d'un langage. Faire de la surbrillance de sa syntaxe.
D�velopper un outil qui met en place des balises Doxygen sur des sources existant non document�s.

Ecrire un programme qui parse un source afin de remonter des graphes de contr�le ...

Et pour tous ces cas, il vaut mieux du code C optimis� � l'utilisation de la STL.

* Pour continuer sur les cha�nes de caract�res, �viter au maximum les printf, sprintf et d�riv�s, qui sont des usines � gaz.

Je ne vois pas o� sont ces usines � gaz? Certes, les flux C++ sont plus jolis, mais je regrette franchement le formatage de cha�ne parfois.

Leur pr�f�rer si possible puts (bcp plus simples car pas de formatage) et les op�rateurs de C++ cin/cout<< (qui font un maximum de boulot du formatage � la compilation).

Oui, et puts ne dois pas �tre utilis�e en m�me temps que les flux, sinon plantage, au passage. Ainsi que fgets, printf ... Enfin, �a d�pend des compilateurs.

* Retarder/limiter le plus possible les op�rations de fichier, forc�ment lentes, en cr�ant des buffers si n�cessaire.

Excellent conseil, sauf pour les fichiers de logs servant � debuguer.

* Utiliser la STL = plus de g�n�ricit� et moins de bugs dans les algos.
Et dans ce cas, utiliser les bons conteneurs et les bons algorithmes aux bons moment.
std::vector (ou pire un tableau C) n'est pas le conteneur le plus adapt� pour faire un dictionnaire (acc�s en O(n)). Un std::map (en O(log n)) ou mieux, un std::hash_map sera nettement plus indiqu� (O(1)). De m�me, pour les grosses allocations, std::deque peut s'av�rer plus int�ressant que std::vector (ou pire un tableau C).
A part pour des domaines tr�s sp�cifiques, d�s qu'on a affaire � un traitement un peu compliqu� (recherche dans un tableau, merge, recherche d'inclusions, etc), v�rifier si l'algo n'existe pas d�j� dans la STL ou dans des librairies existantes.

Je suis d'accord, dans les applications de haut niveau, la STL est bien. Par contre, tous les domaines de d�veloppement ne demandent pas les m�me temps de r�ponses, par exemple le temps r�el embarqu�.

De plus, il y a souvent un surco�t non n�gligeable en m�moire.

On gagne en s�curit� et en �conomie de code ce que l'on perd en performances et �conomie m�moire.

* Eviter de cr�er des hi�rarchies de classes de hauteur trop profonde. Au-dela de 4 niveaux, il faut commencer � se poser des questions et chercher � "�taler" une hi�rarchie horizontalement. L'accumulation des constructeurs et des destructeurs finit par tuer les performances (voir les librairies java), sans parler de la gestion des exceptions qui peut devenir rapidement probl�matique. En g�n�ral, faire des hi�rarchies compliqu�es n'est pas bon signe en OO, -en C++ en tout cas-.

Excellent, tout le monde devrait suivre ce conseil.

L'utilisation de classes param�tr�es (class templates), peut parfois aider. Mais attention � ne pas en abuser, car les templates ne remplacent pas les classes : pas de hi�rarchie possible, et le code devient vite illisible, donc une bonne r�gle � respecter est qu'il faut ne les utiliser qu'avec les types de base en param�tre (int, char, float, boo et int*, char*, float*, bool*l).

Et profiler, profiler, bien �videmment.

ps : l'optimisation du code ne doit pas �tre une excuse pour ne pas utiliser les techniques connues pour am�liorer la robustesse du code, comme les auto_ptr, l'usage de const, des classes stack-based, etc.

Il n'est pas toujours possible de profiler, notamment quand le code est embarqu�, que le seul profiler possible est un profiler ICE qui co�te plusieur milliers d'euro.

Non, il est plus rentable parfois de g�n�rer le code en assembleur, et de calculer les temps d'ex�cution � partir de l'assembleur. ( Tr�s long et tr�s fastidfieux.)

[Matthieu Brucher]

je veux savoir comment le parcours d'un tableau a l'aide de pointeur est plus rapide qu'un int i;
merci

L'explication est donn�e un peu plus haut dans le topic.

Pour la liste de LeGreg, le point 3. Les const, j'en use �norm�ment dans le code que je dois impl�menter pour du calcul matriciel. J'ai une classe de matrice, mais quand une op�ration d'addition cr�e une nouvelle matrice, il renvoie celle-ci, donc impossible d'utiliser le passage par r�f�rence dans mon code si je veux pouvoir faire des calculs comme avec des entiers. Cela fait que les const sont super pratiques car pass�s avec un argument ou comme effet de la m�thode, �a indique au compilateur qu'il n'aura pas besoin de cr�er un nouvel objet. Ensuite, � lui de voir s'il va effectivement se passer du constructeur ou pas.

[lepoutho]

++ i est plus rapide que i++
idem pour -- i a la place de i--

Cordialement

[lepoutho]

parcours d'une chaine
char * chaine = "salut les copines";
char * pt = chaine;
while (* pt)
{

//ce que je dois faire .....


pt ++
}

[lepoutho]

utiliser l'operateur * plutot que l'op�rateur /

float toto = 2;
float titi = toto / 2 ;//pas terrible ...
float titi = toto * 0.5; //meilleur, plus rapide enfin c'est
//ce que je faisais avec de vieux compilo et je continue
//par habitude, mais je n'ai aucune certitude, a voir ...

[moldavi]

utiliser l'operateur * plutot que l'op�rateur /

float toto = 2;
float titi = toto / 2 ;//pas terrible ...
float titi = toto * 0.5; //meilleur, plus rapide enfin c'est
//ce que je faisais avec de vieux compilo et je continue
//par habitude, mais je n'ai aucune certitude, a voir ...

Je pense que les compilateurs actuels optimisent tout seul ce genre de calcul.
Ils peuvent m�me utiliser les registres sp�cialis�s en nombre � virgule. Mais c'est vrai que je n'ai pas personnellement v�rifi�, j'ai juste lu la documentation.