Cela dit je rejoins les avis postés plus haut : dans l'ordre, pour optimiser un code de calcul, il faut
1. prendre le bon algorithme (avec la bibliothèque standard C++, prendre le bon conteneur)
2. mesurer ce qui prend vraiment du temps (sous Linux, perf est ton ami !)
3. optimiser, dans l'ordre selon moi :
- bien régler les cut-offs entre différents algorithmes (ex: un algo en O(n2) peut être bien plus rapide qu'un algo en O(n log n) pour les petits n ! Du coup si l'algo est récursif, les dernières étapes doivent se faire avec l'algo en O(n2) )
- savoir pourquoi ce qui prend du temps prend du temps (branch-misses ? recalculs incessants qu'on pourrait précalculer une bonne fois ? cache-misses ? etc. etc.)
- améliorer le code en fonction de l'étape précédente, notamment les structures de données : jouer avec les flags du compilateur genre O2, lto, march si on connaît le processeur cible, etc.
- faciliter la vectorisation (le compilateur le fait facilement si on lui tend un peu la main ! gcc a une option pour savoir pourquoi une boucle n'a pas été vectorisée le cas échéant)
- paralléliser (seulement une fois que le code est bien optimisé pour un cœur, car c'est sur un cœur que les gains sont les plus importants : avec plusieurs cœurs la concurrence pour les cache est beaucoup plus rude, sans compter les besoins en communication entre les cœurs ! ). C'est une étape parfois difficile si le code n'est pas un peu pensé pour au début, qui peut donc nécessiter pas mal de refactoring.
Si c'est du libre, n'hésite pas à donner un lien je pourrais jeter un œil éventuellement.
# Agner Fog
Posté par khivapia . En réponse au message Techniques d'optimisation C++. Évalué à 4. Dernière modification le 08 novembre 2014 à 16:13.
À l'adresse http://agner.org/optimize il propose un guide d'optimisation en C++.
Cela dit je rejoins les avis postés plus haut : dans l'ordre, pour optimiser un code de calcul, il faut
1. prendre le bon algorithme (avec la bibliothèque standard C++, prendre le bon conteneur)
2. mesurer ce qui prend vraiment du temps (sous Linux, perf est ton ami !)
3. optimiser, dans l'ordre selon moi :
- bien régler les cut-offs entre différents algorithmes (ex: un algo en O(n2) peut être bien plus rapide qu'un algo en O(n log n) pour les petits n ! Du coup si l'algo est récursif, les dernières étapes doivent se faire avec l'algo en O(n2) )
- savoir pourquoi ce qui prend du temps prend du temps (branch-misses ? recalculs incessants qu'on pourrait précalculer une bonne fois ? cache-misses ? etc. etc.)
- améliorer le code en fonction de l'étape précédente, notamment les structures de données : jouer avec les flags du compilateur genre O2, lto, march si on connaît le processeur cible, etc.
- faciliter la vectorisation (le compilateur le fait facilement si on lui tend un peu la main ! gcc a une option pour savoir pourquoi une boucle n'a pas été vectorisée le cas échéant)
- paralléliser (seulement une fois que le code est bien optimisé pour un cœur, car c'est sur un cœur que les gains sont les plus importants : avec plusieurs cœurs la concurrence pour les cache est beaucoup plus rude, sans compter les besoins en communication entre les cœurs ! ). C'est une étape parfois difficile si le code n'est pas un peu pensé pour au début, qui peut donc nécessiter pas mal de refactoring.
Si c'est du libre, n'hésite pas à donner un lien je pourrais jeter un œil éventuellement.