IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Performance et acces a des DLL


Sujet :

C++

  1. #1
    Membre averti Avatar de xxiemeciel
    Inscrit en
    Juin 2005
    Messages
    371
    Détails du profil
    Informations forums :
    Inscription : Juin 2005
    Messages : 371
    Points : 352
    Points
    352
    Par défaut 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
    XXiemeciel

  2. #2
    Expert éminent sénior
    Avatar de diogene
    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    Juin 2005
    Messages
    5 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2005
    Messages : 5 761
    Points : 13 926
    Points
    13 926
    Par défaut
    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
    Publication : Concepts en C

    Mon avatar : Glenn Gould

    --------------------------------------------------------------------------
    Une réponse vous a été utile ? Remerciez son auteur en cliquant le pouce vert !

  3. #3
    Membre averti Avatar de xxiemeciel
    Inscrit en
    Juin 2005
    Messages
    371
    Détails du profil
    Informations forums :
    Inscription : Juin 2005
    Messages : 371
    Points : 352
    Points
    352
    Par défaut
    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
    XXiemeciel

  4. #4
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    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).

  5. #5
    Membre averti Avatar de xxiemeciel
    Inscrit en
    Juin 2005
    Messages
    371
    Détails du profil
    Informations forums :
    Inscription : Juin 2005
    Messages : 371
    Points : 352
    Points
    352
    Par défaut
    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
    XXiemeciel

  6. #6
    Membre averti Avatar de xxiemeciel
    Inscrit en
    Juin 2005
    Messages
    371
    Détails du profil
    Informations forums :
    Inscription : Juin 2005
    Messages : 371
    Points : 352
    Points
    352
    Par défaut
    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
    XXiemeciel

  7. #7
    Membre actif Avatar de amaury pouly
    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    157
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 157
    Points : 224
    Points
    224
    Par défaut
    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 ?!) .

  8. #8
    Membre averti Avatar de xxiemeciel
    Inscrit en
    Juin 2005
    Messages
    371
    Détails du profil
    Informations forums :
    Inscription : Juin 2005
    Messages : 371
    Points : 352
    Points
    352
    Par défaut
    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.
    XXiemeciel

  9. #9
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    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.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  10. #10
    Membre actif Avatar de amaury pouly
    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    157
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 157
    Points : 224
    Points
    224
    Par défaut
    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 .

  11. #11
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    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).
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  12. #12
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    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 !
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  13. #13
    Membre actif Avatar de amaury pouly
    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    157
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 157
    Points : 224
    Points
    224
    Par défaut
    certes mais si t'as fonction est appelée un seul endrois la gain est alors probablement faible sauf si tu fais
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    for&#40;int i=0;i<5000000;i++&#41;
      for&#40;int j=0;j<50000000;j++&#41;
        my_func&#40;i,j&#41;;
    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 .

  14. #14
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    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.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  15. #15
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    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.

  16. #16
    Membre actif Avatar de amaury pouly
    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    157
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 157
    Points : 224
    Points
    224
    Par défaut
    amaury pouly a écrit:
    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) .

  17. #17
    Membre averti Avatar de xxiemeciel
    Inscrit en
    Juin 2005
    Messages
    371
    Détails du profil
    Informations forums :
    Inscription : Juin 2005
    Messages : 371
    Points : 352
    Points
    352
    Par défaut
    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
    XXiemeciel

  18. #18
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    Ce qu'on veut dire, c'est que si tu utilises ta dll ainsi:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    // analyser chaque pixel
    for &#40; int x = 0; x < 50000; ++x &#41;
    &#123;
        for &#40; int y = 0; y < 50000; ++y &#41;
        &#123;
            int pixel_value = get_pixel&#40; x, y &#41;;
            fonction_analyse_de_la_dll&#40; pixel_value &#41;;
        &#125;
    &#125;
    il faudrait penser à rajouter une fonction qui fait cette double boucle dans ta dll:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    // analyser l'image
    int * buffer = get_image_pixels&#40;&#41;;
    fonction_analyse_image_de_la_dll&#40; buffer, 50000, 50000 &#41;;
    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

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

  19. #19
    Membre averti Avatar de xxiemeciel
    Inscrit en
    Juin 2005
    Messages
    371
    Détails du profil
    Informations forums :
    Inscription : Juin 2005
    Messages : 371
    Points : 352
    Points
    352
    Par défaut
    Citation Envoyé par Aurelien.Regat-Barrel
    Ce qu'on veut dire, c'est que si tu utilises ta dll ainsi:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    // analyser chaque pixel
    for &#40; int x = 0; x < 50000; ++x &#41;
    &#123;
        for &#40; int y = 0; y < 50000; ++y &#41;
        &#123;
            int pixel_value = get_pixel&#40; x, y &#41;;
            fonction_analyse_de_la_dll&#40; pixel_value &#41;;
        &#125;
    &#125;
    il faudrait penser à rajouter une fonction qui fait cette double boucle dans ta dll:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    // analyser l'image
    int * buffer = get_image_pixels&#40;&#41;;
    fonction_analyse_image_de_la_dll&#40; buffer, 50000, 50000 &#41;;
    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

    Au fait, les dll c'est imposé ? Tu ne peux pas utiliser des libs statiques plutot ?
    merci du conseil mais je compile effectivement en release , 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
    XXiemeciel

  20. #20
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. [PERFORMANCE] acces a des vues
    Par Valkirion dans le forum Requêtes
    Réponses: 2
    Dernier message: 27/03/2009, 14h42
  2. Priorité de recherche des DLLs
    Par patapetz dans le forum Windows
    Réponses: 3
    Dernier message: 10/09/2003, 19h44
  3. Appel à des fonctions incluses dans des DLL
    Par Greybird dans le forum Langage
    Réponses: 3
    Dernier message: 26/05/2003, 14h33
  4. Réponses: 27
    Dernier message: 03/02/2003, 13h27
  5. [] [Install] Problème de mise à jour des dll
    Par pepper dans le forum Installation, Déploiement et Sécurité
    Réponses: 4
    Dernier message: 23/01/2003, 23h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo