Ce post est une sorte de "repertoire" des astuces et conseils pour optimiser la vitesse de vos programmes.
Vous pouvez aussi proposer vos astuces.

Les astuces :

- Utiliser des fonctions inline, bien que le compilateur decide si la fonction sera inline ou non.
- Utiliser les boucles de facon intelligentes.
- Eviter les divisions, preferer les rotations de bits.
- Utiliser les float en dernier recours.
- Preferer l'utilisation de tableau de fonction plutot qu'un switch si possible.

switch(condition)
{
case 1: someFunction1(); break;
...
case n: someFunctionn(); break;
}

est a remplacer par :

typedef type (*p)(...);
p tab[n] = {someFunction1,...,someFunctionn};
tab[condition](...);

- Utiliser des variables constantes le plus souvent possible bien que le compilateur essaye de le faire pour vous.
- Bien choisir le compilateur et bien le connaitre (option de compilation...).
- Eviter l'allocation dynamique - Seulement pour certains cas bien precis ou une optimisation tres pousse.
- Utiliser des variables register pour des variables utiliser tres souvent ou pour des calculs intensifs - Attention a ne pas en abuser ca peut vous couter chere.
- Attente de la verification d'un specialiste : Utiliser l'asm en ligne pour des algorithmes couteux et peu optimiser lors de la compilation.

EDIT : Conseil de Davidbrcz pris en compte.

Je vous laisse ajouter vos astuces a la suite du post et je les ajouterais avec votre nom.

- ne pas abuser des fonctions inline

- utiliser les boucles intelligemment

- utiliser std::vector au lieu d'un bête tableau à la C (plus rapide - pas seulement à l'écriture du code)

- utiliser l'allocation dynamique

- rendre son code lisible - cela inclus l'indentation, le nom des variables/classes, les commentaires, etc

- bien choisir son IDE - à jour - et bien le connaitre - un minimum, quoi

Quand vous passez un objet qui ne doit pas être modifié à une fonction, passez le par référence constante.
Cela évitera de copier inutilement un objet.

Exemple:

void fonction(const std::vector<int>& vec) { 
// code 
}

Au lieu de:

void fonction(const std::vector<int> vec) { 
// code 
}

[Uniquement si votre vecteur n'est pas modifié.]

Si vous voulez accélérer votre programme, n'écoutez pas les conseils du P.O. Ni du 2ème post. Enfin, lisez plutôt un article sur des sujets méritant des optimisations plutôt que de lire ces posts.

Citation : Pas de titre

- Utiliser des fonctions inline

inline n'est qu'une indication au compilateur. au final c'est lui qui décide.

Citation : Pas de titre

- Eviter d'utiliser des boucles

Référence, tests et/ou benchs ?

Citation : Pas de titre

- Eviter les divisions

Ca dépend de comment tu fait tes divisions. A coup de rotation de bit, c'est super rapide.

Citation : Pas de titre

- Preferer l'utilisation de tableau de fonction plutot que des conditions si possible.

Le code montré ne marche que pour des switch. Avec des conditions plus complexes, ca marche plus.

Citation : Pas de titre

- Utiliser l'asm en ligne pour des algorithmes couteux et peu optimiser lors de la compilation.

Sert à rien. Tu ne battra JAMAIS ton compilateur à ce jeu là.

Citation : Pas de titre

- Bien choisir le compilateur et bien le connaitre.

Avant d'incriminer le compilateur, regarde les algos choisis ainsi que les structures de données utilisées.

Citation : Pas de titre

- Eviter l'allocation dynamique.

Comment on fait pour utiliser des structure de données dynamique ? Le polymorphisme, il passe où ? De plus, ta des benchs / test ou autre ?

Citation : Pas de titre

- ne pas abuser des fonctions inline

Cf avant

Citation : Pas de titre

- utiliser std::vector au lieu d'un bête tableau à la C (plus rapide - pas seulement à l'écriture du code)

Un std::vector serra un poil plus lent qu'un tableau brut, mais la puissance à un prix.

Citation : Pas de titre

- bien choisir son IDE - à jour - et bien le connaitre - un minimum, quoi

Ca c'est une question de productivité, pas de vitesse de code.

PS: un débat un poil plus fournit qu'ici http://www.developpez.net/forums/showthread.php?t=39
PS2: +1 Alp.

Pour tout ce que j'ai dit j'ai verifier en faisant quelques recherche sur google. Quant au compilateur je veux parler des options de compilation. Pour l'alloc dynamique cf le lien de developpez il y a toute un debat dessus, donc apres ce ne sont que des avis personnels, certain diront que c'est faux d'autres diront l'inverse.
Dans certain cas tu peux battre le compilateur en ASM il suffit de regarder l'output du compilateur.

Pour le reste je vais specifier ce que tu as dis.

Il faudrait faire un 2e sujet avec les infos "officielles", comme avec le topic des mots clés du C++, parce que si c'est pour ne pas se mettre d'accord...

Tu balances des phrases comme ça. Certaines de tes "astuces" peuvent devenir véridiques dans un contexte bien précis. Du genre "Evitez l'allocation dynamique là où une instance statique se comporte de manière identique".

Par contre, j'aurais bien suggéré d'utiliser les smart pointers dans les astuces, par exemple.

Je ne vais pas non plus me taper chacun de tes arguments un à un. Ni ceux du 2ème post. Y'a les livres de Meyers et Sutter entre autres pour ça. Et le GOTW.

Aïe aïe aïe...

Un la chose la plus importante de toutes à savoir :

Citation : Michael A. Jackson

The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.

Deux, vive le NIH (http://www.developpez.net/forums/showthread.php?t=39) De grosses bétises ont également été dites, mais elles furent contredites.


Ensuite, l'histoire des boucles, c'est nawak'. Si tu as besoin de recommencer un traitement, c'est que tu as besoin d'une boucle. J'imagine que tu voulais faire allusion au déroulage des boucles ... et bien, c'est le rôle du compilo.

Exactement comme pour les divisions, les compilos sont assez grands (depuis quelques temps déjà) pour savoir remplacer une division par une constante par décalages et autres additions qui vont bien.

Pour les vecteurs, on ne peut pas dire qu'ils sont plus lents ou plus rapides que les tableaux dynamiques. Cela dépend de comment on s'en sert.

Concernant l'ASM, dans l'absolu on pourrait probablement le battre, mais cela demanderait une connaissance excessivement précise des divers niveaux de caches de ta machine (en particulier, et de nulle nulle autre), de ses éventuelles instructions "étendues", du fonctionnement du pipeline (et de sa taille), de comment les interactions entre les coeurs se passent, ...
Autant le dire tout de suite : vous n'avez aucune chance de faire mieux. Il y a 10 ans, ou sur de l'embarqué, je ne dis pas.

Citation : yamashi

Pour tout ce que j'ai dit j'ai verifier en faisant quelques recherche sur google.

Lesquels ? Quels sont tes références ? Car c'est beau de dire qu'on trouve des trucs sur google, mais le net n'est pas toujours fiable, loin de là.

Citation : Pas de titre

Quant au compilateur je veux parler des options de compilation.

Toute personne un minimum sérieuse a moins lu le man de son compilateur, j'ai presque envie de dire que ca va de soi

Citation : Pas de titre

Pour l'alloc dynamique cf le lien de developpez il y a toute un debat dessus,
donc apres ce ne sont que des avis personnels, certain diront que c'est faux d'autres diront l'inverse.

Topic ? (même si c'est vrai que l'allocation dynamique ralenti un poil à cause des indirections)

Citation : Pas de titre

Dans certain cas tu peux battre le compilateur en ASM il suffit de regarder l'output du compilateur.

Disons que c'est faux dans 99,99% des cas (on atteind 100% en se basant sur les topics d'ici)

Citation : Pas de titre

Pour le reste je vais specifier ce que tu as dis.

Avec plaisir.

Un élément important en C++ aujourd'hui c'est que beaucoup de bibliothèques se développent à droite à gauche.

Regardez dans des bibliothèques un minimum reconnues s'il n'y a pas ce dont vous avez besoin. Je pense notamment à Boost bien sûr qui fournit énormément de choses qui sont probablement mieux programmées que vous ne pourriez le faire dans les 10 ans à venir, au moins. Bien sûr selon les cas il y a mieux mais en attendant d'avoir justement _besoin_ de mieux, regardez de ce côté là.

Voici un lien que je viens de trouver qui supporte ce que j'avance sur l'utilisation des pointeurs, des divisions et des float pour lesquels je n'etais pas sur.
Sinon je viens de faire un bench sur l'utilisation de variable register que j'ai trouve sur ce site : (http://www.java2s.com/Code/C/Data-Type/Registervariablefaster.htm) et resultat les variables register sont bien plus rapide que les variables non register.
Maintenant si les specialistes ont un contre argument a fournir avant que je l'affiche je suis a l'ecoute.
EDIT : un autre lien sur l'allocation dyamique.

Ta référence sur les pointeurs lent donne un coût relatif de 2 (avec un minimum à 1) ! Ce qui est négligeable !

Après pour les variables register (instruction qui dit au CPU de garder cette variable dans le cache si possible), c'est normal que ca soit plus rapide car le cache est par définition bien plus rapide (de l'ordre de 10 fois) que la RAM.

Mais c'est extrêmement rare de l'utiliser et que son utilisation se doit être réfléchie et justifié par des tests. lmghs, en 10 ans, tu la utilisé combien de fois cette instruction ?

Edit: pour le lien sur l'allocation dynamique, le site est consacré à la prog sur de l'embarqué !!! Ce qui fausse forcément le jugement !!

Ca rejoint la remarque d'Alp, certains conseils ne sont vrai que dans certains cas. Celui ci est vrai dans l'embarqué, pas du tout ailleurs.

Le liens montre que l'utilisation de new et delete ont un cout relatif a 800 ce qui n'est pas negligable.

Tu déconseille l'allocation dynamique pour les mauvaises raisons...

C'est à éviter car on a un pointeur que l'on peut oublier de libérer ou pire tenter de libérer 2 fois.

Mais le coût d'un new comparé à une construction statique... faut arrêter là... Ca ne fera que réserver la mémoire et y placer l'objet dans 2 endroits différents selon le cas... L'avantage de new et que tu peux récupérer un bad_alloc au lieu de te taper un segfault si plus de mémoire.

Voyons ce que disent les gurus ...
register: http://groups.google.fr/group/comp.lang.c++.moderated/browse_thread/thread/d36e7b29c24cd6f4/1d7992147f2721b3?lnk=st&q=#1d7992147f2721b3

division: http://groups.google.fr/group/fr.comp.lang.c++/browse_thread/thread/39ae3ff29781a616/fbe8249dde6f1372?lnk=st&q=division+group%3Afr.comp.lang.c%2B%2B+optimisation#fbe8249dde6f1372

switch: http://groups.google.fr/group/fr.comp.lang.c++/browse_thread/thread/7981d9971b36a633/f3feae353f876abf?lnk=st&q=group%3Afr.comp.lang.c%2B%2B+optimisation+switch+table#f3feae353f876abf et http://groups.google.fr/group/comp.lang.c++.moderated/browse_thread/thread/e3fb3e2648dbeb82/46555d0e4d3c6c51?lnk=st&q=group%3Acomp.lang.c%2B%2B.moderated+optimisation+switch+table#46555d0e4d3c6c51

const: http://groups.google.fr/group/comp.lang.c++.moderated/browse_thread/thread/1573c05026c9147/9642e1f46bceb159?lnk=st&q=group%3Acomp.lang.c%2B%2B.moderated+optimisation+const#9642e1f46bceb159

L'alloc dynamique est plus lente que pas d'alloc, c'est sûr. Rien de nouveau de ce côté là. Quand il y en a besoin, il y a rarement le choix. Quand on n'en a pas besoin, la sortir est idiot. Pas pour des raisons de perfs. Mais pour des raisons de robustesse ; si on ne pouvait rien créer sur la pile, le RAII n'existerait pas. Quant au monde de l'embarqué, il est assez particulier.
Accessoirement, les pools de mémoire, c'est bien. Et sans aller jusque là, un std::vector::resize() suffit amplement.



Dans tous les cas -> TR18015


@david. "register" ? Hum .. au tout début (de ma pratique du C++), quand j'étais jeune et croyais tout savoir, j'essayais de m'en servir. Pour un même code compilé sur solaris comme VC6 -- c'est dire l'idiotie de la chose. Blitz++ n'était pas encore fini, et il était encore moins utilisable sur VC6.
Depuis j'ai bien percuté les règles 1 et 2 de l'optimisation. Puis je m'attache aux algos. Ce qui ne m'empêche pas d'éviter les pessimisations qui ne mangent pas de pain (passage de paramètre, test anti auto-affectation (qui est une pessimisation, et non une optimisation !!), ...)
Aujourd'hui je ne fais rien d'exceptionnel, et mon composant à contraintes temps-réel non négligeables tient les perfs exigées, et avec une bonne marge -- un banal routeur de télémétrie.

Agreed with Alp & Davidbrcz.

Les optimisations les plus importantes se font au niveau des algos et des structures de données choisis.

À trop vouloir optimiser, on rend très rapidement son code illisible, difficile à maintenir, pas portable, voir faux. Préférez toujours un code clair à un code bourré de hacks dont l'utilité sera souvent tout au mieux discutable.

La Vérité est là (enfin j'espère).

Comme dit plus haut, toutes ces optimisations n'apporteront pas énormément de gain. Le fait d'utiliser intelligemment ces boucles, d'utiliser des std::vector au lieu d'une allocation dynamique type C, d'éviter les divisions au maximum, utiliser des std::size_t quand il le faut pour éviter des casts inutiles, c'est quelque chose qu'on peut faire instantanément. Concernant toutes ces petites astuces, le lien qu'à donner altic est excellent (je mets le lien du pdf en question : http://www.agner.org/optimize/optimizing_cpp.pdf). Il donne énormément d'astuces sur des choses toutes bêtes qu'on peut ignorer et qui permettent d'écrire un code plus clair et légèrement plus efficace (parce que faut pas se leurrer, c'est pas un const par-ci ou un const par-là qui va transcender les performances de votre programme ^^). C'est plus des bonnes habitudes à prendre.

Après, le choix de l'algorithme est plus important, et aussi (mais là c'est plus compliqué et n'y ayant jamais touché je vais pas trop me prononcer), utiliser les instructions SSE. Dans certains cas ça apporte des gains phénoménaux !

L'utilisation de SSE est utile surtout en 3D et mathematique pour les calculs de vecteur. Dans un programme simple il est inutile d'utiliser ces instructions.

à méditer ...

Si c'est pour dire n'importe quoi abstient toi.
Je vais te sortir un programme, tu peux avoir 50TO de ram ca plantera quand meme...

dans 10 ans ...

Tu comprends pas l'utilite de ce topic.
Tu dois etre un debutant qui ne code pas de gros programme complex...
Hors les programmes que nous faisons sont tres important et parfois nous avons besoin d'une vitesse de calcul tres rapide, nous cherchons comment obtenir une vitesse optimal.

PS : Ne t'en fait pas pour nos machines, nous avons surement des machines dont tu n'imagines pas l'existance.

je suis un zero pas un pro ! mais je veut bien voir ton programme quand même !!!

ta machine je m'en moque qu'elle claque 34000 benchmark ca rend pas ton programme interressant ou utile pour autant

avec mes 13000 petit benchmarck je me sens suffisament à l'aise pour coder comme je le sens avec des variable de type double en permanence faire des boucle pour calculer des millions de choses inutiles et me faire plaisir en codant lisiblement.

mais je suis d'accord pour dire qu'il faut prendre des bonnes habitudes sait-on jamais défois que je code half-life 3 tous seul

je vous laisse tranquille...

bon codage !

valbou26, le problème c'est que tu essayes de parler de choses que tu maitrises encore moins que nous. Alors effectivement comme l'a dit yamashi, tu aurais dû t'abstenir.

valbou26, merci de ne pas venir pourrir le sujet en lançant des affirmations sans fondement. Si tu veux discuter et apprendre, pas de problème. Dans le cas contraire, merci de t'abstenir de poster.

ya pas de sujet! lancer des pseudo-informations alors que le lien est clair

http://www.developpez.net/forums/showthread.php?t=39

tourner autour du pot est tellement... constructif!

Si j'ai creer ce post c'est a l'origine pour aider a optimiser, mais aussi a pouvoir discuter du langage en lui meme avec d'autre programmeurs experimente. Personellement parler avec d'autres personnes qui ne sont pas du meme avis que moi me passione et vu que la programmation n'est pas une science excat car personne ne connais la totalite de chaque langage et meme d'un langage, il est interessant de pouvoir progresser en apprenant des autres a qui tu peux aussi apporter tes connaissances. Les forums sont fait pour ca.
Si on part dans ton sens on ira nul part car presque tout les sujets ont deja etait traite.
Mais l'optimisation n'est (je pense) pas encore un sujet completement traite.

Et oui tourner autour du pot est constructif dans certain cas.

Citation : Pas de titre

34000 benchmark

Si tu veux jouer a qui a la plus grosse. Ma machine a une puissance de 2.8Tflops, en benchmark je pense que ca depasse les 200 000. De plus c'est toi qui a lance l'idee des machines, nous n'en avons rien a faire, le probleme n'est pas la. Si on part dans ton sens, il suffit de regarder ce que ca donne : Crysis. Ce jeu est tellement peu optimiser que meme les dernieres machines ne le font pas tourner a des performances optimales. Alors que si celui-ci aurait ete optimise, il fonctionnerait sur des configuration moin importante, donc plus de ventes et par consequent plus de benefices. Pas tout le monde n'a les moyens de s'acheter le dernier AlienWare tout les 6 mois...

Disons que relancer le débat en listant des choses qui sont fausses ... bof bof.
[-> switch, division, const ; plus d'autres qui peuvent se retourner contre nous -> code-bloating qui fait sortir du cache avec l'abus d'inline (template généralement)]