Discussion :

[xxiemeciel]

Bonjour,

je cherche des articles serieux sur les performances du C++ en particulier lorsqu'il faut faire des compromis entre performances et stabilité (ou maintenance).

Les performance de déréférences, du nombre de parametres, des appels de fonction, de la virtualité, des templates.

Cordialement
Vincent

[Selenite]

Tu me fais peur... Crois-tu qu'il y a un compromis à faire entre performance et stabilité ? Ah moins que tu travaille chez Microsoft ;-).

Plus sérieusement, la meilleure façon de savoir quelles sont les opérations coûteuses en les optimisations intéressantes, c'est de connaître un peu le langage assembleur de sa machine. Sans oublier, bien sûr, de savoir ce que fait le compilateur.

Tu comprendras alors (si ce n'est pas déjà compris) pourquoi :
- Une déréférence ne coute presque rien.
- Plus la taille des arguments est petite, mieux c'est.
- Un appel de fonction est un peu coûteux. Soigner l'inlining est très intéressant.
- La virtualité est un peu coûteuse car elle empèche l'inlining et oblige à des déréférencements en cascade.
- Les templates ne coûtent rien. C'est du tout bon. Juste des temps de compilations qui peuvent s'allonger.
- Les macros c'est pas mieux que les const int, que les pointeurs c'est pas mieux que les références, etc.

Et surtout tu comprendras pourquoi il faut mettre la partie la plus fréquente du if en première. Et ça, c'est vraiment essentiel.

Enfin, tu finira sans doute par comprendre (si ce n'est pas déjà compris) que avec 3Ghz et 1 Go de RAM sous le capot que le compromis doit être plus favorable à la maintenance qu'a la performance.

[Luc Hermitte]

Tu as un fil sur la rapidité en C++ il me semble.
J'avais donné un lien vers le document n1359 (brouillon) sur le site du commité de standardisation. Entre temps, il y a eu la version finale n1666.

Commence par ça. Cela éliminera les a priori et autres rumeurs qui ne manqueront pas de surgir dans ce fil de discussion. -- genre la virtualité qui ne coute pas plus que mettre en oeuvre le "branchage" retardé avec des façon plus ... C.

Ensuite, tu as les docs de tes compilos. Tous ne sont pas égaux devant les possibilités d'optimisations.

Mais dans tous les cas, ce sont la maintenance et la "sûreté" qui priment. Foncer dans un mur ne sert à rien.

[xxiemeciel]

Merci de vos reponses,

ca confirme en partie ce que je savais deja, cependant je travail sur des programmes assez ancien et le melange de code templates avec des codes non templates pose souvent de gros problemes de compatibilites (sinon j'aurais deja mis des templates partout ).

Au niveau des performances nous devons parfois faire un compromis, il est vrai que j'ai dit stabilité mais je pensais maintenance (on utilise le terme de stabilité pour dire qu'on remet des anciens code sous forme objet beaucoup plus simple a reutiliser et maintenir)

Enfin et c'est la sujet que je souhaitais aborder, certaines personnes de ma compagnie de la vieille ecole comme on dit nous pause souvent le probleme de la performance et prefere des tres grosses fonctions dans le style C a des designs objet facile a maintenir, reutiliser et ameliorer.

Donc je me demandais jusqu'a quelle point ces personnes avaient raison. Et si je pouvais trouver des metriques sur le sujet. Ca me donnera une base serieuse a montrer pour faire valoir le point de vu objet de la programmation au niveau des performances.

Cordialement
Vincent

[HRS]

Et surtout tu comprendras pourquoi il faut mettre la partie la plus
fréquente du if en première. Et ça, c'est vraiment essentiel.

avec ||, c'est vrai; mais avec && c'est l'inverse (mettre en 1er la partie
la moins fréquente)

[Selenite]

Et surtout tu comprendras pourquoi il faut mettre la partie la plus
fréquente du if en première. Et ça, c'est vraiment essentiel.

avec ||, c'est vrai; mais avec && c'est l'inverse (mettre en 1er la partie
la moins fréquente)

Je parlais en fait du if .. else ...
Les processeurs Athlon (et Pentium 3 ou plus aussi je crois) anticipent les sauts conditionnels. La règle d'anticipation est simple : un saut en arrière est toujours pris, en saut en avant n'est jamais pris. Donc il vaut mettre la partie la plus fréquente du if en premiere.

Ma remarque étant cependant à prendre comme une boutade, bien entendu. C'est bien la dernière chose à faire que de regardé ces choses là.

[Luc Hermitte]

Donc je me demandais jusqu'a quel point ces personnes avaient raison. Et si je pouvais trouver des metriques sur le sujet. Ca me donnera une base serieuse a montrer pour faire valoir le point de vu objet de la programmation au niveau des performances.

Je ne suis pas sûr .. Tu as consulté le document n1666 ? (3e entrée sous google)

[xxiemeciel]

Oui j'ai commencé a regarder le document n1666 mais pas en entier, je manque un peu de temps mais quand j'aurais parcouru les parties qui m'interesse je viendrais donner des commentaires.

Vincent

[xxiemeciel]

c'est un bon article, tres complet. Ca devrais suffire a repondre a certaines questions sur les performances qui n'arrete pas de revenir.

Merci
Vincent

[Luc Hermitte]

C'est un document qui a le mérite d'être plus objectif que les plus folles rumeurs que l'on peut lire ici ou là.

Après, tout ce qui reste, c'est la doc de ton compilo (genre pour savoir sous quelles conditions tu pourras profiter du RVO) et des benchmarks persos pour vérifier le prix de telle ou telle autre fonctionnalité sous ta platerforme.

Dans une thématique proche (quels styles de progammation et quels langages adopter), il y a un document sympa sur objet mentor -> "Why are you still programming in C" (ou un nom approchant).

[xxiemeciel]

C'est un titre prometteur,

En tout cas maintenant je vais pouvoir faire le point entre les prejugés et la réalité

Vincent