C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Perf operator[]          C++Talk.NET Forum Index -> C++ (French) View previous topic :: View next topic   Author Message benoit le callennec Guest Posted: Wed Jan 14, 2004 8:39 am    Post subject: Perf operator[] Bonjour, Je me demande s'il y a des differences de performances entre parcourir un std::vector avec un iterator ou simplement en utilisant l'operateur[] et si oui, de quel ordre? Merci d'avance, Benoit Back to top Alexandre Guest Posted: Wed Jan 14, 2004 12:18 pm    Post subject: Re: Perf operator[] "benoit le callennec" <benoit.lecallennec (AT) epfl (DOT) ch> a écrit dans le message de news:40050177$1 (AT) epflnews (DOT) epfl.ch... Quote: Bonjour, Je me demande s'il y a des differences de performances entre parcourir un std::vector avec un iterator ou simplement en utilisant l'operateur[] et si oui, de quel ordre? Merci d'avance, Benoit Normalement, la structure mémoire du vector doit lui garantir une perf équivalente avec [] qu'avec un itérateur. Ce qui, je crois, n'est pas le cas pour deque. Back to top ben_cal Guest Posted: Wed Jan 14, 2004 5:13 pm    Post subject: Re: Perf operator[] Alexandre wrote: Quote: Normalement, la structure mémoire du vector doit lui garantir une perf équivalente avec [] qu'avec un itérateur. Ce qui, je crois, n'est pas le cas pour deque. Ok, je vois. Merci beaucoup, Benoit Back to top kanze@gabi-soft.fr Guest Posted: Thu Jan 15, 2004 7:52 am    Post subject: Re: Perf operator[] benoit le callennec <benoit.lecallennec (AT) epfl (DOT) ch> wrote Quote: Je me demande s'il y a des differences de performances entre parcourir un std::vector avec un iterator ou simplement en utilisant l'operateur[] et si oui, de quel ordre? Tout dépend de l'implémentation et du compilateur, mais a priori : si operator[] est plus rapide, rien n'empêche à l'itérateur de l'utiliser. Donc, je dirais que dans une bonne implémentation, operator[] ne peut pas être plus vite que l'itérateur. Sauf qu'en mode debug, il y a plus de choses à vérifier avec l'itérateur. Dans l'ensemble, j'aurais une tendance à dire que le choix doit se faire plutôt sur la sémantique voulue, et non la vitesse d'une implémentation donnée. Si je veux itérer, j'utilise un itérateur ; si je veux accéder à un élément donné, à partir de son rang, j'utilise l'operator[]. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 Back to top Samuel Krempp Guest Posted: Thu Jan 15, 2004 2:34 pm    Post subject: Re: Perf operator[] le Thursday 15 January 2004 08:52, [email]kanze (AT) gabi-soft (DOT) fr[/email] écrivit : Quote: benoit le callennec <benoit.lecallennec (AT) epfl (DOT) ch> wrote in message news:<40050177$1 (AT) epflnews (DOT) epfl.ch>... Je me demande s'il y a des differences de performances entre parcourir un std::vector avec un iterator ou simplement en utilisant l'operateur[] et si oui, de quel ordre? Tout dépend de l'implémentation et du compilateur, mais a priori : si operator[] est plus rapide, rien n'empêche à l'itérateur de l'utiliser. Donc, je dirais que dans une bonne implémentation, operator[] ne peut pas être plus vite que l'itérateur. Sauf qu'en mode debug, il y a plus de choses à vérifier avec l'itérateur. quand j'ai fait des mesures sur une boucle presque vide, la principale différence de temps (jusqu'à un facteur 2 en gros, IIRC) vient de la façon dont on teste la fin de boucle : for(; it != v.end(); ++it) *it .... plus lent que : Iter vend = v.end(); for(Iter it=v.begin(); it != vend; ++it) *it ... qui est vraiment sans différence significative avec sz = v.size(); for(size_t i=0; i v[i] ... C'est dire à quel point l'itération elle même est rapide, et que v[i] / ++i vs *it / ++it a vraiment peu (ou pas) d'impact mesurable. (faire une copie locale de end() / size() peut avoir des conséquences - si v est modifié dans la boucle par exple. J'ai remarqué que le compilo en général ne fait pas de lui même cette optimisation. D'ailleurs à propos des optimisations permises au compilo : si il est sûr que le contenu de la boucle ne va pas changer le résultat de size() (ou end()) des appels suivant, il a le droit d'utiliser en fait une copie locale, non ? Et pour ça, la possibilité éventuelle de threads concurrents n'a pas à être prise en compte, c'est à l'utilisateur de thread de s'en soucier, c'est bien ça ?) -- Sam Back to top kanze@gabi-soft.fr Guest Posted: Fri Jan 16, 2004 7:41 am    Post subject: Re: Perf operator[] Samuel Krempp <krempp (AT) crans (DOT) truc.en.trop.ens-cachan.fr> wrote Quote: le Thursday 15 January 2004 08:52, [email]kanze (AT) gabi-soft (DOT) fr[/email] écrivit : benoit le callennec <benoit.lecallennec (AT) epfl (DOT) ch> wrote in message news:<40050177$1 (AT) epflnews (DOT) epfl.ch>... Je me demande s'il y a des differences de performances entre parcourir un std::vector avec un iterator ou simplement en utilisant l'operateur[] et si oui, de quel ordre? Tout dépend de l'implémentation et du compilateur, mais a priori : si operator[] est plus rapide, rien n'empêche à l'itérateur de l'utiliser. Donc, je dirais que dans une bonne implémentation, operator[] ne peut pas être plus vite que l'itérateur. Sauf qu'en mode debug, il y a plus de choses à vérifier avec l'itérateur. quand j'ai fait des mesures sur une boucle presque vide, la principale différence de temps (jusqu'à un facteur 2 en gros, IIRC) vient de la façon dont on teste la fin de boucle : for(; it != v.end(); ++it) *it .... plus lent que : Iter vend = v.end(); for(Iter it=v.begin(); it != vend; ++it) *it ... qui est vraiment sans différence significative avec sz = v.size(); for(size_t i=0; i v[i] ... C'est à peu près ce que j'ai trouvé aussi. C'est un peu compréhensible, aussi. Quote: C'est dire à quel point l'itération elle même est rapide, et que v[i] / ++i vs *it / ++it a vraiment peu (ou pas) d'impact mesurable. J'imagine que c'est le cas sur la plupart des machines et avec la plupart des compilateurs. Quote: (faire une copie locale de end() / size() peut avoir des conséquences - si v est modifié dans la boucle par exple. J'ai remarqué que le compilo en général ne fait pas de lui même cette optimisation. En principe, il pourrait, dans la mésure qu'on n'appelle pas d'autre fonction dans la boucle, ou que le vector n'est pas visible par ailleurs. Dans la pratique, c'est une optimisation qui exige pas mal d'effort de la part du compilateur (au moins qu'il a une connaissance explicite de vector). Dans le cas où on est dans une fonction, et le vector a été passé comme paramètre en référence (ou qu'il s'agit d'une fonction membre et qu'il soit membre de la classe), il faudrait même un analyse extensif entre-module -- je ne connais pas de compilateurs actuellement qui le font. Quote: D'ailleurs à propos des optimisations permises au compilo : si il est sûr que le contenu de la boucle ne va pas changer le résultat de size() (ou end()) des appels suivant, il a le droit d'utiliser en fait une copie locale, non ? Dès que le comportement visible du programme (les entrées/sorties et les lectures et les écritures des objets volatiles) ne change pas, le compilateur peut faire ce qu'il veut. En principe, donc, pas de problème. Dans la pratique, en revanche, sauf dans des cas les plus simple, il faut une analyse assez poussé. Quote: Et pour ça, la possibilité éventuelle de threads concurrents n'a pas à être prise en compte, c'est à l'utilisateur de thread de s'en soucier, c'est bien ça ?) En ce qui concerne la norme, dès qu'il y a plus d'un thread, il y a un comportement indéfini. Ensuite, c'est une question de ce que le vendeur a voulu garantir. Dans la pratique, ce que tu dis vaut bien pour Posix, et étant donné que l'interface de vector expose des références et des pointeurs à de la mémoire interne, je vois mal comment il pourrait en être autrement. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (French) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.