Version imprimable
Bonjour,
Je me demandais s'il était possible d'augmenter la vitesse d'exécution de mon programme. Plus précisément augmenter la vitesse de ma boucle.
Disons que:
Et est-il possible de voir la vitesse à laquelle un programme s'exécute (c'est peut être un peu vague...).Code:
2
3
4
Merci :)
Bonjour,
Il est assez simple de voir la vitesse : il suffit d'utiliser les fonctions de temps de la bibliothèque standard et de calculer la différence de temps entre deux tours de boucles.
Pour améliorer la vitesse de ton programme, il faut d'abord réduire la complexité de ton algorithme, rendre ton algorithme plus performant.
Ensuite, tu peux jouer sur la priorité de ton programme pour qu'il ai accès plus souvent au CPU.
Tu peux aussi sur certains OS (testé sur Debian squeeze ) utiliser une fois printf ce qui donnera un priorité légèrement plus élevée au thread courant.
Merci de pour ta réponse,
J'ai retrouvé ça pour calculer le temps d’exécution :http://www.developpez.net/forums/d79...n-prog-resolu/
Sinon pour ce qui est d'améliorer la vitesse, l'algorithme est vraiment basique.
Ensuite:
jouer sur la priorité de ton programme pour qu'il ai accès plus souvent au CPU.
Comment faire ? :weird:
Merci
Il faut regarder la commande "nice" et l'utiliser en root !
Et fais attention... un algorithme "vraiment basique" peut s'optimiser "dans la logique" si beaucoup de choses se répètent souvent...
La difficulté à optimiser peut par contre te faire t'arracher tes cheveux ! :P
Garde en tête aussi les optimisations "techniques" : faire le moins possible d'I/O !
vitesse DD <<< vitesse accès mémoire < vitesse CPU (registres, etc...)
- Moins tu fais de read/write, plus tu vas gagner de temps ! (si possible ne faire qu'un seul READ et un seul WRITE).
- Moins tu call de fonctions, moins tu perds de temps à empiler/dépiler des registres en mémoire... (voir le mot clé "inline" du C pour garder un code lisible et un ASM optimisé)
- Moins tu déréférences de pointeur, moins tu "sortiras" du CPU pour lire/écrire la mémoire.
EDIT : pour le déréférencement, c'est semi-vrai...
En effet, les caches L1/2/3 vont faire une partie du travail de lecture/écriture mémoire sans que tu ne leur demandes...
Mais pour qu'ils soient réellement efficaces : garder des tableaux contigus pour tes résultats...
Bonjour,
en plus de remarques de Neckara (qui d'ailleurs devait parler de complexité temporelle de l'algorithme plus que de la complexité de compréhension ...) je peux te conseiller d'utiliser un profiler. Le proiler est un outil intéressant qui, après une exécution de ton programme, te liste les endroits de ton source qui sont le plus consommateurs en temps. Ce sont les optimisation de ces endroits qui amélioreront le plus significativement les temps de réponses de ton programme. Chaque plateforme propose un profiler donc que tu sois sous windows linux ou mac tu devrais trouver ton bonheur.
Augmenter les priorités d'exécutions a ses limites, cela ne sert pas à grand chose si le goulet d'étranglement se situe au niveau d'un appel io par exemple, en revanche rajouter un mécanisme de cache pourrait dans ce cas être profitable (parfois).
Ou utiliser fread et fwrite qui ont un buffer pour limiter les opérations d'E/S.Citation:
Envoyé par Metalman
Attention, ce n'est pas tout à fait vrai.Citation:
Envoyé par Metalman
Déjà, il faut comme kwariz le souligne utiliser un profiler, selon ce qui est fait, l'appel de fonctions peut être négligeable en comparaison.
Par contre remplacer des algorithmes récursifs en itératifs peut être intéressant même si le compilateur peut "dérécursiver" (copyright Neckara pour ce mot :P) certains algorithmes réccursifs.
Ensuite, pour le mot clé inline, il faut se méfier, un inline sera un "copié-collé" de code et augmente la taille du programme, ce qui peut même provoquer des pertes de performances cf FAQ.
Attention aussi à l'ordre de parcours du tableau : tab[i][j][k] : d'abord parcourir en fonction des k, puis des j, puis des i ainsi on lira les éléments les un à la suite des autres.Citation:
Envoyé par Metalman
Sur de gros tableaux, parcourir d'abord les i nous fera lire les éléments de jmax*kmax en jmax*kmax, ce qui nécessitera des opérations supplémentaires au niveau du cache
@kwariz : oui, je parlais bien en complexité d'algorithme ( O(n), O(n²), ...)
@dashed : Je pense que kwariz t'as donné la meilleure réponse qui puisse t'être faite, utiliser un profiler.
L'optimisation prématurée est dangereuse, il faut d'abord identifier ses besoins en performances et voir quelles zones du code sont à optimiser plutôt que d'optimiser "au hasard".
Merci pour toutes vos réponses, je vais m'orienter vers le profiler. :)
Je viens de m'apercevoir qu'on a oublier une chose importante :
compiler en release avec l'option -O3, ceci permettra au compilateur de faire plusieurs optimisations.
D'accord, merci beaucoup. :)
Euuuh... ça copie/colle aussi un peu de code, comme mon inline si je ne me trompe pas... :PCitation:
Envoyé par Neckara
Enfin il y a une généralité à garder en tête :
Soit tu écris en dur beaucoup de choses, et ça réduit le nombre de calculs,
Soit tu réduis ce qui est en dur, et tu calcules beaucoup !
Mais le compilateur sait parfaitement où copier du code et où ne pas en copier pour obtenir des performances optimales ;), et puis il ne fait pas que ça.Citation:
Envoyé par Metalman
Bonjour,Citation:
Envoyé par Metalman
oui le -O3 (sur gcc) duplique du code parfois déroule des boucles etc ... Le comportement du inline est plus délicat. Même si tu précises qu'une fonction est inline (au sens C99) le compilateur peut décider de ne pas l'inliner. Il peut factoriser pour t'éviter à écrire des choses en dur aussi ...
Il y a une chose qui est super importante néanmoins : un compilateur sera bien souvent plus malin à optimiser que la vaste majorité des programmeurs surtout si on lui donne de bonnes indications.
Une option de gcc qui n'est pas à négliger si on cherche la perf à tout prix : on compile une première fois avec -fprofile-arcs, on utlise la version qui sera profilée et ensuite tu peux demander à gcc de recompiler en prenant en compte les données récoltées pendant le profilage (réorganisation du code pour augmenter la locailté, profiter de la prédiction de conditionnelles, ...)
Pour les fonctions inline, le problème, c'est qu'en apprenant que le compilateur peut choisir de ne pas inliner, certains programmeurs peuvent être tenté de forcer l'inlining avec une option particulière de gcc :aie:.Citation:
Envoyé par kwariz
Je ne connaissais pas :ccool: faudra que je note ^^Citation:
Envoyé par kwariz