Discussion :

[yan]

Ah ouais, ce qui se passe c'est que j'avais enlevé les vérifications que rajoute visual par défaut même en release (_SECURE_SCL=0). Comme ça les 3 boucles génèrent le même code asm et sont donc aussi rapides.

En laissant les vérifications, par contre, for_each est un peu plus rapide car les vérifications de validité des itérateurs sont effectuées qu'une fois au début de la fonction (sur begin et end) pour for_each mais une fois par itération (sur it) pour les deux boucles.

Ceci explique cela, merci.
A mon avis visual ne doit pas être le seul compilateur qui fait cela.
Malgré tout, je resterais sur l'idée de privilégier les algo pour être tranquille.

[yan]

je viens de tester le code corrigé sous mingw.
pour un vector et une liste, for_each est 50% plus rapide que la boucle for...
j'ai beau vérifier, le résultat ne change pas.
Quelqu'un aurais un explication?


Avec visual express 2008, c'est pareil sans désactiver les sécurités.

[loufoque]

Mouarf, des tests de perf avec le mode debug de ta bibliothèque standard activé...

Les benchmarks ça se fait avec toutes optimisations activées. (-O3 -march=native -fomit-frame-pointer -DNDEBUG pour GCC, par exemple)

[yan]

Mouarf, des tests de perf avec le mode debug de ta bibliothèque standard activé...

Les benchmarks ça se fait avec toutes optimisations activées. (-O3 -march=native -fomit-frame-pointer -DNDEBUG pour GCC, par exemple)

J'en suis pas encore à faire des bench en debug...
Pour mingw, j'utilise code::block.
Par defaut, il utilise -02.
J'ai modifié pour qu'il utilise -03 et -fomit-frame-pointer et défini DNDEBUG
Ça ne change rien...

[loufoque]

Pour MSVC, il faut désactiver SECURE_SCL machin truc.

[yan]

Je veins d'essayer avec g++ 4.1 sous ubuntu, les temps sont pareil entre les trois methode.

Y as que mingw...Peut être parce qu'il est basé sur gcc 3??

[JolyLoic]

Pour MSVC, il faut désactiver SECURE_SCL machin truc.

Hélas, c'est une variable que Microsoft préconise de garder, même en release. Et donc on risque d'être obligé de l'utiliser dans des projets (qui utilisent des bibliothèques externes pré-compilées avec ce flag), alors qu'il est nocif sur les performances. L'utiliser pour des benchs ne me semble donc pas idiot.

Je me demande ce qui a motivé Microsoft à brider les performances de son compilateur, surtout quand on sait l'influence que des benchs de ce type peut avoir sur les développeurs C++.

Le pire, c'est que sur un prétexte de sécurité, cette option va pousser les gens n'ayant pas le choix à utiliser des tableaux à la C plutôt que des vectors, car la différence de perfs est significative, et donc à choisir une solution bien moins sûre...

[loufoque]

C'est comme décider de ne pas désactiver les asserts (définir NDEBUG) en release. Certains ne le font pas, tout simplement parce que le code n'a pas été suffisamment testé pour montrer que ces assertions n'arrivent jamais.

[ooxoo]

merci pour les tests, c'est intéressants.

Si je comprends bien le _SECURE_SCL vérifie à chaque appel de l'iterator, que celui n'a pas dépassé les limites du conteneur, dans le cas d'une boucle for.
Dans le cas d'un for_each, le compilateur ne fait pas cette vérification.
c'est ça?

[yan]

Si je comprends bien le _SECURE_SCL vérifie à chaque appel de l'iterator, que celui n'a pas dépassé les limites du conteneur, dans le cas d'une boucle for.
Dans le cas d'un for_each, le compilateur ne fait pas cette vérification.
c'est ça?

En gros oui.
Le for_each utilise une autre forme de l'iterateur et le compilateur ne fait le test que pour le premier et le dernier iterateur avant la boucle.

Après, il y as l'optimisation qui peut changer la donne.
Sous visual 2008 express, le code corrigé donne les même perf pour les trois boucle sur une list ou un vector.