Discussion :

[jfloviou]

Bonjour � tous, je suis nouveau sur ce forum et suis � la recherche de tous les trucs et astuces du plus bateau au plus compliqu� pour un code plus efficace en vitesse de calcul: ex mieux vaut une boucle FOR ou l'usage du WHILE ? La pile est elle vraiment plus rapide que le tas?
l'usage de inline c'est mieux pour la vitesse?

et tous les autres...

Donc si vous connaissez des sites, ou des astuces, merci!

jaja

[loic.radio]

Bonjour,

Les astuces de bases les plus utiles :

- ne jamais utiliser de double ni de float si on peut faire autrement,
- utiliser les fonctions inline si possible,
- si tu as des calculs utilisant fr�quement des sinus, cosinus.. calcul les une fois et mets les dans un tableau index� ( ex au lieu de cos(12), calcul tout les cos jusqu'� 360 et mets-les dans un tableau double MonCos : cos(12) devient MonCos[12]).
- sauter dans les fichiers (utiliser ftell et fseek) au lieu de lire octet par octet.
- essayer d'avoir le moins de division et de multiplication possible.
- utiliser les d�calages plutot que les multiplication ou division si multiple de 2 : ex : x<<2 au lieu de x=x*2
- etc, etc,etc

[exxos]

pour ce qui est des float, je crois que maintenant avec les new processeurs c aussi bien gere que des int. mais bon a voir ....

pour ce qui est des parcours des tab, il vaut mieux des pointeurs mobile:
de meme, il vaut mieux comparer qqch avec qqch du registre (ici le 0), voir meme 2 choses du registre entre eux:

ex:

Code :

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

1
2
3
4
int tab[50000];
for(int i(0);i<50000;i++){
//qqch a faire
}

remplacer par:

Code :

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

1
2
3
4
5
6
int tab[50000];
int * ptr=tab;
register int i=50000;
while (i--){
//qqch a faire
}

[Musaran]

Je suis tomb� sur ce vieux topic au hasard d'une recherche...
Et je le remonte sans honte !


Commentaires:
Ne pas remplacer une division (par une puissance de 2) par un d�calage !
Le compilateur sait tr�s bien le faire.
Et puis �a ne marche pas sur les nombres n�gatifs.

register est un voeu pieu... L� aussi, le compilateur sait tr�s bien d�cider tout seul.

inline est pareil...
Attention � ne pas forcer, l'augmentation de taille du code pourrait annuler le gain des appels de fonctions �vit�s.


Conseils:
Attention, tout ceci est � comprendre 'dans la mesure du raisonnable'.

-prendre un bon compilateur ! Lui faire confiance pour les optimisations de base.

-utiliser des librairies efficaces !

-simplifier les expressions.

-avoir une structure de programme efficace.

-mesurer les performances, se concentrer sur les 20% de codes consommant 80% du temps. Typiquement les boucles imbriqu�es.

-pr�f�rer les entiers aux flottants.

-pr�f�rer le type int, c'est quasiment par d�finition le plus rapidement manipul� par le processeur.

-sp�cifier const tout ce qui peut l'�tre. Si �a bouge pas, pas besoin d'aller y voir..

-�viter les op�rations d'�criture.

-mettre des assert dans le code. En plus de capturer des bogues, certains compilateurs savent s'en servir comme indices d'optimisation.

Code :

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

1
2
3
signed int i= ...;
assert(i>0);
...=i/4; //bien que signé, i est positif, et /4 est remplacé par >>2.

-�viter les appels syst�mes. Ils engendrent un changement d'�tat du processeur qui consomme une centaine de cycles d'horloge...

-�viter les E/S, surtout les acc�s disques.

-g�rer un tampon avec les E/S lentes. fopen au lieu de open par exemple.

-�viter les branchements, ils impliquent un "jump" au niveau processeur, ce qui nuit aux encha�nements de traitements.
Les boucles(for et (do)while) impliquent une condition � chaque it�ration. do...while fait un branchement de moins � la fin.
Une condition (if/else et ?:) implique un branchement. if sans else n'a de branchement que si faux.
Le branchement goto nuit � la compr�hension qu'� le complilateur de votre code.
Si vous l'utilisez quand m�me, sachez que les accolades travers�es engendrent des lib�rations/allocations/initialisations sur la pile, donc c'est plus qu'un simple "jump" processeur.

-mettre la moit� la plus fr�quente du if-else c�t�... je sais plus !

-d�rouler les boucles. Euh... non! Le compilateur s'en charge.

-�viter les appels de fonctions. En plus du double saut aller-retour, il y a des sauvegardes de registres.

-manier les compteurs de max vers 0. Car les comparaisons avec 0 sont plus rapides.

-utiliser des pointeurs mobiles plutot que des indices.

Code :

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

1
2
3
4
5
p++ ; //1 addition
*p  ; //1 déréférencement
 
i++ ; //1 incrémentation
t[i]; //*(t+i) 1 multiplication, 1 addition, 1 déréférencement

-ne pas copier inutilement les donn�es. Traitements sur les cha�nes par exemple...

-pr�-calculer ce qui peut l'�tre.

-�viter les allocations dynamiques.

-ne pas confondre nombre de lignes de source et taille du code compil�.

-ne pas faire de choses inutiles. C'est �vident...

-cherchez la localit� de r�f�rence.
�a veut dire faire des acc�s sur les m�mes donn�es (ou adjacentes) � peu d'intervalle.
Pour b�n�ficier � plein des caches processeur, carte m�re, m�moire, syst�me, disque, ect...

Code :

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

1
2
3
4
5
6
7
int tab[X][Y];
for(y=0;y<Y;y++)
	for(x=0;x<X;x++)
		tab[x][y]; //mauvais, x varies le plus vite
for(x=0;x<X;x++)
	for(y=0;y<Y;y++)
		tab[x][y]; //bon, c'est la dernière dimension dont les cellules sont adjacentes en mémoire

-faire des acc�s lin�aires. Car les caches pr�-chargent les donn�es adjacentes.


C'est tout pour cette fois, mais il y en aura s�rement d'autres...

[gl]

Penser dans les options de compilation a parametrer le compilateur en 'optimisation de temps d'execution'

[shef]

Et surtout bencher r�guli�rement son appli au fur et � mesure des potimisations, pour se rendre compte de leur effet (ou de la d�gradation)

[fd]

...et generer le code assembleur pour l'optimiser eventuellement (je parle de l'optimiser en C/C++ et pas taper ds l'asm directement bien entendu)

[olivic]

Et faire des vrais algo. J'ai vu un prog avec un trie bulle pour tri� un tableau avec � cot� des d�callage binaire partout.

Quand je vois des personnes qui cr��s des class existante (liste chain� par ex) je suis persuad� qu'elles sont moins efficace que la STL.

[Pazz]

> olivic : pas d'accord avec toi. Tu peux faire une liste bien chain�e bien plus efficace que celle de la STL, par contre elle n'aura pas la m�me robustesse.

Avantages de la STL : efficacit� connue mais pas forc�ment optimale (mais toujours correcte), et surtout utilisable dans toutes conditions, tous les cas ont �t� pens�s.

Mais si c pour un cas particulier tu peux faire bien plus rapide.

[Musaran]

Choisir comme option d'appel par d�faut des fonctions "fastcall".

Le standard est "stdcall" il me semble, c'est l'appelant de la fonction qui nettoie les arguments pass�s.

�a doit bien faire... oh... 3 octets de perdus par appel de fonction, c'est intol�rable !

[LeGreg]

- ne jamais utiliser de double ni de float si on peut faire autrement,

Vous pouvez utilisez les float tant que vous voulez surtout que le besoin s'en fait sentir avec l'informatique moderne.
Par contre, vous devriez limiter les conversions float -> int -> float.
Limitez l'utilisation du fmod a ce qui est necessaire.
Sinon les multiplications, additions, soustractions de float sont assez rapides sur les processeurs > pentium. ce ne sera pas le facteur limitant si tu es oblig� de faire du code compliqu� pour compenser l'absence du float.

- si tu as des calculs utilisant fr�quement des sinus, cosinus.. calcul les une fois et mets les dans un tableau index� ( ex au lieu de cos(12), calcul tout les cos jusqu'� 360 et mets-les dans un tableau double MonCos : cos(12) devient MonCos[12]).

Gain non garanti pour des raisons d'etranglement sur l'acces � la lookup table alors que les processeurs incluent une instruction de calcul du cosinus. A n'utiliser que pour des processeurs limit�s en virgule flottante (proc embarqu�s) et meme la ca peut etre parfois plus rapide et aussi efficace de faire le calcul par approximation.

- essayer d'avoir le moins de division et de multiplication possible.

Beaucoup plus vrai pour les divisions que pour les multiplications qui sont assez rapides. Notez que diviser par X revient a multiplier par 1/X mais c'est un truc de base, il paraitrait meme que des compilateurs l'optimisent (quand il s'agit de constantes).

Ne pas remplacer une division (par une puissance de 2) par un d�calage !Le compilateur sait tr�s bien le faire.
Et puis �a ne marche pas sur les nombres n�gatifs.

moi j'aime bien generer des puissances de deux par un 2^n = 1 << n;
Sinon la puissance de deux en binaire a une propriete interessante
on peut calculer son modulo par un & (2^n-1)
et on peut l'arrondir a la puissance de deux voulue par l'op�ration complementaire & ~(2^n-1).
Ca ne sert presque a rien. Enfin de toute facon ce genre d'optimisation vous le ferez apr�s la touche finale si jamais ca a une importance quelconque.

inline est pareil...
Attention � ne pas forcer, l'augmentation de taille du code pourrait annuler le gain des appels de fonctions �vit�s.

Si vous pensez qu'une methode peut-etre inline, pensez a la mettre
dans le fichier header de votre classe, sinon le compilo ne saura pas ou trouver le corps de la fonction pour l'inliner. (certains ont un fichier header qu'ils appellent machin.inl pour sp�cifier qu'il contient les d�finitions des fonctions inlinables)

-prendre un bon compilateur ! Lui faire confiance pour les optimisations de base.

C'est lesquels les mauvais compilateurs?
perso j'utilise MSVC++, c'est bien suffisant
pour ce que je fais.

-avoir une structure de programme efficace.

Oui avant de chercher a gagner des cycles sur une boucle
voir si l'algo qui prend une heure ne peut pas etre ramen�
a un algo qui prend une minute par analyse du probleme.

-pr�f�rer les entiers aux flottants.

cf ma remarque ci dessus

-pr�f�rer le type int, c'est quasiment par d�finition le plus rapidement manipul� par le processeur.

Ca veut dire que bool ne peut pas etre manipul� rapidement par le proc?
L'important c'est tout de meme la proprete des types manipul�s par le programme, le compilateur fait sa sauce derriere pour arranger ca au mieux.

-sp�cifier const tout ce qui peut l'�tre. Si �a bouge pas, pas besoin d'aller y voir..

Je ne crois pas que le compilateur optimisera tres souvent sur const.
Par contre un code peut-etre optimis� pour du const-specific
exemple: surcharge d'une methode const sur une string qui renvoie un char plutot qu'une reference vers un char.

-�viter les op�rations d'�criture.

??

-ne pas faire de choses inutiles. C'est �vident...

Ah tu veux dire, eviter de mettre des noop au milieu du code?

[snip] (je coupe)

Ca fait tout de meme beaucoup de regles dont certaines ont un interet qui est soit tres faible soit risquent d'etre mal interpret�es.

LeGreg

[Pazz]

ne jamais utiliser de double ni de float si on peut faire autrement,

� noter que sur les Pentium IV, ALU et FPU peuvent fonctionner simultan�ment.

Donc si tu as besoin de faire 20% d'op sur des floats et 80% sur des entiers, tu lances une op sur float, 4 sur entiers, une sur float, 4 sur entiers etc.

Bon �videmment c plus facile � faire en asm qu'en C++ mais on voit quand m�me la diff�rence.

Je ne sais pas si certains compilo r�alisent cette optimisation pour l'instant sp�cifique � un CPU.

[haypo]

Je suis p't�tre HS, mais je veux quand m�me faire part de ma pens�e : je me concentre sur la qualit� du code, le rendre portable, bien optimiser les algorithmes. L'optimisation en elle-m�me : compilateur s'en charge :-)

En jouant avec les "petites" optimisations : d�calages binaires, utiliser int plut�t que float, etc., on gagne des performances, c'est s�r, mais �a rend le code moins compr�hensible et donc plus difficile � maintenir et d�boguer ...

Un changement d'algorithme par contre permet des gains �norme de performances ! On passant d'une liste simplement cha�n�e � une liste doublement cha�n�e je passe d'un calcul de 3.5 secondes � 20 millisecondes !!! Simplement car effacer un �l�ment dans une liste cha�n�e demande � conna�tre l'�l�ment pr�c�dent, il faut donc parcourir la liste ... quand tu as 1 million d'�l�ment, �a prend le temps qu'il faut :-)

Par contre j'ai un faible pour le mot cl� "const".

On m'a d'ailleurs dit qu'il fallait plut�t utiliser "const int cst_x = 4;" que "#define cst_x (4)". Je doute. Mon probl�me est surtout de placer des "const type var=valeur;" dans un fichier .H ... "Impossible de pr�compiler l'ent�te car il contient du code" :-( Et si je mets un "extern" devant, et que je le d�clare avec sa valeur dans le .CPP ... Ca marche pas, il me dit que la variable n'est pas d�finit ou je ne sais pas quoi :-/

@+ Haypo

[LeGreg]

Un changement d'algorithme par contre permet des gains �norme de performances ! On passant d'une liste simplement cha�n�e � une liste doublement cha�n�e je passe d'un calcul de 3.5 secondes � 20 millisecondes !!! Simplement car effacer un �l�ment dans une liste cha�n�e demande � conna�tre l'�l�ment pr�c�dent, il faut donc parcourir la liste ... quand tu as 1 million d'�l�ment, �a prend le temps qu'il faut :-)

Oui le meilleur moyen de faire du code rapide
c'est de faire une analyse du probleme et d'en d�duire
la structure de donn�e la moins mauvaise � utiliser.

Donc conseil au programmeur d�butant: n'apprend pas de quel cot� du if il faut mettre le bloc le plus probable, cela te donnera une fausse id�e que tu maitrises la machine. Par contre prend des cours d'algorithmique de base ou lis un bouquin (style introduction a l'algorithmique de Thomas Cormen).

On m'a d'ailleurs dit qu'il fallait plut�t utiliser "const int cst_x = 4;" que "#define cst_x (4)". Je doute. Mon probl�me est surtout de placer des "const type var=valeur;" dans un fichier .H ... "Impossible de pr�compiler l'ent�te car il contient du code" :-( Et si je mets un "extern" devant, et que je le d�clare avec sa valeur dans le .CPP ... Ca marche pas, il me dit que la variable n'est pas d�finit ou je ne sais pas quoi :-/

Entre les const et les define c'est un peu la guerre.
Par contre ce qui est sur c'est qu'on peut toujours remplacer
une suite de define par un type enum. C'est une maniere de typer plus fortement un entier, et en plus une
variable de type enum apparaitra sous son nom propre dans
le debogueur, ce qui peut etre un gain de temps.

Pour ce qui est de la d�finition des constantes globales:

Code :

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

extern const type mavar; // dans le .h

et

Code :

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

const type mavar = .. ; // dans le cpp

normalement ca marche.
Quel est ton code et quel est ton message d'erreur? (a la compilation ou lors de l'�dition de liens?)

LeGreg

[Pazz]

bien d'accord avec vous, ce qui prime c avant tout la structure de donn�e et l'algo, et seulement ensuite l'impl�mentation.

Mais c plus compliqu� � expliquer dans le forum

[Musaran]

moi j'aime bien generer des puissances de deux par un 2^n = 1 << n;

Moi aussi. Mais cela implique:

Supposition 1) << et >> signifient d�clage vers le poids fort/faible.
Les explications que je lis parlent juste de gauche/droite.
L'effet serait invers� avec le "boutisme" de bits oppos� ?

Supposition 2) Les nombres sont repr�sent�s en syst�me de base partant de 0, ou arabe, je ne sais pas trop comment on dit.
Il existe d'autres repr�sentations, certes moins courantes: d�cimal cod� binaire, fibonacci, biais�...

Supposition 3) Les nombres sont repr�sent�s en base 2 (binaire).
En base n, ce serait multiplier/diviser par n.

Des suppositions l�g�res, mais des suppositions quand m�me.

Nota: il est vrai que mon manuel dit que <<1 revient � *2.

C'est lesquels les mauvais compilateurs?

Je ne sais pas...
Mais le jour o� j'ai besoin que mon ex�cutable soit effectivement performant, la premi�re chose que je fais, c'est de me renseigner l�-dessus.

-pr�f�rer le type int, c'est quasiment par d�finition le plus rapidement manipul� par le processeur.

Ca veut dire que bool ne peut pas etre manipul� rapidement par le proc?
L'important c'est tout de meme la proprete des types manipul�s par le programme, le compilateur fait sa sauce derriere pour arranger ca au mieux.

Je veux dire:
Si le type n'est pas soumis � une contrainte particuli�re, comme initialis� par tel autre type, pass� a une fonction, surpasser ou pas, avoir des d�cimales, �tre sign� ou pas...
...alors, il faut prendre int.
Prendre un type plus petit en se disant "il prends moins de place en m�moire, j'y gagne" risque surtout de forcer le compilateur � g�n�rer du code suppl�mentaire, ou � utiliser des instructions processeur anciennes pour y acc�der conform�ment au code �crit.

int est par d�finition de la taille que le processeur manipule le mieux (mais au moins 32 bits dans les derni�res normes).
En interne, les types <int sont plac�s dans un espace d'un int, le compilateur sait ce qu'il fait.

Je ne crois pas que le compilateur optimisera tres souvent sur const.

Je crois l'inverse.
Je crois m�me qu'il traque ce qui est const sans l'avoir �t� d�clar�.
Mais de toutes fa�on, il vaudrais mieux savoir que croire.

-�viter les op�rations d'�criture.

??

J'ai �t� un peu bref, l�...
Je veux dire qu'une �criture, que ce soit en m�moire ou sur disque ou autre, est typiquement plus longue qu'une lecture.
�a peut �tre int�ressant de travailler sur une valeur temporaire, et de n'�crire le r�sultat qu'une fois.

Ca fait tout de meme beaucoup de regles dont certaines ont un interet qui est soit tres faible soit risquent d'etre mal interpret�es.

Oui...
Toutes les expliquer en d�tail serait trop long.
Mais je pr�f�res les donner que de les taire.
Ceux qui sont int�ress�s doivent se documenter pour bien comprendre, c'est clair...

Une optimisation mal faite peut �tre pire que le code non-optimis� !

[Musaran]

En C, on ne peut pas partager les variables constantes par un header comme en C++.
Chaque source cr�e sa propre constante.

Et si on utilises extern, la constante n'est pas connue � la compilation, ce qui permet moins d'optimisations (le C++ est �galement concern�).

Par contre, on peut substituer des enums pour les entiers int:

Code :

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

enum{Maconst=5};

[Musaran]

Plut�t que de faire malloc/free dans un bloc pour une broutille...
...utiliser alloca, la m�moire est allou�e sur la pile et automatiquement lib�r�e � la sortie de bloc.

Toutefois:
-ce n'est pas standard.
-la pile n'est faites que pour quelques m�gas maximum.

[LeGreg]

<< et >> signifient d�clage vers le poids fort/faible.
Les explications que je lis parlent justent de gauche/droite.
L'effet serait invers� avec le "boutisme" de bits oppos� ?

Bien sur que non! on parle de representation binaire du nombre
et non pas de sa representation en memoire (ou sur disque).

Supposition 2) Les nombres sont repr�sent�s en syst�me de base partant de 0, ou arabe, je ne sais pas trop comment on dit.
Il existe d'autres repr�sentations, certes moins courantes: d�cimal cod� binaire, fibonacci, biais�...

les operateurs binaires operent sur les representations binaires
des nombres. Point.

Je crois l'inverse.
Je crois m�me qu'il traque ce qui est const sans l'avoir �t� d�clar�.
Mais de toutes fa�on, il vaudrais mieux savoir que croire.

Non tu crois probablement la meme chose que moi . Mais optimiser ce qui est effectivement "const" dans une expression, n'est pas ce que j'appelle moi optimiser sur le mot-cl� "const".
(exemple classique : fonction(objet&, const objet &)..)

un article qui etaie ce que j'essaie d'expliquer tant bien que mal
http://www.gotw.ca/gotw/081.htm

LeGreg

[gl]

Supposition 2) Les nombres sont repr�sent�s en syst�me de base partant de 0, ou arabe, je ne sais pas trop comment on dit.
Il existe d'autres repr�sentations, certes moins courantes: d�cimal cod� binaire, fibonacci, biais�...

les operateurs binaires operent sur les representations binaires
des nombres. Point.

Non, Musaran a raison, vous ne parlais pas de la meme chose, toi tu parle de la base, lui de la representation.
En effet un nombre peut etre coder classiquement, c'est a dire qu'il est converti dans la base, ainsi en 10 decimal s'ecrit 0000 1010 en binaire et la effectivement >> et << corresponde nt a des multiplicationdivision par puissance de 2.

Maintenant un nombre peut aussi etre representer en BCD (binaire code decimal), 10 en decimal devient alors 0001 0000 et du coup << et >> pour mulitplier/diviser par 2 ne fonction plus. Pourtant on travaille dans les deux cas avec des operateur binaires.

En resume le binaire, decimal, hexadecimal, ... ne sont que de bases et quelque soit la base, le comportement et la valeur d'un nombre ne varie pas.

La numerotation classique, le BCD, ... sont des representations qui influe sur les proprietes du nombre