Discussion :

[harsh]

Bonjour,

Quand je lis la FAQ C++, je vois que la fonction resize appliquer sur un vector d'entier réinitialise les entrees a 0 (en plus de correctement mettre le tableau aux bonnes dimension)

Comme dans mon cas, je dois reinitialiser mon vector de double a 0 a chaque fin de boucle, je met un resize (taille du vector)... Mais que neni, il ne me reinitialise rien du tout. Je suppose donc que la fonction teste la taille du vector, et que dans le cas ou elle est bonne, il n'y touche pas.

1) Est ce exact ?
2) Quelle est la maniere la plus propre et la plus rapide de remettre tout les elements d'un vector de double a 0, une boucle ?

Merci

[Swoög]

resize mets à 0 pour les nouvelles valeurs seulement

le mieux est certainement de faire un clear() [vidage] avant le resize

[harsh]

Oui mais faire un clear remet la taille a zero. La memoire est elle alors desallouée?

Si oui, une simple boucle sur les element ne serait elle pas plus efficace?

[Swoög]

pas forcément, à toi de tester...

Il ne me semble pas que la mémoire soit désallouée... mais ça dépend de l'implémentation (donc du compilateur)...

[Matthieu Brucher]

Le plus simple, c'est d'utiliser

Code :

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

std::fill(vecteur.begin(); vecteur.end(); 0.);

[Swoög]

Ah !

Merci Milles, je savais bien qu'il y avait une fonction spéciale, mais je n'arrivais plus à m'en souvenir...

par contre je dirais plutôt :

Code :

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

std::fill(vecteur.begin(), vecteur.end(), 0.);

[PS : pour le 0. la conversion est pas automatique ?]

[harsh]

... Justement, c'est la question que j'avais zappée (la derniere a ce sujet, promis), quel est le comportement de fill (), une boucle standard, ou est-ce un peu plus malin (si c possible)?

Merci

[Matthieu Brucher]

Oui, ',' ) la place de ';'
C'est un peu plus malin parce que si tu fais l'opération toi-même, tu ferais qqch du genre :

Code :

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

for(it = vecteur.begin(); it != vecteur.end(); it++)

Sans faire attention, et là il y a un temporaire supprimable + n-1 appels à une fonction, par exemple.
Pour la conversion implicite, je préfère ne pas m'y fier -> si tu fais la même chose avec std::accumulate, t'es mal, il n'y a _PAS_ de conversion, dans aucun cas...

[harsh]

merci

[Jan Rendek]

Le plus rapide c'est de le traiter comme un tableau.

Code :

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

1
2
3
4
 
vector<double> vect;
...
memset(&vect[0], 0, vect.size()*sizeof(double));

[Jean-Marc.Bourguet]

Le plus rapide c'est de le traiter comme un tableau.

Code :

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

1
2
3
4
 
vector<double> vect;
...
memset(&vect[0], 0, vect.size()*sizeof(double));

Ca ne fonctionne que si le format des flottants coopere.

Ce n'est pas sur que ce soit plus rapide que l'utilisation de fill (qui sait par exemple que les donnees sont alignees et un multiple de la taille des flottants). En fait j'en serait surpris (mais je ne serais pas surpris que memset soit bien optimise aussi).

[Jan Rendek]

Ca marche pour tous les types scalaires, un double ou flottant dont tous les bits sont à 0 est bien le nombre 0.0
Ensuite, en fonction du compilateur, le memset peut-être plus ou moins bien optimisé. S'il possède des redéfinitions utilisant des instructions étendues type SSE, c'est beaucoup plus rapide. Maintenant, clairement pour un tableau de 10 éléments ce n'est pas utile.

[Luc Hermitte]

* clear() ne récupère pas la mémoire. D'où la feinte avec le swap.

* Une SL peut détecter que le fill opère sur des types POD et donc appliquer des traitements intelligents à base de memset. On garde une écriture plus propre, plus simple, plus rapide à taper (OK, j'ai une macro ^Xbe qui rajoute des begin()-end() à mes containers), plus résistante aux changements de types (parce qu'une spec a décidé qu'il fallait remplacer les flottants par un type dont la comparaison utilise un epsilon).

[Matthieu Brucher]

Tiens, ça me fait penser qu'il y a un exemple de ce type dans boost avec has_trivial_assign

[Luc Hermitte]

N'est-ce pas ?
Je suis retombé dessus aujourd'hui quand je cherchais comment reconnaitre si l'opérateur << était défini pour un type -- et puis j'ai laissé tomber car je me prenais des ICE avec GCC 3.4.4.

[Jan Rendek]

Une SL peut détecter que le fill opère sur des types POD et donc appliquer des traitements intelligents à base de memset. On garde une écriture plus propre, plus simple, plus rapide à taper.

POD ou pas POD, l'algorithme 'fill' effectuera une copie valeur à valeur, et non la mise à zero d'une zone mémoire. Dans ce cas précis, ce sera toujours plus lent.
Maintenant, la rapidité du code n'est pas toujours le facteur premier de décision.

EDIT: Avec les type_traits de boost, il est effectivement possible d'obtenir le même résultat sans écrire explicitement le memset. Cependant, dans le cas précis où on manipule un tableau de double et que la remise à zéro est indentifiée comme dégradant les perfs, j'écrirais simplement le memset.

[Matthieu Brucher]

Et en plus, ça ne marche que si le compilo fournit à Boost les infos de ce type ou si on spécialise has_trivial_assign.
En fait, ce truc devrait être généralisé, ce n'est pas au programmeur "haut niveau" de se poser la question est-ce que je peux faire un memset ou pas !

[Luc Hermitte]

Il doit quand même bien y avoir un truc dans des SL.
Dans celle de GCC (pas la plus récente, en plus), j'ai un __copy_trivial qui fait un memmove. Pour fill, il semblerait qu'ils ne déclenchent le memset que pour les types de 1 octet -- ce qui quelque part est assez logique, hors du cas particulier du 0.

[Jan Rendek]

Il doit quand même bien y avoir un truc dans des SL.
Dans celle de GCC (pas la plus récente, en plus), j'ai un __copy_trivial qui fait un memmove. Pour fill, il semblerait qu'ils ne déclenchent le memset que pour les types de 1 octet -- ce qui quelque part est assez logique, hors du cas particulier du 0.

Ce n'est pas implanté dans la SL de gcc 4. Le gain de temps n'est dû au remplacement de l'assignation par un memcpy, mais par l'application du memset sur une plage mémoire comprenant tous les éléments du tableau.

En fait, ce truc devrait être généralisé, ce n'est pas au programmeur "haut niveau" de se poser la question est-ce que je peux faire un memset ou pas !

Oui et non, je suis tout à fait d'accord que la STL doit fournir la meilleur implémentation possible en fonction du type d'instanciation des conteneurs et que l'utilisateur doit utiliser préférenciellement des algos de 'haut niveau'.
Cependant quand la RaZ d'un tableau de double devient un point d'optimisation, on est dans un autre cadre. Dans ce cas, ce qu'on souhaite c'est un tableau, implémenté par un vecteur. Il est hors de question de le remplacer par un quelconque autre conteneur, et le d'autre partie du code seront spécifique à ce conteneur (resize, ou reserve probablement pour éviter les coût d'agrandissement). Ainsi, je ne vois pas l'intérêt de passer par un 'fill', 'copy' ou autre, dont l'implémentation est incertaine, alors que 'memset' fait exactement ce que je souhaite (d'ailleurs quand je bosse avec gcc, c'est mon memset à moi que j'appelle dans ce cas).