intérêt de boost::multi_array ? - C++ - Programmation
Marsh Posté le 14-04-2007 à 18:26:48
Spa forcément la meilleure solution, mais pour te réduire l'écriture d'empilement de vecteurs tu peut faire ça :
Code :
|
Evidemment faut voir si ton compilo supporte bien la spécialisation partielle, j'utilise que gcc ici, je peut pas test
Après peut-être que les valarray peuvent t'aider aussi...
Marsh Posté le 14-04-2007 à 19:50:14
Et en quoi le couple classe + conteneur classique serait inapproprié au problème ?
Marsh Posté le 14-04-2007 à 20:36:00
el muchacho a écrit : Et en quoi le couple classe + conteneur classique serait inapproprié au problème ? |
Ce ne serait pas inapproprié à strictement parler, mais je trouverais quand même assez bizarre d'ajouter une classe à mon code qui encapsulerait juste un tableau multidimensionnel. Si les dimensions n'étaient connues qu'à l'exécution, je ne dis pas (je l'ai déjà fait), mais là... Ajouter des conteneurs propriétaires qui n'encapsulent que l'existant me paraît à éviter. Je n'aime pas trop tomber sur des codes où les gens ont commencé par redéfinir des class Queue et des Pile, par exemple.
0x90 a écrit : Spa forcément la meilleure solution, mais pour te réduire l'écriture d'empilement de vecteurs tu peut faire ça : |
Pas mal du tout. Je n'ai jamais écrit de templates récursifs, je ne risquais pas de trouver ça tout seul. Ta solution m'évite aussi de définir les N types avec des noms comme 'tabNDims', 'tab(N-1)Dims', etc..., ce qui aurait été très moche. Merci !
Sinon, j'ai réfléchi et faut avouer qu'il y a quelques trucs pas mal dans boost::multi_array. Genre, on peut définir des vues sur un tableau. Par exemple "vue à 2 dimensions, où les indices 2,3 et 4 de mon tableau X à 5 dimensions sont fixés et où je ne prends que les éléments d'indices pairs sur la 5ème dimension" : comme les itérateurs sont définis sur les vues, c'est compatible avec les algos de la STL et je peux très bien trier ces éléments par ordre croissants en une ligne avec un std:sort, etc etc... Bref, l'intérêt est plutôt de se conformer au modèle de programmation générique de la STL, ce qui ne m'intéresse pas dans le cas présent.
Marsh Posté le 15-04-2007 à 02:34:41
boulgakov a écrit : Ce ne serait pas inapproprié à strictement parler, mais je trouverais quand même assez bizarre d'ajouter une classe à mon code qui encapsulerait juste un tableau multidimensionnel. Si les dimensions n'étaient connues qu'à l'exécution, je ne dis pas (je l'ai déjà fait), mais là... Ajouter des conteneurs propriétaires qui n'encapsulent que l'existant me paraît à éviter. Je n'aime pas trop tomber sur des codes où les gens ont commencé par redéfinir des class Queue et des Pile, par exemple. |
Non, ce que je dis, c'est qu'à première vue, si on prend ton exemple de tuple hétérogène (un prix qui dépend du pas de temps, du client, du fournisseur, du produit et du pays), on peut/doit faire une classe de ça. Et on met les objects instanciés dans un conteneur standard.
Marsh Posté le 15-04-2007 à 03:45:56
el muchacho a écrit : Non, ce que je dis, c'est qu'à première vue, si on prend ton exemple de tuple hétérogène (un prix qui dépend du pas de temps, du client, du fournisseur, du produit et du pays), on peut/doit faire une classe de ça. Et on met les objects instanciés dans un conteneur standard. |
Euh... bah non. J'ai pas dû être clair. C'est un code numérique, hein, j'ai un peu instancié pour que ça parle aux gens mais mon temps, mes clients,... ce sont juste des indices entiers. Pourquoi je créerais une classe ?
Code :
|
Pas super utile, voire même nuisible.
Marsh Posté le 15-04-2007 à 13:01:31
Mais non. C'est du n'importe quoi, là.
Ce à quoi je pensais, c'était plutôt qq chose comme:
Code :
|
par exemple.
Mais si ça se trouve, ça n'est pas ce que tu veux faire. Tu veux p-ê faire des recherches sur d'autres colonnes ? Pour l'instant, tout ce que je vois, c'est un problème extrêmement mal modélisé, l'équivalent d'une base de données avec toutes les données en bordel dans une seule table, et donc une solution qui ne marchera probablement pas avec un nombre conséquent de données.
Mais comme tu n'es pas disert sur ce que tu veux réellement faire, on ne peut pas vraiment aider, on ne peut que faire des supputations.
Marsh Posté le 15-04-2007 à 13:07:14
ReplyMarsh Posté le 15-04-2007 à 13:48:59
Taz a écrit : On peut avoir ton code de benchmark ? |
Ouaip, avec plaisir, si ça se trouve je tire les mauvaises conclusions du mauvais test. J'ai la flemme de mettre au propre, par contre. Le test 1 dim et le test 2 dims se suivent dans le main(). En 2 dimensions, je sais que t'attaque toujours la diagonale de la matrice ce qui pourrait être un biais, mais j'ai fait quelques variantes et cela ne change rien.
Code :
|
Edit - Les résultats sur les 2 dimensions :
**
Moyenne STL : 0.0972
Moyenne C : 0.0828
Moyenne Boost : 1.0731
**
Marsh Posté le 15-04-2007 à 14:52:24
Code :
|
en nettoyant un peu et en simplifiant :
[1] STL 15.89
[1] C 15.88
[1] Boost 18.51
[2] STL 21.45
[2] C 20.45
[2] Boost 24.43
Marsh Posté le 15-04-2007 à 14:58:27
et pour la petite histoire, avec une allocation dynamique de tableau (vrai tableau contigüe), ça donne :
[2] STL 21.44
[2] C 20.42
[2] Ca 19.44
[2] Boost 23.51
Marsh Posté le 15-04-2007 à 15:20:59
petite analyse de l'assembler ppc du code précédent, et plus précisément sur la boucle :
Code :
|
On constate que les codes sont extrêment voisins quand ils ne sont pas rigoureusement identiques. La seule différence est sur le calcul d'index : tantôt des shift quand c'est possible, tantôt des multiplication.
Dans le test a 2D, cette différence slwi/mulli est la seule entre les méthodes STL et et C. La différence de vitesse de cette instruction se sent sur 10**8 exécutions.
Pour moi la différence est faible, le plus lent l'étant de 20% par rapport au plus rapide.
Marsh Posté le 15-04-2007 à 16:13:19
Taz a écrit : en nettoyant un peu et en simplifiant : |
J'ai dû instancier explicitement les fonctions pour que VC++ avale ton code
Code :
|
et j'obtiens :
[1] STL 9.985
[1] C 68.796 (Là, j'ai relancé plusieurs fois et même installé le "Service Pack" en désespoir de cause mais rien n'y fait)
[1] Boost 17.375
[2] STL 11.515
[2] C 10.235
[2] Boost 43.515
Conclusion 1 : mon problème vient du compilo, pas de multi_array. Conclusion 2 : j'ai tous les éléments et je n'ai plus qu'à prendre une option, on verra ça plus tard. Il fait quand même un poil beau dehors, je vais pas passer mon WE là-dessus.
Merci bcp !
Marsh Posté le 14-04-2007 à 17:24:39
Bonjour,
J'ai tout un tas de données qui se stockent dans des tableaux pleins à plusieurs dimensions (disons par exemple : un prix qui dépend du pas de temps, du client, du fournisseur, du produit et du pays).
Solution C :
Beurk. En outre il faut allouer et détruire, j'ai une vingtaine de types de données du même genre : impossible.
Solution STL :
Re-beurk. Allocation à peine plus chouette qu'en C.
Je précise qu'il y a plusieurs types de données différentes, certaines entières d'autres réelles, et pouvant dépendre de 0 à 5 dimensions. Mon exemple du prix ci-dessus correspond au "pire" cas.
Solution Boost :
Bien ! Problème : j'ai fait quelques tests sous VC++ 2005 (toutes optimisations à fond, "checked iterators" désactivés). Je fait des boucles pour stocker et lire 10^8 fois soit a) un rand() b) une constante.
* Résultats sur les rand() :
En 1 dimension (10 éléments), STL ~ Boost.
En 2 dimensions (10*10 = 100 éléments), Boost 2 fois plus lent que STL.
* Résultats sur 1 constante :
En 1 dimension, Boost 2 fois plus lent que la STL. Là OK, un conteneur multi-dimensions n'est pas forcément super adapté pour un tableau simple.
En 2 dimensions, Boost 8 fois plus lent que la STL Bon, si je teste avec 2*10^6 éléments, l'écart se ressert (Boost 3 fois plus lent) mais bof quoi.
Donc je ne comprends pas. boost::multi_array me semblait justement fait pour moi : données dont je connais a priori le nombre de dimensions mais pas la taille de chaque dimension + pas envie d'écrire des horreurs comme vector<vector<vector<... Quel est l'intérêt s'il m'explose mon temps de calcul ? Je ne suis pas en train de me défouler dessus, hein, je voudrais vraiment savoir à quoi sert cette librairie, j'ai sûrement raté quelque chose. En plus je peux écrire :
et garder les perfs de la STL + une syntaxe relativement concise.
Message édité par boulgakov le 14-04-2007 à 17:26:16