double[] vs valarray

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

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)&

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

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.

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:

---

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:

---

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.

@[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)

Ouahou, merci � tous pour vos r�ponses :-)

Citation:

---

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.

Citation:

---

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

---

Indeed

Citation:

---

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.

Citation:

---

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� ;-) )

Citation:

---

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 ?

Citation:

---

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.

Citation:

---

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

Parall�le r�seaux ? cluster ? multi thread ? gpu ?

au fait, tu as du code pour montrer comment tu alloues et fait les calculs ?

Citation:

---

Envoy� par [Hugo]

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

---

Plusieurs questions se posent alors :
- Avez vous essayer sur de tr�s grands tableaux pour obtenir des r�sultat coh�rent?
- Avez vous bien mesur� le temps syst�me et non le temps total ? (en effet un m�me algorithme peut �tre plus ou moins lent selon le nombre de processus actifs)
- Il aurait plut�t fallu comparer le nombre de cycle de votre CPU car le CPU adapte sa vitesse en fonction de son utilisation pass�e.
- Avez vous essay� sur un grand nombre d'essais et fait des moyennes ?
- �tes-vous s�r que vos impl�mentations �taient optimales ?
- Avez-vous bien compil� la solution "style C" en C++ et non en C ?

Bref, je pense qu'il ne faut pas trop ce soucier de ce "facteur 20".
Je sais qu'un vecteur est l�g�rement plus lent que l'�quivalent "style C" mais c'est plus que n�gligeable au dire de mon prof. de C++.


La seule chose qui importe vraiment, c'est la complexit� de vos algorithmes. On peut faire toutes les optimisations que l'on souhaite, une complexit� plus faible sera toujours meilleurs pour de gros calculs (� nuancer bien s�r).

La STL a l'avantage de fournir des algorithmes dont tu peux voir la complexit�.

glm est header-only (puisque template)

Citation:

---

Parall�le r�seaux ? cluster ? multi thread ? gpu ?

au fait, tu as du code pour montrer comment tu alloues et fait les calculs ?

---

Clusters et gros calculateurs, genre qui font p�ter les petaflops. Pas de GPU en perspective. Donc MPI, � coup s�r, peut-�tre threads et/ou openMP en plus... On va se r�galer.

Sinon, je suis out pour le moment, j'essaierai de poster des bouts de code demain.

Citation:

---

Plusieurs questions se posent alors :
- Avez vous essayer sur de tr�s grands tableaux pour obtenir des r�sultat coh�rent?

---

Les ex�cutions durent quelques minutes � une demi-heure sur nos petits benchmarks, qui finissent avec quelques dizaines de degr�s de libert�. Pour passer la centaine, il faut compter la journ�e... C'est un peu chronophage (d'o� la parall�lisation). Mais les tableaux dont on parle sont des vecteurs position, donc de taille 3.

Citation:

---

- Avez vous bien mesur� le temps syst�me et non le temps total ? (en effet un m�me algorithme peut �tre plus ou moins lent selon le nombre de processus actifs)
- Il aurait plut�t fallu comparer le nombre de cycle de votre CPU car le CPU adapte sa vitesse en fonction de son utilisation pass�e.
- Avez vous essay� sur un grand nombre d'essais et fait des moyennes ?

---

c'est mon coll�gue qui a fait, mais je le soup�onne de bien travailler... je v�rifierai, bonne question !

Citation:

---

- �tes-vous s�r que vos impl�mentations �taient optimales ?
- Avez-vous bien compil� la solution "style C" en C++ et non en C ?

---

Nos impl�mentations ne sont s�rement pas encore optimales (et �a va prendre quelques ann�es dans le meilleur des cas). Mais on aimerait r�gler ce "d�tail" qui co�te cher en r��criture quand on se plante. On a pas mal encapsuler les algo, je pense qu'on a une bonne granularit�, mais avant de passer en parall�le il vaut mieux �tre au clair sur la structure de donn�es, histoire de ne pas recoder le MPI tout les 36 du mois, c'est long et vraiment casse-pied. Pour ne pas dire que les bugs MPI...
Bien compil� C++, forc�ment, le code est globalement en C++. Ces petits tableaux ne sont que des donn�es membres d'objets plus gros.

Citation:

---

La seule chose qui importe vraiment, c'est la complexit� de vos algorithmes. On peut faire toutes les optimisations que l'on souhaite, une complexit� plus faible sera toujours meilleurs pour de gros calculs (� nuancer bien s�r).

---

Je suis bien d'accord ! Mais on aimerait �viter de devoir reprendre tous les messages MPI 100 fois, et donc mieux vaut ne pas trop se planter sur ce genre de d�tails non plus.

Encore un grand merci � tous !!

Marc

Plusieurs remarques en vrac :
* pour la partie structure des donn�es et algo, on est bien d'accord : lors de la parall�lisation, vous devrez probablement adapter tout �a (un algo peut tout � fait �tre le plus efficace en mono thread et �tre moisi en parall�le)
* tu as d�j� de libs mpi pour la structure des donn�es
* le mot magique pour faire vos choix (structure, algo, optimisation, etc.) c'est profiling
* la diff�rence de perfs peut s'expliquer par les copies cach�s, les tests cach�s, les lutins aux grandes dents cach�s, bref, tout ce qui est cach� (chose que tu as moins de risque d'avoir avec les tableaux style C)
* je suppose (j'esp�re, si vous voulez travailler s�rieusement) que vous vous �tes rapproch� d'une �quipe de sp�cialistes en parall�lisme ?
Si c'est pas le cas, je vous conseille fortement de le faire. Conna�tre les techniques, optimisations, outils, langages, etc. est un boulot � plein temps, vous allez faire des choix non optimaux si vous demander pas conseils.
Tu peux peut �tre contacter JoelF (http://www.lri.fr/membre.php?mb=1146)

Bon courage

Plusieurs piste :

- mpi implique des comms et ce sera trjrs le pr9bleme
- tableau. de taille fixe =std::array ensuite, les tableau de tableau ca rend le cache triste. pr�f�rez des tableaux 2d compact.

ensuite, gaffe au cache, aux copies, vectorisez etc .....

Bonjour,

Apr�s longue absence, merci pour vos r�ponses !! De fait, nous travaillons avec des gens de l'INRIA, mais ces questions ne sont finalement pas aussi �videntes qu'on aurait pu l'imaginer � l'origine... M�ditation in progress sur la base de vos suggestions. Je ne crois pas qu'on avait essay� les std::array !!

Marc

quelle equipe de l'INRIA ?

c'est jamais trivial l'optimisation et le parallelsime, ca se saurait :aie:

Il me semble avoir lui quelque part que le type qui a �crit les valarray les a a posteriori reni�s, tellement il trouvait �a mal foutu.

Sinon, Josuttis a �crit un chapitre en consultation libre � leur sujet.

Le labri, � Bordeaux. Quant � la parall�lisation... haha !! Je d�couvre (encore que pour le moment, ce n'est pas encore nous qui mettons la main dans le camboui, mais �a va venir).

oodni je crois avoir entendu la m�me histoire sur les valarray (que je n'ai pas choisis, pour ma part, et sur lesquels on est en train de revenir, je pense). Lemieux ne serait-il pas de les virer tout � fait ? Je ne sais pas s'ils sont tr�s utilis�s ?

Citation:

---

Envoy� par oodini

Sinon, Josuttis a �crit un chapitre en consultation libre � leur sujet.

---

Citation:

---

Envoy� par [Hugo

]oodni je crois avoir entendu la m�me histoire sur les valarray (que je n'ai pas choisis, pour ma part, et sur lesquels on est en train de revenir, je pense). Lemieux ne serait-il pas de les virer tout � fait ? Je ne sais pas s'ils sont tr�s utilis�s ?

---

Il me semble que le probl�me venait (un peu ? beaucoup ?) du fait que les calculs produisaient beaucoup de temporaires et de boucles cach�es, donc tr�s mauvais en terme de performances. D'apr�s le doc de Josuttis, ce point semble corrig�.
Peu �tre que du coup, cela facilitera son adoption ?