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.