Discussion :

[kipgon]

Le voila

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
matrix &matrix::operator =(const matrix &A)
{
    if (this == &A)
    {
        return *this;
    }
    else
    {
        if (m_dim_i!= A.m_dim_i||m_dim_j!= A.m_dim_j)
        {
            this->~matrix();
        }
    }
 
    m_dim_i= A.m_dim_i;
    m_dim_j= A.m_dim_j;
 
    p = new double[m_dim_i*m_dim_j];
 
    for (int i = 0; i <m_dim_i; i++)
    {
        for (int j = 0; j <m_dim_j; j++)
        {
            p[m_dim_i*i+j] = A.p[m_dim_i*i+j];
        }
    }
 
    return *this;
}

Comme lors de mon test je ne l'utilisais pas je me suis dis que le problème ne venait pas de la !

[GrosLapin]

Quand tu fais A(3) ça donne dim_i = 3 dim_j = 1. Du coup à l'affichage tu affiches 0 3 6 alors que tu devrais afficher 0 1 2 du coup tu as que 0 de bon

[Bousk]

Bonsoir,

à vue de nez, je dirais que ça sent les copies non maîtrisées dans tous les sens.
Cela dit, on voit pas grand chose de l'implémentation et utilisation..

[Médinoc]

1. haraelendil a dit constructeur de copie, pas opérateur d'affectation
2. Cet opérateur d'affectation est une horreur. Tu devrais implémenter un constructeur de copie correct et utiliser l'idiome copy-and-swap quand les dimensions ne sont pas égales, ce sera beaucoup plus propre.

PS: Ton constructeur matrix(int dim_i) devrait être déclaré explicit.

[kipgon]

J'ai trouvé mon problème, en fait je remplissais ma matrice en faisant dim_i*i+j au lieu de dim_j*i+j ! Erreur idiote !

Sinon j'ai aussi ajouté le constructeur par copie que j'avais en effet oublié alors que je l'utilisais

Mais pour ce qui est du temps de calcul et bien c'est pire ! 88 secondes

[victor_gasgas]

Si tu veux savoir où se trouve tes goulots d'étranglement , utilise un profileur !

Mais je pense que si tu as du calcul instance , ton ralentissement doit provenir de tes allocations mémoire avec new. En effet, chaque fois que tu crées, copies
ou même multiplies deux matrices tu fais une allocation.

Le profileur de donneras de très bons résultats, mais si tu as des matrices de taille petites alors tout ton temps sera passé dans les allocations dynamiques sûrement !

P.S. Si tu connais tes tailles de matrice en avances, tu pourras peut être utiliser std::array qui alloue sur la pile. Et avec quelques expressions templates et un bon niveau d'optimisation tu sortiras touts les objets temporaires : ce sont quelques techniques utilisées dans les bibliothèques matricielles. Et si tu veux aller plus moins renseignes toi sur l'alignement mémoire, les instructions simd (c.f. Boost.simd qui nous tarde tous ), etc.

[jabbounet]

As-tu réellement besoin d'une allocation dynamique pour tes matrices?

Dans la plupart des application ou j'ai pu rencontrer ce type d'implémentation les matrices ne dépassaient pas une taille fixe...

Un new (allocation sur le tas) coute infiniment plus cher par rapport à une allocation sur la pile.

Après tu peux aussi essayer de porter certain principes utilisés pour les string comme le short string optimisation (SSO) ou le copy on write.

[Arzar]

+1 avec jabbounet
C'est vrai qu'il y a un truc pas clair dans le premier post, le PO dit qu'il est passé d'un style "qui utilise à l'origine des tableaux 2D" à sa prpore classe matrix, ce qui donnent l'impression qu'il est passé d'un truc du style double mat[10][10]; (sur la pile) à matrix mat(10, 10); (sur le tas avec new) ce qui serais évidemment une méga catastrophe.

[Médinoc]

S'il y a beaucoup de créations et destructions et que la taille est fixe, matrix<double, 10, 10> mat; pourrait être un meilleur choix en effet.

[Joel F]

(c.f. Boost.simd qui nous tarde tous ), etc.

oh y a eu une beta y a 4 mois et y en a une aurte bientot :o

[kipgon]

Je suis effectivement passé d'un

Code :

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

double mat[10][10]

à un

Code :

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

matrix mat(10,10)

avec les new

par ce que je ne connais pas à la compilation la taille des matrices que je vais utiliser (elle est entrée dans ma GUI).

Donc en fait c'est bien la déclaration en dynamique qui coute cher en temps et pas une erreur de programmation de ma part (je suis en train d'apprendre le c++ alors je me méfie de mes erreurs ^^).

Je pense que je vais donc "abandonner" puisque j'ai déjà codé une classe matrice avec des vectors, avec des tableaux 2D et avec des tableaux linéaire (dim_j*i+j) cela m'a permis de comprendre un peu le principe de tout cela et je vais me tourner pour les usages vers la bibliothèque boost je pense .

A moins que vous ayez une meilleure bibliothèque à me conseiller ?

[Joel F]

pas boost.ublas, les performances sont bof bof

[jabbounet]

Je suis effectivement passé d'un

Code :

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

double mat[10][10]

à un

Code :

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

matrix mat(10,10)

avec les new

par ce que je ne connais pas à la compilation la taille des matrices que je vais utiliser (elle est entrée dans ma GUI).

La matrice est entrée dans une GUI, si c'est manuel je pense que tu peux utiliser une taille fixe max de 100x100 par exemple et n'utiliser qu'une sous partie de la matrice.
je ne pense pas qu'un utilisateur entrera manuellement une matrice 100x100, ou alors il a du temps a perdre.

Autrement tu peux très bien avoir en interne dans ton objet une matrice de taille fixe alloué sur la pile pour gérer les matrices de petites taille et un pointeur pour gérer les matrices de grande taille (que te n'allouera que dans le cas ou l'utilisateur souhaite bosser avec des matrice dépassant la taille de la matrice alloué sur la pile), ce serait une espèce d'équivalent au short string optimisation (SSO) suggéré avant.


Autre possibilité, faire une pré-allocation à l'initialisation ton application et s'en servir comme cache pour stocker les matrices mais cela nécessite de bien gérer cet espace mémoire et ce sera de toute façon moins efficace que de mettre les matrices sur la pile.