Discussion :

[[Hugo]]

Bonjour,

J'ai une question relativement bas niveau : on a fait des comparaisons de performances entre des vlarray de double et des braves tableaux de double type C' pour constater des différences de perf d'un facteur 20, environ... Est-ce qu'il existe des fortes différences de performances entre différentes implémentations de valarray ? Le choix de cette classe est sa simplicité d'écriture pour les opérations vectorielles... Bref, sinon est-ce qu'il y a une raison fondamentale qui explique qu'une classe type valarry ou vector soit tellement plus lente ? Peut-on imaginer des solutions objets rapides, si tel est le cas ?

Merci beaucoup pour toute suggestion !

Marc

[Bousk]

Bonjour,

je n'ai jamais utilisé le valarray, mais concernant le vector
- il faut faire attention à sa taille, le remplir uniquement à coup de push_back ça entraîne de nombreux redimensionnements et copie de contenus
- l'utilisation de vector::at sera plus lente que operator[] puisque at ajoute des vérifications
- attention aux copies en paramètres de fonction => (const)&

[[Hugo]]

Bonjour Bousk,

Merci pour ta réponse ! En l'occurence, il s'agit de manipuler des tableaux de dimensions fixes (3, typiquement) et de calculer des braves produits scalaires, un peu de calcul matriciel, etc, mais les valarray avait été retenus pour leur simplicité syntaxique. Du coup, la question qu'on se pose est : est-ce qu'on peut imaginer construire nous-mêmes une classe qui fasse le boulot sans une telle perte de performances ou bien vaut-il mieux revenir aux types de base du C ?

Encore merci !

Marc

[Neckara]

Si valarray est un conteneur de la STL tu peux retrouver sa complexité pour différentes opérations.
Toutes les implémentations de valarray ont alors la même complexité.

Ensuite, pour les performances, comment avez-vous procédé pour les calculer? Une différence d'un facteur 20 me semble tout de même un peu gros.
Une mauvaise compréhension d'un conteneur peut entraîné à une mauvaise utilisation et donc à des pertes de performances.
Par exemple pour les vecteur, si on connait la taille du tableau, il faut réserver l'espace au début plutôt que de faire des push_back qui reallouera régulièrement plus d'espace comme l'a dit Bousk.


Sinon, je ne sais pas exactement quelle sera l'utilisation finale, mais je pense que le gain de temps au niveau de la programmation est beaucoup plus bénéfique qu'un gain de temps au niveau de l'exécution dans votre cas.

[Bousk]

La question est : pourquoi tu aurais quelque chose de plus lent ?
Une classe ce n'est jamais qu'un moyen d'aggréger les données entre elles. Une classe ne rendra pas l'application particulièrement plus rapide ou lente, ce sont avant tout les algos qui jouent sur ça.
Que tu aies

Code :

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

1
2
3
4
5
6
7
8
9
10
11
struct Vector {
  float values[3];
  Vector(float, float, float);
  void add(float);
};
int main()
{
 Vector v(0,1,2);
 v.add(4);
 return 1;
}

ou

Code :

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

1
2
3
4
5
6
7
void add(float*, float);
int main()
{
 float values[3] = {0, 1, 2};
 add(values, 4);
 return 1;
}

c'est identique.

Quant à la performance, il faut bien se demander si elle est nécessaire et à quel point. Puis où aller la chercher.
Est-ce que ça vaut vraiment le coup d'avoir un C-array ? et tous les problèmes qui peuvent en découdre.
Pourquoi pas un std::vector correctement utilsé ?
Ou un std::array si le C++11 est utilisable.

edit: pour du calcul matriciel j'utilise glm que j'ai découverte pour openGL.

[gbdivers]

@[Hugo]
Pour ce type de problématique, tu devrais passer par un lib existante (ou au moins voir comment elles sont implémentées)

Une technique indispensable à utiliser dans ce cas, c'est les expressions template (cf Abrahams)

[[Hugo]]

Ouahou, merci à tous pour vos réponses :-)

Ensuite, pour les performances, comment avez-vous procédé pour les calculer?

A la hache : on a pris un cas et comparé le temps d'exécution avec les deux implémentations.

Une différence d'un facteur 20 me semble tout de même un peu gros.

Indeed

Une mauvaise compréhension d'un conteneur peut entraîné à une mauvaise utilisation et donc à des pertes de performances.
Par exemple pour les vecteur, si on connait la taille du tableau, il faut réserver l'espace au début plutôt que de faire des push_back qui reallouera régulièrement plus d'espace comme l'a dit Bousk.

On est à taille fixe, ici, donc pas de problème de ce genre.

Sinon, je ne sais pas exactement quelle sera l'utilisation finale, mais je pense que le gain de temps au niveau de la programmation est beaucoup plus bénéfique qu'un gain de temps au niveau de l'exécution dans votre cas.

Euh, en fait on voudrait les deux : c'est pour faire du calcul massivement parallèle, à l'arrivée, et les perf sont vraiment importantes (voilà ce que ça donne quand des physiciens se mettent au C++, savent rien faire ces gens-là ;-) )

Quant à la performance, il faut bien se demander si elle est nécessaire et à quel point. Puis où aller la chercher.
Est-ce que ça vaut vraiment le coup d'avoir un C-array ? et tous les problèmes qui peuvent en découdre.
Pourquoi pas un std::vector correctement utilsé ?
Ou un std::array si le C++11 est utilisable.

Merci pour ces pistes, on va méditer tout ça. C++11 pourrait être utilisable... Quel serait le bénéfice, ici ?

edit: pour du calcul matriciel j'utilise glm que j'ai découverte pour openGL.

Je vais aller regarder ça. Pour le moment, tout l'algèbre est géré par lapack et on voudrait limiter le nombre de bibliothèques au minimum.

Pour ce type de problématique, tu devrais passer par un lib existante (ou au moins voir comment elles sont implémentées)

Une technique indispensable à utiliser dans ce cas, c'est les expressions template (cf Abrahams)

OK, merci, je vais aller gratter dans cette direction !

Merci encore à tous !

Marc