Discussion :

[nicolas66]

Bonjour,

Je vais très prochainement terminer une bibliothèque de fonctions C sur les matrices creuses. Elle permet de gérer :

- L'addition matricielle
- La soustraction matricielle
- La multiplication matricielle
- La multiplication scalaire
- La transposition
- La sauvegarde et le chargement des matrices au format XML (librairie libxml2)

La librairie est disponible à cette adresse : http://nicolas.lerme.free.fr/Zephyr-1.0.0.zip.

J'ai réalisé quelques tests sur le temps de calcul de deux initialisations de matrices creuses (100 x 100) dans une même boucle accompagné d'une multiplication matricielle entre celles-ci.

Au final, je tombe à environ 0.35 sec de calcul. A vrai dire, je ne sais pas si c'est énorme et je voudrai avoir votre avis sur la question. Merci d'avance à ceux qui pourront m'éclairer


Nico.

[Matthieu Brucher]

Compare tes résultats avec les résultats sur les mêmes matrices avec Matlab et une implémentation style MTL ou Boost.uBlas.

Je ne saurai que trop te conseiller de faire les tests sur plusieursboucles afin d'éliminer les temps de rellocation, de lancement, ...

[Jedai]

Je crois que 0,35s c'est assez lent, maintenant ça dépend de tant de facteur que bon... Par exemple tu ne nous dis même pas les capacités de ta machine, alors si c'est un 486 c'est génial et si c'est un Pentium D 800 c'est très bof ! Si ta matrice creuse comporte trois coefficient c'est extrèmement nul (même sur le 486) mais si elle presque pleine c'est sans doute plus honorable....
L'emploi de XML pour stocker les matrices m'apparaît comme curieux, mais c'est un choix qui se respecte, pas très bon si on doit faire des calculs sur des très gros ensembles qu'on est obligé de mapper sur un fichier par exemple.

--
Jedaï

[nicolas66]

Compare tes résultats avec les résultats sur les mêmes matrices avec Matlab et une implémentation style MTL ou Boost.uBlas.

Je ne saurai que trop te conseiller de faire les tests sur plusieursboucles afin d'éliminer les temps de rellocation, de lancement, ...

Heu je n'ai pas Matlab sous la main mais je vais voir ce que cela donne avec la bibliothèque Boost.

Je crois que 0,35s c'est assez lent, maintenant ça dépend de tant de facteur que bon... Par exemple tu ne nous dis même pas les capacités de ta machine, alors si c'est un 486 c'est génial et si c'est un Pentium D 800 c'est très bof ! Si ta matrice creuse comporte trois coefficient c'est extrèmement nul (même sur le 486) mais si elle presque pleine c'est sans doute plus honorable....
L'emploi de XML pour stocker les matrices m'apparaît comme curieux, mais c'est un choix qui se respecte, pas très bon si on doit faire des calculs sur des très gros ensembles qu'on est obligé de mapper sur un fichier par exemple.

Ma machine est un Athlon 1500+ 1.33 GHz. Quant aux deux matrices creuses de départ de 100x100, elles sont pleines à rabord.

Pour ce qui est du XML, je l'ai employé car je trouve qu'il convenait bien dans ce cas, que les données sont bien organisées, que le fichier pourrait être ensuite importé dans une autre application et enfin pour ne pas avoir à écrire un parser bidon sur un fichier texte . En revanche, il est clair que le temps de parsing augmente rapidement en fonction de la taille de la matrice ...

[Matthieu Brucher]

Si tes matrices creuses sont pleines, c'est pas génial, autant utiliser des matrices pleines dans ce cas.

[progfou]

Matlab, scilab ou octave .

Ca fonctionne pareil mais c'est gratuit !

[nicolas66]

Si tes matrices creuses sont pleines, c'est pas génial, autant utiliser des matrices pleines dans ce cas.

Je comprends ta remarque mais je souhaitais simplement voir ce que ca donnait si mes matrices creuses étaient pleines et avoir un avis sur le temps de calcul lors d'une multiplication matricielle. C'est clair que ya pas trop d'intérêt à les utiliser dans ce cas-là .

Sinon j'ai regardé du côté de Boost et je viens de m'apercevoir que l'opérateur de multiplication matricielle n'a pas été écrit. Je vais tenter de l'écrire moi-même.

Matlab, scilab ou octave .

Ca fonctionne pareil mais c'est gratuit !

Scilab ou octave sont-ils suffisants pour ce que je souhaite faire ?

[Matthieu Brucher]

Il existe bien, c'est juste pas un produit avec *, je crois. Regarde sur prod()

[nicolas66]

Il existe bien, c'est juste pas un produit avec *, je crois. Regarde sur prod()

Arf merci, ca prouve que j'avais pas assez bien cherché

Bon concernant les tests, j'ai utilisé des matrices creuses de taille 100x100 aussi et j'ai effectué une multiplication matricielle. Le temps de calcul donne 10 secondes et des poussières. Voici le code de test pour Boost :

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
 
#include <iostream>
#include <cstdlib>
#include <ctime>
#include <boost/numeric/ublas/matrix_sparse.hpp>
#include <boost/numeric/ublas/io.hpp>
 
using namespace boost::numeric::ublas;
 
 
void InitRandom()
{
    srand(time(NULL));
}
 
float Random( float Min, float Max )
{
    return (rand() / (float)(RAND_MAX) * (Max - Min)) + Min;
}
 
int main( int argc, char ** argv )
{
    mapped_matrix<float> m1(100, 100), m2(100, 100), m3(100, 100);
    InitRandom();
 
    for( unsigned i=0; i<m1.size1(); ++i )
    {
        for( unsigned j=0; j<m1.size2(); ++j )
        {
            m1(i, j) = Random(-5.0, 5.0);
            m2(i, j) = Random(-5.0, 5.0);
        }
    }
 
    m3 = prod(m1, m2);
 
    return EXIT_SUCCESS;
}

[Matthieu Brucher]

Donc c'est bien pour toi, si j'ai bien compris Tu mesures bien juste le temps de la multiplication ?
Il faudrait tout de même que tu fasses plusieurs centaines de multiplications pour voir une meilleure estimation de la vitesse.

[nicolas66]

Heu non je mesure le temps complet d'exécution global du programme sachant que je fais un peu près les mêmes opérations (initialisations + multiplication). Comme tu le dis, il serait préférable de mesurer uniquement le temps de calcul de la multiplication mais je ne sais trop comment faire en C / C++.

[Matthieu Brucher]

Tu fais une boucle avec n fois ta multiplication, un time() avant, un time() après, un difftime() pour mesurer la différence, et c'est bon.

[nicolas66]

Bon voici les résultats du bench pour 10 multiplications successives entre deux mêmes matrices de taille 100x100 :

- Ma librairie -> environ 2 secondes
- Bibliothèque Boost -> environ 121 secondes

[Charlemagne]

Sur des matrices carrées pleines 100x100 de floats, la librairie ATLAS fait environ 2500 multiplications par seconde (P4 2.6Ghz).

Mais pour tester le potentiel d'une librairie de multiplication matricielle, il vaut mieux tester sur tout un panel de tailles différentes, et si possible grandes: de (100x100) à (1000x1000) par exemple.

[Jean-Marc.Bourguet]

Je ne sais pas tres bien quel genre de commentaires tu desires. Voici ce qui m'a frappe apres avoir survole la doc.

Le principal interet a faire soi-meme une bibliotheque de calcul matriciel, c'est me semble-t'il d'apprendre a etudier l'aspect numerique (stabilite, propagation des erreurs, ...) des choses. Si on a une application en vue, l'utilisation d'une bibliotheque existante eprouvee (et boost la ne me semble pas convenir malgre le respect que je leur porte pour d'autres domaines) me semble etre la seule approche possible sauf a vouloir ameliorer l'existant, mais dans ce cas, on n'a pas besoin de demander des commentaires sur un forum aussi peu specialise que developpez.com.

Hors dans la documentation que j'ai survolee, il n'est pas question du tout de cet aspect.

[nicolas66]

Je souhaitais simplement avoir un avis sur le temps de calcul d'une multiplication matricielle pour savoir s'il était bon ou pas de se lancer dans une série d'optimisations.

Voici ce qui m'a frappe apres avoir survole la doc.

Tu parles de la doc générée par doxygen ?

Le principal interet a faire soi-meme une bibliotheque de calcul matriciel, c'est me semble-t'il d'apprendre a etudier l'aspect numerique (stabilite, propagation des erreurs, ...) des choses.

Heu là, je ne vois pas trop comment je pourrai étudier ce genre de choses. Menfin je ne sais pas si ca intéresserait mes profs vu que c'est simplement un projet bidon de fin d'année de licence 3 ...