Code C++/C optimisé pour le profil

Question

J'ai un code C++ très structuré avec lequel je travaille. Je peux compiler et profiler avec les outils AMD et sleepy en mode debug. Cependant, sans optimisation, la plupart du temps passé concentré dans le code et la STL. Avec la compilation optimisée, tous les outils de profil que je connais produisent des informations sur les déchets. Est-ce que quelqu'un sait un bon moyen de profiler le code natif optimisé

PS1: Le code que j'écris est également fortement modélisé. La plupart du temps passé dans le code non optimisé sera optimisé. Je parle de 96-97% du temps d'exécution sont passés dans le code basé sur un modèle sans optimisation. Cela va corrompre la précision du profilage. Et oui, je peux changer beaucoup de code basé sur des templates ou au moins quelle partie du code basé sur des templates est la plus problématique et je peux faire mieux dans ces endroits.

Answer 1

Vous devriez vous concentrer sur le code que vous avez écrit parce que c'est ce que vous pouvez changer, le temps passé en STL est hors de propos, ignorer et se concentrer sur les appelants de ce code. Si vous passez trop de temps en STL, vous pouvez probablement appeler une autre primitive STL à la place de la primitive en cours.

Le profilage est le code unoptimized moins intéressant, mais vous pouvez toujours obtenir quelques informations. Si les algorithmes utilisés de certaines parties du code sont totalement erronés, ils apparaîtront même là. Mais vous devriez être en mesure d'obtenir des informations utiles à partir de tout bon outil de profilage dans un code optimisé. Quels outils utilisez-vous exactement et pourquoi appelez-vous leurs déchets de sortie?

En outre, il est généralement assez facile d'instrumenter votre code à la main et de savoir exactement quelles parties sont efficaces et qui ne sont pas. Il s'agit simplement d'appeler les fonctions de la minuterie (ou de lire le nombre de cycles du processeur si possible) à des endroits bien choisis. Je le fais habituellement à partir de tests unitaires pour avoir des résultats reproductibles, mais tout dépend des spécificités de votre programme.

Outils ou le code instrumentant sont la partie facile de l'optimisation. Le plus difficile est de trouver des moyens d'obtenir du code plus rapidement là où c'est nécessaire.

Answer 2

Que voulez-vous dire par "information sur les ordures"? Le profilage n'a de sens que sur les builds optimisés, donc les outils sont conçus pour fonctionner avec eux - donc si vous obtenez des résultats insignifiants, c'est probablement parce que le profileur ne trouve pas les bons symboles ou n'a pas besoin d'instrument . Dans le cas d'Intel VTune, par exemple, j'ai trouvé des résultats impossibles pour l'échantillonneur à moins que je ne lui dise explicitement où trouver les PDB pour l'exécutable que je réglais. Dans la version instrumentée, j'ai dû manipuler les paramètres jusqu'à ce que les sondes soient correctement insérées dans les appels de fonction.

Answer 3

Quand @kriss dit

Vous devriez vous concentrer sur le code que vous avez écrit parce que c'est ce que vous pouvez changer

qui est exactement ce que je voulais dire.

Je voudrais ajouter que, à mon avis, il est plus facile de faire l'optimisation des performances d'abord sur le code compilé sans optimisation, puis tourner plus tard l'optimiseur, pour la même raison. Si quelque chose que vous pouvez corriger coûte du temps supplémentaire, il en coûtera proportionnellement trop de temps indépendamment de ce que fait le compilateur, et il est plus facile de le trouver dans du code qui n'a pas été brouillé.

Je ne regarde pas ce code en mesurant le temps.Si l'excès de temps est, disons, de 20%, alors je fais une pause aléatoire plusieurs fois. Dès que je vois quelque chose qui peut évidemment être amélioré sur 2 échantillons ou plus, alors je l'ai trouvé. It's an oddball method, but it doesn't really miss anything. Je mesure le temps total avant et après pour voir combien j'ai économisé. Cela peut être fait plusieurs fois jusqu'à ce que vous ne puissiez rien trouver à réparer. (BTW, si vous êtes sur Linux, Zoom est un moyen plus automatisé de le faire.)

Ensuite, vous pouvez activer l'optimiseur et voir combien cela vous donne, mais quand vous voyez ce que vous avez fait, vous peut voir qu'il n'y a vraiment aucun moyen que le compilateur aurait pu le faire pour vous.