[Profilage] Beaucoup de temps dans des modules inconnues

Version imprimable

08/03/2010, 10h26
sapin

[Profilage] Modules inconnues | Pointeur de fonction vs Foncteur

Bonjour,

J'ai un soucis actuellement avec un programme en cours de développement.
En effet, mon programme est assez long à l'exécution et pour savoir qu'est ce qui le ralentie, j'ai lancer un profilage avec l'outil fournit dans Visual Team Suite.

Selon cette outils, les modules qui ont le pourcentages d'exemples exclusifs les plus élever sont : mscorwks.dll (32,84 %), MonExe.exe (24%) et ntdll.dll (18%).

Je ne comprend pas du tout à quoi servent mscorwks.dll et ntdll.dll (d'après quelques recherches, c'est en rapport avec du .net, mais je n'en utilise pas).

Avez vous une idée de ce qui fait que ces modules sont appelés si souvent ?

Mon programme est constitué d'un exe (le main) et de deux .lib. Le code est beaucoup trop volumineux pour pouvoir etre posté, mais il ne me semble pas que j'utilise de fonction exotique (hormis quelques fonctions déclarer en inline).

Merci pour votre aide car la, je suis vraiment perdu.
08/03/2010, 11h42
Sylvain Togni

Ne te focalise pas trop sur les modules, c'est surement dû à des appels systèmes dans ton code, mais ce n'est pas le plus important à savoir pour optimiser une application.

Ce qui est important c'est de savoir quelles sont les fonctions dans ton code qui prennent le plus de temps, pour savoir sur lesquelles concentrer ses efforts. Normalement un profiler doit donner cette info.
08/03/2010, 12h22
sapin

Lorsque je regarde les fonctions, ce sont encore les dll qui arrivent en tete.
mscorwks.dll et ntd.dll conserve les memes % d'exemple exclusif (32% et 18%)

Ma première fonction arrive à avec un pourcentage de 2,02% d'exemple exclusif. Ce qui est vraiment faible par rapport au DLL.

Je suis vraiment perdu pour le coup.
08/03/2010, 12h39
Sylvain Togni

Ça doit être parce que tu regarde le temps "exclusif" des fonctions, c'est-à-dire le temps passé dans chaque fonction à l'exclusion du temps passé dans ses sous-fonctions.

Il est plus intéressant de regarder le temps total passé dans chaque fonction, il doit y avoir une option quelque part dans le profiler pour cela.
08/03/2010, 12h40
JolyLoic

C'est à dire que tu dois passer plein de temps dans des appels systèmes (lecture de fichiers, allocation mémoire, lock de mutex...). Regarde donc quelle fonction à toi arrive en tête en temps non exclusif, tu y trouveras probablement ce genre d'appel.
08/03/2010, 14h46
sapin

Alors, suivant vos conseils, je me suis intéressé au pourcentage inclusifs et non exclusif et oublié les dll.

J'ai trouver une fonction au pourcentage "anormalement" élevé pour ce qu'elle fait et il semble que cela soit du à la présence d'un pointeur de fonction dans ce bout de code. En faisant des tests, j'ai fait sauter ce pointeur de fonction et j'améliore mon temps d'exécution en release d'un facteur 10.

Il ne me reste plus qu'a trouver un moyen pour remplacer ce pointeur de fonctions, mais cela me semble mal partie car la généricité de mon code ce faisait à travers ce pointeur.

Merci pour vos conseils :ccool:
08/03/2010, 15h05
gbdivers

Bonjour

En utilisant le pattern Stratégie, tu ne peux pas éviter les pointeurs de fonctions ?
http://come-david.developpez.com/tut...trategie#LVIII
08/03/2010, 15h13
nikko34

rassure moi, quand tu dis que ça va plus vite quand tu as enlevé le code, c'est ptet parce que ta fonction (pointée) n'était plus appelé? Et c'est ptet ce qu'il y a dans la fonction qui pose problème, et pas le fait que ça soit un pointeur?

@gbdivers

Plutôt que de partir sur du pattern strategy, autant mentioner les fonctions virtuelles pour commencer?
08/03/2010, 16h22
JolyLoic

j'aurais plutôt dit un foncteur, dont la résolution à la compilation peut améliorer les perfs, voir les benchs std::sort (foncteur) / qsort (pointeur de fonction)
10/03/2010, 09h48
sapin

Citation:

Envoyé par nikko34

rassure moi, quand tu dis que ça va plus vite quand tu as enlevé le code, c'est ptet parce que ta fonction (pointée) n'était plus appelé? Et c'est ptet ce qu'il y a dans la fonction qui pose problème, et pas le fait que ça soit un pointeur?

J'ai recopié le contenu de la fonction appeler par le pointeur de fonction et je l'ai inséré dans mon code. La "fonction pointée" n'est donc pas en cause puisqu'elle est exécuté.

J'ai tenté le pattern stratégie mais cela n'améliore pas mes performance. Je pense que les fonctions virtuels et les pointeurs de fonctions c'est un peu le même combats pendant l'exécution.

Citation:

j'aurais plutôt dit un foncteur, dont la résolution à la compilation peut améliorer les perfs, voir les benchs std::sort (foncteur) / qsort (pointeur de fonction)

Je ne connait pas ca par contre, je vais essayé de me renseigner dessus. Pour le moment les seuls infos que j'ai trouver parle d'un for_each optimisé pour le cas du traitement d'un élément unique.

Merci à vous.

Edit :
Je pense avoir trouver un exemple de foncteur plus clair ici. http://bakura.developpez.com/tutoriel/cpp/tri/
Ce doit être ce dont tu me parlais.
11/03/2010, 12h58
sapin

J'ai remplacé les pointeurs de fonction par des foncteur, et mon temps d'exécution est beaucoup plus rapide.

Merci
13/03/2010, 12h37
buzzkaido

Bonjour,

Cette histoire d'optimisation m'intéresse beaucoup, car j'utilise aussi des pointeurs de fonction, aussi pour une histoire de généricité...

Citation:

J'ai remplacé les pointeurs de fonction par des foncteur, et mon temps d'exécution est beaucoup plus rapide.

Tu veux dire que tu as remplacé les pointeurs de fonction par des pointeurs sur des foncteur ?

Ou autre ?

Y'aurait moyen que tu poste un bout de code "avant" et "après" histoire de bien voir ce que tu as optimisé ?

Merci !
13/03/2010, 13h04
Davidbrcz

Citation:

Envoyé par buzzkaido

Bonjour,

Cette histoire d'optimisation m'intéresse beaucoup, car j'utilise aussi des pointeurs de fonction, aussi pour une histoire de généricité...

Tu veux dire que tu as remplacé les pointeurs de fonction par des pointeurs sur des foncteur ?

Ou autre ?

Y'aurait moyen que tu poste un bout de code "avant" et "après" histoire de bien voir ce que tu as optimisé ?

Merci !

Cf le message de loic. Il a remplacé qsort+pointeurs de fonction par std::sort et des foncteurs.

Si je ne raconte pas de betise, l'idée principale de l'optimisation par foncteur est que dans un algorithme, le foncteur peut directement être remplacé au moment de la compilation et éviter ainsi d'appeler des centaines de fois une fonctions. A l'inverse, utiliser un pointeur de fonction oblige à une évaluation au moment de l'exécution, ce qui a pour effet de effet de plomber les perfs.

Réponse fournie sans garantie, si quelqu'un peut confirmer.
13/03/2010, 13h50
Invité

Citation:

Envoyé par Davidbrcz

Cf le message de loic. Il a remplacé qsort+pointeurs de fonction par std::sort et des foncteurs.

Si je ne raconte pas de betise, l'idée principale de l'optimisation par foncteur est que dans un algorithme, le foncteur peut directement être remplacé au moment de la compilation et éviter ainsi d'appeler des centaines de fois une fonctions. A l'inverse, utiliser un pointeur de fonction oblige à une évaluation au moment de l'exécution, ce qui a pour effet de effet de plomber les perfs.

Il peut effectivement y avoir inlining du foncteur, mais je ne crois pas que ce soit garanti.

Sur le bench de Loic, il y a deux éléments qui changent : sort vs qsort, et foncteur vs pointeur de fonction...

Je crois qu'on peut passer à std::sort un pointeur de fonction. Il faudrait donc comparer :

std::sort + foncteur
std::sort + pointeur de fonction
qsort + pointeur de fonction

Je dis cela parce que quicksort, l'algo de qsort, et l'un de ceux utilisés par std::sort (de mémoire, c'est un drole de mix entre heap et quick sort) est célèbre pour ses perf variables d'une implémentation à l'autre (c'est typiquement l'algo qu'il faut tester quand on décide de l'écrire ou de l'améliorer soi même)

Il faudrait également regarder les implémentations de la comparaison... Un algorithme de tri comme quicksort fait *beaucoup* de comparaisons (et leur nombre peut changer radicalement d'une implémentation à l'autre). Une petit différence entre le code du foncteur et celui de la fonction peut avoir un effet important à l'arrivée.

Francois
14/03/2010, 18h46
buzzkaido

Pour avoir regardé le sort de la STL il y a quelque temps, il me semble que c'était un truc du genre :

- si le nombre d'éléments restant à trier est inférieur à un seuil -> heap sort
- si le nombre d'éléments restant à trier est supérieur à ce seuil -> quick sort

Ce qui est le plus malin (le seuil choisi étant la valeur de "n" pour laquelle les courbes de complexité des deux algo se croisent)

Du coup il serait intéressant de connaitre les valeurs dont parle fcharton

Par contre, dans le cas d'une généricité à l'exécution (pour exécuter une "factory" en fonction du type d'un objet qui n'est pas connu à la compilation) j'utilise actuellement des pointeurs de fonction. Je me demandais donc si les remplacer par des pointeurs de foncteurs pourrait améliorer quelque chose (même si je ne vois pas trop comment ?)

Est-ce l'optimisation avec les foncteurs tient bien à la différence :

"pointeur" <=> "déterminé à la compilation"

ou y-a-t-il d'autres raisons ?

(j'ai pas très envie de tout changer maintenant si je suis pas à peu près sûr de gagner quelque chose...)
14/03/2010, 22h15
JolyLoic

Rien n'est garanti en théorie, mais en pratique, les compilateurs arrivent généralement bien mieux à inliner le code d'un foncteur que celui d'un fonction qui est passée par pointeur.

Cet inlining, comme tous les inlinings, fait gagner le coût d'un appel de fonction (qui peut être non négligeable dans ce genre de cas où la fonction elle même est généralement très courte), plus ouvre des opportunité d'optimisation du fait que l'appel de fonction n'est plus une frontière infranchissable.

Bonjour tous le monde et désolé du retard pour la réponse,

Alors, premier point : je n'ai pas utilisé de sort ou de qsort dans mon code. Ca n'est donc pas intervenu dans mon cas d'optimisation.

Grosso modo, voici comment j'ai modifié le code pour intégrer les foncteurs. En pseudo code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 /*Version pointeur de fonction*/ typedef int (*PointeurFonctionGenerique) (void ); //définition de fonction génériques. int FonctionGenerique1() {...}; int FonctionGenerique2() {...}; //Objet contenant les fonction générique Class CoquilleVide{ PointeurFonctionGenerique pf; void Init(int i); void Run(); }; void CoquilleVide::Init(int i) { switch(i) { case 0 : pf = FonctionGenerique1; break; case 1 : pf = FonctionGenerique2; break; default :pf = Fonction Generique2; }; } void CoquilleVide::Run() { int res = (*pf)(); }
Avec cette version, je perd beaucoup en temps d'exécution à chaque que pf est appelé.

Voici maintenant la version avec foncteur.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 //Je garde mes fonctions générique déjà défini int FonctionGenerique1() {...}; int FonctionGenerique2() {...}; //je défini une struct qui contient le foncteur struct MonFoncteur{ void operator()(int res&, int i); int index; } //je défini ce que va faire mon foncteur void MonFoncteur::operator()(int res&, int i) { switch(i) { case 0 : res = FonctionGenerique1(); break; case 1 : res = FonctionGenerique2(); break; } //je garde la classe qui exécute le code Class CoquilleVide{ MonFoncteur foncteur; void Init(int i); void Run(); }; void CoquilleVide::Init(int i) { index = i; } void CoquilleVide::Run() { int res; foncteur(res, foncteur.index); }
Avec cette version, je ne perd pas en temps d'exécution. Le temps d'appel du foncteur est transparent (même temps d'exécution que lorsque je ramène le switch dans ce cas la directement dans la fonction run, du je pense à l'inlining.).

Voila la solution que j'ai mis en place car comme dit plus haut, je n'utilise pas la stl pour appeler mes fonctions générique.

N'hesitez pas à me faire signe si vous voyez une autre méthode d'implementation.

Merci !:ccool:

15/03/2010, 10h23
buzzkaido

Merci pour les précisions !

J'ai un code du même goût, ça devrait donc s'appliquer, par contre, pour éviter un "vilain switch" et éviter de le maintenir à jour, j'utilise une Map.

Il y a donc un peu de perte de temps (recherche dans la map) mais vu que la clé est un "int", ça va vite...

Du coup, au lieu d'enregistrer mes fonctions génériques dans un "switch", j'ai une fonction comme ça :

Code:

MaFactory::register(int clé, PointeurFonctionGenerique)

que j'appelle pour chaque type et qui insère le "PointeurFonctionGenerique" dans la Map.
15/03/2010, 10h30
sapin

Bien vu pour la map.

Sinon de manière conceptuel, la méthode avec les foncteurs me convient, car permet de mettre une différence entre le "metier" contenu dans les fonctions générique et "l'algo".

Vu que la conversation a déviée, je vais modifier le titre du topic.
15/03/2010, 10h45
buzzkaido

Citation:

Sinon de manière conceptuel, la méthode avec les foncteurs me convient, car permet de mettre une différence entre le "metier" contenu dans les fonctions générique et "l'algo".

Pareil.

Je me sers de ce système comme ça :

- une librairie d'objets métiers, qui ne contiennent que le minimum (code de calcul, get/set sur les paramètres...)

- une librairie de widgets (un par objet métier, en général) qui sont l'équivalent de mes objets métiers, mais dans la "couche graphique" de l'appli

- une librairie d'algorithmes (qui peuvent s'appliquer sur certains objets métiers)

ensuite le lien entre un objet métier, un ou plusieurs widgets et un ou plusieurs algo se fait via des "Factory" (ou equivalent) qui sont enregistrés sous forme de pointeurs de fonctions.

Ainsi, sans modifier les objets métiers (la base de tout sur lesquels y'a pas mal de tests unitaires automatiques...) je peut :
- ajouter / modifier / supprimer des widgets (ajouter un éditeur de propriétés, modifier une fenêtre de visualisation...)
- ajout / modifier / supprimer des algo (nouvel algo, modification des specs..)

du coup, vu que mes objets métiers sont garants de la cohérence des informations sur lesquelles on bosse (c'est eux qui font les contrôles lors de la modification de leurs propriétés) ben quelque soit la forme de l'IHM, les éditeurs que l'on met dedans ou les algos de calcul que l'on exécute, on est sûr que les données sur lesquelles on bosse sont toujours dans un état "correct".

Avec un petit MVC en plus par là-dessus on est aussi sûr quel les données présentées à l'utilisateur dans les IHM sont toujours à jour et donc toujours cohérentes.