Performance et acces a des DLL

Bonjour,

Depuis maintenant une bonne semaine j'effectue des tests de performances sur un code tres simple. Il sagit de la fonction suivante

bool transformx()
{
return false;
}

que j'appel 50000*50000 fois dans une boucle, le programme s'execute en 3 secondes. La fonction etant codée dans le fichier cpp contenant le main.

si je place le code de la fonction dans des fichiers transform.hh et transform.cpp independant de mon main, alors les temps d'Executions explose a 15 secondes (enorme perte de performance pour un code aussi simple).

La meme baisse de performance apparait si je construit un DLL a partir de transform.hh et transform.cpp. Et la perte de performance persiste lorsque je fais un chargement explicite de la fonction du DLL.

Jusqu'a present je n'ai presque pas trouver d'informatiopn sur les temps d'acces a des fonctions dans des bibliotheques statique ou dynamique mais il semblerait que cela influe beaucoup sur la performances.

Si jamais quelqu'un a des informations sur le sujet je suis preneur

Merci
Vincent

La fonction a été compilée in-line donc sans les procédures d'appel et de retour coûteuses en temps.
Dans un autre cpp, ou une librairie, la fonction ne peut être in-line d'où l'accroissement du temps d'exécution

Citation:

---

Envoyé par diogene

La fonction a été compilée in-line donc sans les procédures d'appel et de retour coûteuses en temps.
Dans un autre cpp, ou une librairie, la fonction ne peut être in-line d'où l'accroissement du temps d'exécution

---

ca veut dire que dans le cas de grosses fonction ou de programmation object dans un DLL les performances vont chuter a ce point ? Parceque on peut pas mettre tout le code d<un programme inline.

merci
Vincent

Tu peux sous VC++ activer l'optimisation globale qui va permettre de faire de l'inlining depuis d'autres cpp / lib statiques.
http://gilles-vollant.developpez.com.../optimisation/
Sinon quelques remarques:
- ce n'est pas une perte de performance que tu constates, mais plutot l'impossibilité d'optimiser, ce qui est différent
- tu ne mesures que le cout d'un appel de fonction (ta fonction est vide). C'est ce que te permet de gagner l'inlining. Plsu tu as de code, et moins le bénéfice de l'optimisation se fait sentir. Donc "ca veut dire que dans le cas de grosses fonction" y'aura pratiquement pas de différence
- tu effectues 2.500.000.000 appels de fonctions... et l'optimisation ne porte que sur celà. On peut raisonnablement penser que dans une utilisation plus "normale" de ton logiciel, il y en aura beaucoup moins. Les bénéfices de l'options présentée ci dessus se chiffrent de l'ordre du pourcentage. Autrement dit, à utiliser une dll, ce serait fort surprenant que tu ais ne serait-ce que 5% de différence, sauf cas particulier (nombre élevé de focntions quasi vides appelées très très souvent).

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Tu peux sous VC++ activer l'optimisation globale qui va permettre de faire de l'inlining depuis d'autres cpp / lib statiques.
http://gilles-vollant.developpez.com.../optimisation/
Sinon quelques remarques:
- ce n'est pas une perte de performance que tu constates, mais plutot l'impossibilité d'optimiser, ce qui est différent
- tu ne mesures que le cout d'un appel de fonction (ta fonction est vide). C'est ce que te permet de gagner l'inlining. Plsu tu as de code, et moins le bénéfice de l'optimisation se fait sentir. Donc "ca veut dire que dans le cas de grosses fonction" y'aura pratiquement pas de différence
- tu effectues 2.500.000.000 appels de fonctions... et l'optimisation ne porte que sur celà. On peut raisonnablement penser que dans une utilisation plus "normale" de ton logiciel, il y en aura beaucoup moins. Les bénéfices de l'options présentée ci dessus se chiffrent de l'ordre du pourcentage. Autrement dit, à utiliser une dll, ce serait fort surprenant que tu ais ne serait-ce que 5% de différence, sauf cas particulier (nombre élevé de focntions quasi vides appelées très très souvent).

---

A l'origine les tests etaient sur les codes de ma compagnie (donc des objets complexes et volumineux) et je constatais les memes pertes de performances allant de 10 secondes a plus de 90 secondes en comparant des appels direct d'une fonction codées avec les main de mon test et un appel au code de la compagnie (pour la meme fonction)

Je dois avouer que la fonction qui a servit de test n'etait pas particulierement complexe, mais la difference de temps d'execution etait suffisement importante pour qu'on me demande de prolonger les tests en vu de chercher un optimisation.

au final j'en suis venu a simplifier au maximum pour voir si les differences de temps persistaient.

cordialement
Vincent

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Tu peux sous VC++ activer l'optimisation globale qui va permettre de faire de l'inlining depuis d'autres cpp / lib statiques.
http://gilles-vollant.developpez.com.../optimisation/
Sinon quelques remarques:
- ce n'est pas une perte de performance que tu constates, mais plutot l'impossibilité d'optimiser, ce qui est différent
- tu ne mesures que le cout d'un appel de fonction (ta fonction est vide). C'est ce que te permet de gagner l'inlining. Plsu tu as de code, et moins le bénéfice de l'optimisation se fait sentir. Donc "ca veut dire que dans le cas de grosses fonction" y'aura pratiquement pas de différence
- tu effectues 2.500.000.000 appels de fonctions... et l'optimisation ne porte que sur celà. On peut raisonnablement penser que dans une utilisation plus "normale" de ton logiciel, il y en aura beaucoup moins. Les bénéfices de l'options présentée ci dessus se chiffrent de l'ordre du pourcentage. Autrement dit, à utiliser une dll, ce serait fort surprenant que tu ais ne serait-ce que 5% de différence, sauf cas particulier (nombre élevé de focntions quasi vides appelées très très souvent).

---

j'ai utiliser l'option whole lors de ma compilation (/GL) et j'ai obtenu une optimisation dans le cas ou le code est dans mes include (sans DLL). Le temps d'execution redescend alors a 4 secondes.

Cependant je n'Arrive pas a optimiser dans le cas d'un acces au DLL, je suis en train d'essayer d'utiliser l'option /LTCG mais pour l'instant l'option est refusé par mon compilateur.

cordialement
Vincent

tu ne peux pas optimiser avec une DLL .
d'ailleurs la question ne se pose pas: il est impossible d'optimiser un code aussi simple . L'inlining n'a aucune valeur ici puisque jamais un compilo n'inlinera un efonction de 40 ligne ou plus .
Une dll est un fichier compilé qui contient le code donc impossible d'inliner une fonction que tu exporte !!!(sinon il n'y a pas de fonction) donc tu l'appel(linking statique ou chargement dynamique: revient au même): çà revient au problème de départ: plus de temps à cause du coup de l'appel .

Au fait: je doute que dans ta compagnie on appel 50000*50000 fois ce code sinon il doit y avoir un problème d'algo ou alors vous travaillez sur des énorme base de données(mal optimisées ?!) .

Citation:

---

Envoyé par amaury pouly

tu ne peux pas optimiser avec une DLL .
d'ailleurs la question ne se pose pas: il est impossible d'optimiser un code aussi simple . L'inlining n'a aucune valeur ici puisque jamais un compilo n'inlinera un efonction de 40 ligne ou plus .
Une dll est un fichier compilé qui contient le code donc impossible d'inliner une fonction que tu exporte !!!(sinon il n'y a pas de fonction) donc tu l'appel(linking statique ou chargement dynamique: revient au même): çà revient au problème de départ: plus de temps à cause du coup de l'appel .

Au fait: je doute que dans ta compagnie on appel 50000*50000 fois ce code sinon il doit y avoir un problème d'algo ou alors vous travaillez sur des énorme base de données(mal optimisées ?!) .

---

la boucle est la uniquement pour le tests elle permet de comparer autrement que sur des nanosecondes.

et pour l'instant ce que je retire de ce qu'on me dit c que la performance chute de 400% uniquement a cause de l'utilisation du DLL.

Citation:

---

Envoyé par xxiemeciel

et pour l'instant ce que je retire de ce qu'on me dit c que la performance chute de 400% uniquement a cause de l'utilisation du DLL.

---

Non, tu "penses" à l'envers, ça t'a déjà été dit.

La réponse à ton problème est liée aux fonctions inline et à la différence de temps entre sauts courts et sauts longs. On peut aussi parler d'optimisations plus vicieuses, comme le "invariant code motion" ou le "copy propagation", etc, etc...

Après, ce ne sont pas les performances qui "chutent" de 400% en DLL, mais une amélioration en appel inline.

Contrairement à ce que tu crois, ce que tu mesures en appel DLL, ce sont les performances NORMALES. Dans le cadre de ton appel en DLL de 15 secondes, ça fait 6 NANOsecondes par appel, soit l'équivalent de 12 cycles CPU sur un processeur à 2 GHz. Tout à fait raisonnable pour un saut, un chargement, un retour, une décrémentation de compteur, un test et un saut conditionnel.

Dans le cas "rapide", durant 3 secondes, ça fait 1.2 ns par "appel", donc l'équivalent de 2 à 3 cycles CPU par "appel"... Ceci correspond à peine à un chargement de registre !! En gros, ta fonction ne fait rien d'autre que mesurer le temps pris par le chargement du registre EAX. Et encore : pas dit que ça fasse autre chose que simplement décrémenter une boucle, tester et faire le saut conditionnel, suivant les optimisations !!

Tu devrais t'intéresser de très très près à l'assembleur généré par ton code, je pense que beaucoup de choses seraient bien plus claires pour toi.

je confirme .
surotut que dans une utilisation normale d'un programme tu vas pas inliner une fonction de 100 lignes(d'ailleurs je compilo l'ignorerais je pense) . D'autre part, une fonction normale c'est:
->saut
->chargement(allocation var locale sur la pile)
->code
(->libération var locale sur la pile) <- dépend du protocoel d'appel
->retour

toi tu considère que une fonction normale c'est
->code

or le saut est probablement l'une des opération les plus coûteuse dans un programme(vidage et remplissage du cache, saut en lui même) donc évidemment sur une obucle pareille la différence est énorme et pourtant ne représente RIEN !!

L'utilisation de la DLL NE RALENTIE PAS LE PROGRAMME MAIS LE PLACE DANS UNE UTILISATION NORMALE !

essaye de coder une fonction de 30 ou 40 lignes et de l'appeler 50000*50000 fois et tes test auront déjà plus de valeur .

Citation:

---

Envoyé par amaury pouly

je confirme .
surotut que dans une utilisation normale d'un programme tu vas pas inliner une fonction de 100 lignes(d'ailleurs je compilo l'ignorerais je pense) .

---

Il peut être intéressant d'inliner des fonctions de 100 lignes, ou plus grosses encore. Ca peut en particulier arriver quand la fonction n'est appelée que depuis un très petit nombre d'endroits (voire 1 seul point d'appel).

Citation:

---

Envoyé par amaury pouly

surotut que dans une utilisation normale d'un programme tu vas pas inliner une fonction de 100 lignes(d'ailleurs je compilo l'ignorerais je pense) .

---

Non, on peut mettre en inline une fonction de n'importe quelle taille. Par contre, si la fonction est appelée en beaucoup d'endroits (et non pas "très fréquemment", ce qui est encore autre chose), la taille du code produit peut grimper de façon assez démentielle... C'est certes efficace, mais ça coûte de la mémoire, ne serait-ce que pour contenir le code ! ;-)
De manière générale, toute fonction appelée à un seul endroit du code mérite de passer en inline : dans ce cas (très) particulier, ça réduit même la taille du code final ! :mrgreen:

certes mais si t'as fonction est appelée un seul endrois la gain est alors probablement faible sauf si tu fais

Code:

---

1 2 3 4

for(int i=0;i<5000000;i++) for(int j=0;j<50000000;j++) my_func(i,j);

---

le fait d'inliner permet un gain de place de 20 octets si la fonction est appelée a un seul endrois alors autant dire que c'est rien .
et puis on parle de DLL donc la question ne se pose pas(i.e nom du topic) .
Dans une dll impossible d'inliner une fonction qu'on exporte(si on l'exporte pas on peut), qu'elle fasse 1 ou 1000 lignes .

Citation:

---

Envoyé par amaury pouly

certes mais si t'as fonction est appelée un seul endrois la gain est alors probablement faible

---

Oui, mais il existe quand même, en vitesse d'exécution comme en taille de code.

Citation:

---

Envoyé par amaury pouly

le fait d'inliner permet un gain de place de 20 octets si la fonction est appelée a un seul endrois alors autant dire que c'est rien .

---

Mais à force, sur des centaines (voire des milliers !) de fonctions, ça finit par compter... Surtout qu'il n'y a pas que ça comme optimisations capable de réduire la taille du code tout en augmentant la vitesse d'exécution.
N'oublie pas qu'il y a beaucoup de domaines où la place mémoire est un élément rare et précieux, notamment l'embarqué et les serveurs. Dans d'autres domaines (drivers par exemple), le facteur "performance" est crucial, même si c'est juste 1% de gain : ça peut faire la différence avec le matériel du concurrent !!
De manière générale, ça ne coûte rien d'activer ce genre de trucs, et c'est tout bénéfice : pourquoi s'en priver ? ;-)

Citation:

---

Envoyé par amaury pouly

Dans une dll impossible d'inliner une fonction qu'on exporte(si on l'exporte pas on peut), qu'elle fasse 1 ou 1000 lignes .

---

Bien sûr, je suis d'accord avec toi, mais comme tu le fais remarquer, c'est largement possible au sein de l'exécutable utilisant la DLL, et au sein de la DLL elle-même. Les fonctions exportées sont un cas un peu particulier.

Si tu as un tel écart de performance en utilisant une dll, tu devrais peut être repenser l'interface de cette dernière. Il n'est pas normal que ton programme passe la majorité de son temps à faire de la gestion de pile d'appel, il y a un probleme.

Citation:

---

amaury pouly a écrit:

Citation:

---

Dans une dll impossible d'inliner une fonction qu'on exporte(si on l'exporte pas on peut), qu'elle fasse 1 ou 1000 lignes .

---

Bien sûr, je suis d'accord avec toi, mais comme tu le fais remarquer, c'est largement possible au sein de l'exécutable utilisant la DLL, et au sein de la DLL elle-même. Les fonctions exportées sont un cas un peu particulier.

---

Justement, s'il a besoin d'une dll c'est bien pour l'appeller !!! Donc ce n'est pas un cas particulier mais le cas général, normal, attendu(appel çà comme tu veux)(qu'il optimise dedans on s'en fou puisqu'il l'appel dans tous les cas) . S'il appel 50000*50000 fois cette fonction alors c'est probablement qu'il y a une erreur de conception et qu'il faut revoir le raisonnement .
Sur un système embarqué d'accord la mémoire est précieuse, dans un driver la vitesse est crucial mais néanmoins si tu arrive a en écrire 1000 fonctions alors je doute que tu inline les 1000 fonctions pour optimiser car il serait plus probable et plus logique de concevoir une DLL .
Pour optimiser il n'y a pas 100 méthodes: un code bien conçu(je parle pas de l'assembleur puisque pour battre le compilo c'est assez difficile) .

Pour le moi le problème n'est pas dans la taille ou la rapidité, qu'on gagne 1 ns à chaque appel quelle importantce tant que l'on appel pas cette fonction un très très très très grand nombre de fois ?! D'ailleurs quand on dépasse 1000000 d'appels pour la même fonction, pour moi c'est qu'il y a un problème(et encore c'est beaucoup) .

Bonjour a tous et merci de vos reponses,

J'ai probablement trop simplifier la chose lorsque j'ai exposer mon probleme. Je vais donc expliquer plus en detail.

tout d'abord une boucle de 50000 par 50000 n'est absolument pas ridicule et le fais d'appeller une fonction tres simple non plus. Je travail pour une compagnies de traitement des images satellites et nous travaillons sur des images pouvant avoir jusqu'a 30 bandes de données et plusieurs milliards de pixels (certaines de nos images font plusieurs Gigas).

Et si la perte de performance par l'utilisation de DLL sur un appel repetitif d'une fonction tres simple (par exemple le traitement d'un seul pixel) a des pertes de performances de 400% cela a beaucoup d'importance pour nous.

J'ai aussi relancé mes tests avec une fonction non vide d'environs une quarantaine de lignes (le code vient d'un algorithme de traitement des pixels justement) et les pertes de performances sont semblables a ce que j'avais constaté avec les autres tests.

Je m'y connais tres peu en systeme, compilation et assembleur, j'ai une formation plutot mathematique orienté vers le traitement des images. C'est pour cela que je suis venu vous demander des conseils sur comment optimiser mes acces DLL .

Cordialement
Vincent

Ce qu'on veut dire, c'est que si tu utilises ta dll ainsi:

Code:

---

1 2 3 4 5 6 7 8 9 10

// analyser chaque pixel for ( int x = 0; x < 50000; ++x ) { for ( int y = 0; y < 50000; ++y ) { int pixel_value = get_pixel( x, y ); fonction_analyse_de_la_dll( pixel_value ); } }

---

il faudrait penser à rajouter une fonction qui fait cette double boucle dans ta dll:

Code:

---

1 2 3 4

// analyser l'image int * buffer = get_image_pixels(); fonction_analyse_image_de_la_dll( buffer, 50000, 50000 );

---

Ensuite ce n'est absolument pas normal que tu ais 400% de différence sur une fonction de 40 lignes. La différence devrait être négligeable, sauf si ta fonction s'execute quasi instantanément.

Bref, la règle, c'est que pour minimiser le cout d'utilisation de la dll, il faut minimiser le cout des appels de fonctions, donc minimiser le nombre d'appels de fonction, donc faire le plus de choses possibles dans tes fonctions.

Pense bien à compiler en Release aussi :wink:

Au fait, les dll c'est imposé ? Tu ne peux pas utiliser des libs statiques plutot ?

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Ce qu'on veut dire, c'est que si tu utilises ta dll ainsi:

Code:

---

1 2 3 4 5 6 7 8 9 10

// analyser chaque pixel for ( int x = 0; x < 50000; ++x ) { for ( int y = 0; y < 50000; ++y ) { int pixel_value = get_pixel( x, y ); fonction_analyse_de_la_dll( pixel_value ); } }

---

il faudrait penser à rajouter une fonction qui fait cette double boucle dans ta dll:

Code:

---

1 2 3 4

// analyser l'image int * buffer = get_image_pixels(); fonction_analyse_image_de_la_dll( buffer, 50000, 50000 );

---

Ensuite ce n'est absolument pas normal que tu ais 400% de différence sur une fonction de 40 lignes. La différence devrait être négligeable, sauf si ta fonction s'execute quasi instantanément.

Bref, la règle, c'est que pour minimiser le cout d'utilisation de la dll, il faut minimiser le cout des appels de fonctions, donc minimiser le nombre d'appels de fonction, donc faire le plus de choses possibles dans tes fonctions.

Pense bien à compiler en Release aussi :wink:

Au fait, les dll c'est imposé ? Tu ne peux pas utiliser des libs statiques plutot ?

---

:lol: merci du conseil mais je compile effectivement en release :lol: , pour les DLL c surtout que la majorité des codes de ma compagnie on plus de 10 ans d'age et que une optimization pourrait etre plus rapide et moins couteuse qu'un recodage complet.

Cependant je comprend parfaitement ton point de vu sur les appels de fonction. Il faut essayer de limiter le nombre d'acces au DLL finalement.
Cependant j'esperais qu'il existe un moyen d'optimiser l'Acces a la fonction dans le DLL.

cordialement
Vincent

Si tu peux te passer des dll, modifies les en lib statique, avec l'option d'optimisation globale.
Tu cherches à optimiser l'accès à une fonction de la dll. Or l'optimisation consiste à supprimer cet accès à la fonction via l'inlining. Dans le cas d'une dll, si tu supprime la fonction, y'a plus de dll... Autrement dit, ne cherche pas à optimiser là où on peut pas optimiser. Identifie pourquoi ta dll est utilisée de manière si intensive, et repense son interface pour réduire le nombre d'appel des fonctions.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Si tu peux te passer des dll, modifies les en lib statique, avec l'option d'optimisation globale.
Tu cherches à optimiser l'accès à une fonction de la dll. Or l'optimisation consiste à supprimer cet accès à la fonction via l'inlining. Dans le cas d'une dll, si tu supprime la fonction, y'a plus de dll... Autrement dit, ne cherche pas à optimiser là où on peut pas optimiser. Identifie pourquoi ta dll est utilisée de manière si intensive, et repense son interface pour réduire le nombre d'appel des fonctions.

---

ok, merci