Discussion :

[Jeane]

Bonjour

dans mon programme j'utilise initialement une map de type<Material*,Cell> et j'ai une fonction num suivante:

Code :

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

1
2
3
4
5
6
7
8
int num(Material *matl) {
    map<Material *,Cells>::iterator p = mat_.find(matl);
    if (p != mat_.end()) {
        return (p->second).num;
    } else {
        return (int)0;
    }
}

En analysant avec callgrind les fonctions qui prennent le plus de temps je me rend compte que c celle-ci qui est appeler bcp de fois et qui prend bcp de temps.
Etant donner que la taille de la map ne depasse pas 5. Je me dis que construire l'iterateur est ce qui prend du temps.

Du coup je pense a une alternative qui est de stoker directement les valeurs num dans un vecteur de taille 5 et d'y acceder directement genre:

Code :

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

1
2
3
4
5
6
7
8
9
int num2(Material *matl) {
    int ind=matl->id();
    if (ind < nbmat_) {
        return mat2_[ind];
    } else {
        cout <<"Attention ca a depasser la taille de mat2_"<<endl;
        return 0;
    }
}

cette modification entraine bcp de changements lourds.
C'est pourquoi avant je voudrais savoir si vouss pensez qu'une telle modification peut reellement etre benefique pour accelerer le programme.

Merci
Cordialement
jeanne

[mchk0123]

Est ce que tu ne pourrais pas plus simplement stocker la valeur renvoyée précédemment par "num()" dans chaque instance de Material sous une variable num ?

Cela s'appèlle faire de la pré-calculation de fonctions : on pré-calcul les valeurs connues de retour de fonctions en début (ou en cours) de programme et puis on y accède directement dés que l'on en à besoin.

Ca évite d'exécuter le même code à chaque fois.

Dis moi si ca peut s'appliquer à ton cas.

[Sylvain Togni]

Oui, avec peu d'éléments c'est très souvent un simple vecteur qui est la structure la plus rapide.

Ce qui est intéressant pour tester rapidement divers conteneurs c'est d'encapsuler les fonctionnalités désirées dans une classe, de cette façon on peut changer l'implémentation (std::map ou std::vector par exemple) facilement, sans devoir faire de changements ailleurs dans le code.

[Jeane]

Est ce que tu ne pourrais pas plus simplement stocker la valeur renvoyée précédemment par "num()" dans chaque instance de Material sous une variable num ?

Cela s'appèlle faire de la pré-calculation de fonctions : on pré-calcul les valeurs connues de retour de fonctions en début (ou en cours) de programme et puis on y accède directement dés que l'on en à besoin.

En fait la valeur num s'applique a un Material donne et a un Noeud donne. De plus cette valeur change au cours du temps. Mon idee est de stockee pour chaque noeud la valeur num correspondant au 5 type de materiel (d'ou l'utilisation d'un vecteur)

[Jeane]

Ce qui est intéressant pour tester rapidement divers conteneurs c'est d'encapsuler les fonctionnalités désirées dans une classe, de cette façon on peut changer l'implémentation (std::map ou std::vector par exemple) facilement, sans devoir faire de changements ailleurs dans le code.

Je ne comprend pas bien se que tu me propose de faire. Peux-tu developper un peu s'il te plait. Qu'entend-tu par "encapsuler les fonctionnalités désirées dans une classe"

Merci

[mchk0123]

En fait la valeur num s'applique a un Material donne et a un Noeud donne. De plus cette valeur change au cours du temps. Mon idee est de stockee pour chaque noeud la valeur num correspondant au 5 type de materiel (d'ou l'utilisation d'un vecteur)

Si j'ai bien compris (un peu plus de code aiderais à mieux comprendre) ça veut dire que mat_ est un std::vector() sur des instances de noeuds ???
Comme ça par hazard, si tu as au max 5 instances de Material, tu as combien d'instances max de Noeuds ?

Enfin ajoute le mot clef inline devant ta fonction num() :
c'est une optimisation du compilateur qui va recopier le code compilé de la fonction partout où elle est appellée, ainsi cela supprimera le temps passé par le processeur pour "sauter" jusqu'à la fonction num() ; c'est déjà ça.

[Jeane]

Si j'ai bien compris (un peu plus de code aiderais à mieux comprendre) ça veut dire que mat_ est un std::vector() sur des instances de noeuds ???
Comme ça par hazard, si tu as au max 5 instances de Material, tu as combien d'instances max de Noeuds ?

a la base mat_ est une map<Material *,Cells> et c un attribut de la classe noeud. Le nombre de noeud est fixe est vaut 10*10*10 ( c un qudrillage). Chaque noeud a un certain nombre de particules (ce nombre s'appel num ) d'un type de material donnee. Si il y a 0 particule du material au noeud i alors le material n'est pas dans la map sinon il y est est le nombre de particule est socker dans cells.num.

Enfin ajoute le mot clef inline devant ta fonction num() :

Je pensais que cela etait utile uniquement pour les fonctions tres simple non?

[mchk0123]

a la base mat_ est une map<Material *,Cells> et c un attribut de la classe noeud. Le nombre de noeud est fixe est vaut 10*10*10 ( c un qudrillage). Chaque noeud a un certain nombre de particules (ce nombre s'appel num ) d'un type de material donnee. Si il y a 0 particule du material au noeud i alors le material n'est pas dans la map sinon il y est est le nombre de particule est socker dans cells.num.

Ce que j'ai encore du mal à voir c'est si tu as 1 map en global ou bien 1 map pour chaque noeud.

Je pensais que cela etait utile uniquement pour les fonctions tres simple non?

Ca n'a rien à voir. Dans ton cas ca ne peut que faire du bien à la vitesse de ton programme.

[Jeane]

Ce que j'ai encore du mal à voir c'est si tu as 1 map en global ou bien 1 map pour chaque noeud.

1 map pour chaque noeud

Dans ton cas ca ne peut que faire du bien à la vitesse de ton programme.

J'ai deja essayer ca ne change pas la vitesse d'execution

[mchk0123]

Bon déjà avoir 1000 tables de hachages de tailles 5 c'est vraiment pas la meilleure façon de faire. Ca doit surement influer sur les faibles performances de ton programme.

[Jeane]

Justsment le choix de la map etait d'eviter de prendre trop de memoire (sa taille est compris entre 0 et 5 selon le nombre de materiel present a chaque noeud)

tu penses que ca prend trop de memoire? C ca qui ferait ralentir?
Du coup le choix de vecteur de int de taille 5 n'est pas non plus judicieux selon toi?

Merci

[mchk0123]

Envoi la totalité de ton code et la log de callgrind ... ca nous aidera pour t'aider.

[Jeane]

la totalite de mon code? Il est un peu ttrop gros pour ca je pense

Je voudrais juste savoir a quelle point stocker 1000 vecteur de taille 5 peuvent faire ralentir le prog?

encore merci

[mchk0123]

Envoi la totalité de ton code et la log de callgrind ... ca nous aidera pour t'aider.

la totalite de mon code? Il est un peu ttrop gros pour ca je pense

Bon envoi alors juste la log de callgrind ...

Ca aidera à comprendre quel type de ralentissement tu as ... unitaire, imbriqué, durée d'exécution, fréquence d'appel, ...

Pis ca marchait bien jusqu'à quel moment, depuis quand tu t'est rendue compte que les perfs étaient mauvaises ...

[Jeane]

desole je peux pa envoyer la log.

Je reprend un code en fait. C pas moi qui l'ai ecrit. Je n'ai pas l'ahbitude avec les optimisation de code.

en fait cette fonction est celle qui prend le plus de temps en "self" dans callgrind et qui est appele le plus de fois