Discussion :

[sapin]

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.

[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.

[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.

[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.

[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.

[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

[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

[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?

[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)

[sapin]

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.

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.

[sapin]

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

Merci

[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é...

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 !

[Davidbrcz]

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.

[Invité]

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

[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...)

[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.

[sapin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

MaFactory::register(int clé, PointeurFonctionGenerique)

que j'appelle pour chaque type et qui insère le "PointeurFonctionGenerique" dans la Map.

[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.

[buzzkaido]

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.