Discussion :

[IrmatDen]

Presque entièrement d'accord,
Juste une petite précision, l'encapsulation n'a pas d'impact sur la puissance d'optimisation du compilateur, ce n'est qu'un pur cloisonnement sécuritaire facilitant la maintenance. Au mieux ca rend la phase de compilation plus rapide mais pas le code exécuté.

A voir le post et le sujet (ou plutôt le fil ), j'ai la forte impression que JolyLoic parlé d'optim que le développeur apporte, pas d'optim amenées par la compilation

[mchk0123]

En effet (et par exemple) la création et la destruction d'objets plus ou moins polymorphes impliquent les appels respectifs à tous les constructeurs et destructeurs de tous les parents de l'objet en question mais aussi à ses propres méthodes de construction et de destruction...

Surement moins d'impact que tu ne le penses sur la différence C/C++.
Tu perd en temps d'appel entre les différents const./dest. mais c'est mineur sur les CPU d'aujourd'hui (bien moins qu'un branch misprediction).

Ce qui est sur c'est que si tu est accroc aux méthodes virtuelles, aux constructeurs de copies et que tu ne pratique jamais le passage d'objets par référence, ... aie aie aie ... Ca peut faire mal.

Donc je serais tenté de dire que plus tu utilises un langage abstrait, plus tu à de décisions (correctes) d'implémentation à prendre car tu auras toujours plus de combinatoire pour faire la même chose que si tu utilises un langage plus proche du bit code.

[zais_ethael]

Bon, je crois qu'on a tous compris que le C++ n'est pas lent en lui même et qu'un code C compilé avec un compilo C++ produira exactement le même résultat.
Je vais prendre un petit exemple:

Code :

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

1
2
3
4
5
6
7
int vecc[N];
vector<int> veccpp(N);
 
for(int i=0;i<N;i++)
   vecc[i]++;
for(int i=0;i<N;i++)
   veccpp.at(i)++;

A priori ces deux codes sont similaires, sauf que la fonction at() de vector vérifie systématiquement si la taille de vecteur et renvoie une exception si elle est dépassée. Donc si N=10 000, cela fera 10 000 vérifications inutiles puisque on sait très bien qu'on ne dépassera pas la taille de ce vecteur (oui, les gourous de la stl me diront qu'on peut utiliser l'opérateur [] qui ne fait pas cette vérification ou encore des itérateurs, mais c'est pour illustrer et j'avais pas d'autre exemple en tête ).
C'est inévitablement plus lent, c'est une des conséquences quand on fait des classes "super-safes, où tout est toujours libéré correctement, où rien ne peut jamais se retrouver dans un état incohérent à quelque instant que ce soit". Pour généraliser on pourrait même énoncer une loi du style: toute abstraction entraine une perte d'optimisation.
Ce n'est pas forcément lié au C++, pour reprendre notre exemple il existe aussi des biblios pour faire des tableaux plus sécurisés en C. Le C++ se distingue juste parceque cela est plus facile, plus naturel.

[mchk0123]

Donc je serais tenté de dire que plus tu utilises un langage abstrait, plus tu à de décisions (correctes) d'implémentation à prendre car tu auras toujours plus de combinatoire pour faire la même chose que si tu utilises un langage plus proche du bit code.

Je précise ce que j'ai dit :

Plus un langage à une puissance d'expression etendue (ce qui le cas de C++ par rapport à C, car il ajoute des concepts sans en enlever), plus il y à de combinaisons possible pour implémenter un processus donnant le même résultat.
Du coup on à plus de décisions correctes à prendre ...

... Donc plus de probabilitée d'écrire du code peu optimisé si on y fait pas attention.

[zais_ethael]

Je précise ce que j'ai dit :

Plus un langage à une puissance d'expression etendue (ce qui le cas de C++ par rapport à C, car il ajoute des concepts sans en enlever), plus il y à de combinaisons possible pour implémenter un processus donnant le même résultat.
Du coup on à plus de décisions correctes à prendre ...

... Donc plus de probabilitée d'écrire du code peu optimisé si on y fait pas attention.

Vraiment bizarre ton raisonnement. J'ai beau y réfléchir, je ne peux qu'en arriver à la conclusion inverse. Plus un langage a d'expressivité, moins il faut de lignes pour résoudre un problème. Moins il faut de lignes, moins il y a de combinaisons possibles. Donc moins de décisions à prendre.
Et qui dit moins de décisions à prendre dit, non pas moins de probabilité d'écrire du code peu optimisé, mais moins de probabilité de faire une erreur, qui fera que le programme ne fonctionne pas.
Je ne vois pas le rapport direct entre ton raisonnement et l'optimisation...

[mchk0123]

Je ne parles pas de capacité offerte par le langage d'écrire le meilleur code optimisé (auquel cas le C++ est meilleur que le C) mais bien de probabilité pour tomber par hazard sur la meilleur implémentation d'un processus.

Plus un langage à une puissance d'expression élevée, plus cela te permet d'écrire des programmes longs et compliqués.
Donc à connaissance 0 en optimisation, si tu est débutant et que tu écris un programme simple en ASM tu à plus de chance qu'il soit performant.
Maintenant, toujours à connaissance 0 optimisation, si tu est débutant et que tu écris un programme complique en C++ tu à moins de chance qu'il soit performant.

Autrement dit, écrire de manière optimisée en C++ nécessite un degrée de connaissance, attention et expérience supérieur.

Ton exemple sur std::vector et le bound checking était trés bon.

[mchk0123]

Explication un peu plus clair de ma part :

Moins il faut de lignes, moins il y a de combinaisons possibles.

Pas tout à fait. Pour un même problème à résoudre (par exemple multiplication de 2 matrices), si tu as à un langage à puissance d'expression supérieure, tu aura plus de manières possibles d'écrire la solution. Donc moins de probabilité de ... etc.

[Luc Hermitte]

Ce n'est pas le 0 connaissance en optimisation qu'il faut considérer, c'est le 0 connaissance dans le langage et les bibliothèques offertes.

Quelqu'un qui n'y connait rien en optim, mais qui connait Blitz++ (/boost.ublas / ATLAS / ...) écrira des choses plus performantes que le premier venu en assembleur. Il écrira même des choses plus performantes que quelqu'un qui croit s'y connaitre.

Je ne vois pas ce que prouve cet exemple sur les vecteurs non plus. Qu'il faut lire la documentation des fonctions que l'on utilise ? Cela a d'ailleurs été très bien dit. Les fonctions sécurisés en C ont également un sur-coût.
Ce n'est pas lié au langage! (le sujet du fil). C'est lié au bibliothèques utilisées. Si on ne lit les les doc, si on ne se renseigne pas sur ce qui existe, si on se croit meilleur que les autres et faisons dans le NIH, ... Cela fait plein de "si". Aucun de ceux-ci (de "si") n'est lié au langage. Et tous ces "si" là peuvent avoir des implications négatives sur la maintenabilité, la robustesse et les performances.

Oui le C++ est complexe. Oui il permet d'écrire des choses de plus de façons différentes. Des qui seront plus rapides, des qui seront moins efficaces. C'est comme le perl. Et alors ?

Il y a des risques bien plus importants que les perfs quand on n'apprend pas à ce servir de ces langages. A quoi bon foncer dans un mur?

[mchk0123]

Quelqu'un qui n'y connait rien en optim, mais qui connait Blitz++ (/boost.ublas / ATLAS / ...) écrira des choses plus performantes que le premier venu en assembleur. Il écrira même des choses plus performantes que quelqu'un qui croit s'y connaitre.

Raisonnement marketing et commercial. Tu peux donner des exemples de ce que tu avances ?

Oui le C++ est complexe. Oui il permet d'écrire des choses de plus de façons différentes. Des qui seront plus rapides, des qui seront moins efficaces. C'est comme le perl. Et alors ?

Que viens faire le perl ici ?

Il y a des risques bien plus importants que les perfs quand on n'apprend pas à ce servir de ces langages. A quoi bon foncer dans un mur?

Tu peux développer un peu ?...

[zais_ethael]

Ce n'est pas lié au langage! (le sujet du fil). C'est lié au bibliothèques utilisées. Si on ne lit les les doc, si on ne se renseigne pas sur ce qui existe, si on se croit meilleur que les autres et faisons dans le NIH, ... Cela fait plein de "si". Aucun de ceux-ci (de "si") n'est lié au langage. Et tous ces "si" là peuvent avoir des implications négatives sur la maintenabilité, la robustesse et les performances.

Moi ce que j'essaie de dire, c'est qu'on ne peut pas tout avoir. Un programme qui soit à la fois the plus rapide, the plus stable, the plus facile à maintenir ça n'existe pas.
La programmation en C++ veut qu'on essaie de s'abstraire le plus possible des taches ingrates, en C on est quand même obligé de s'en farcir pas mal. Mais cette abstraction a un cout, une gestion moins fine de ces taches, ce qui entraine un baisse de performance.
Programme + lent ne veut pas dire programmeur - bon ou biblio - bonne. Tout est question de choix, on peut très bien (et tout le monde le fait) laisser l'optimisation de coté pour privilégier la facilité de programmation et obtenir un gain de productivité, sinon tout le monde ferait de l'assembleur.

[epsilon68]

C'est aussi pour ca que Java et C# existe et que tout le monde quitte le C++

[zais_ethael]

Voila Mais bon on aura quand même toujours besoin de langages permettant un programmation très optimisée (programmation système, moteurs 3D, ect...)

[loufoque]

Les abstractions de C++ n'ont pas de coût particulier.

Et ce n'est pas en écrivant en assembleur que tu produiras du code optimisé. Le compilateur et les optimiseurs sont bien meilleurs pour générer de l'assembleur.

[Jean-Marc.Bourguet]

Donc à connaissance 0 en optimisation, si tu est débutant et que tu écris un programme simple en ASM tu à plus de chance qu'il soit performant.

Tu viens de montrer que tu n'as aucune connaissance d'optimisation en assembleur. Sur une machine moderne, il n'y a aucune chance qu'un code naïf soit performant. Et moderne de ce point de vue, ça commence au Pentium I.

[mchk0123]

Tu viens de montrer que tu n'as aucune connaissance d'optimisation en assembleur.

Si mais pour la compréhension des autres lecteurs tu peux développer un peu ? Et surtout, pour rebondir sur le sujet du post, est-ce que les compilateurs C et C++ savent bien tirer profit de toute la complexitée des CPUs modernes et de la gamme assez variée.

[Jean-Marc.Bourguet]

Si

Dans ce cas, pourquoi fais-tu une affirmation qui n'a probablement été vraie -- si elle l'a été -- qu'au tout début des langages compilés (qu'un débutant en assembleur a plus de chance de produire un programme performant qu'un débutant dans un langage compilé).

mais pour la compréhension des autres lecteurs tu peux développer un peu?

Les processeurs modernes tirent leur puissance de leur capacité à exploiter le parallélisme qu'il est possible d'extraire du flux d'instructions. Une partie du travail d'optimisation consiste à rendre le plus possible ce parallélisme visible.

Et surtout, pour rebondir sur le sujet du post, est-ce que les compilateurs C et C++ savent bien tirer profit de toute la complexitée des CPUs modernes et de la gamme assez variée.

Pour répondre à ta question, s'il y a une tâche que les ordinateurs font mieux que les hommes, c'est bien gérer des détails de ce genre -- surtout plusieurs fois après modification du programme ou pour des architectures ou des micro-architectures différentes. Depuis longtemps, pour battre un compilateur optimiseur, la technique n'est pas de chercher à faire mieux là-dessus -- ce qui est parfois possible sur des cas plus ou moins particulier -- mais, d'une part, de chercher à profiter de propriétés qui ne sont pas ou difficilement accessibles aux compilateurs (des propriétés globales) et d'autre part de ne pas respecter des contraintes que les compilateurs respectent (passer par registre quand l'ABI qui exige un passage sur la pile est un grand classique)

Pour revenir réellement au sujet, il n'y a aucune raisons pour qu'un compilateur C soit sur ce point plus performant qu'un compilateur C++.

[Jean-Marc.Bourguet]

C'est aussi pour ca que Java et C# existe et que tout le monde quitte le C++

J'admire le tout le monde...

[deubelte]

ah oui, mais la non!!!
En ce moment, je m'efforce d'apprendre le C++. Alors si tout le monde passe en java ou C#, ca sert a rien d'apprendre le C++.

La question que je me pose n'est pas la rapidité du C++, mais est ce que le C++ a encore de l'avenir ?

[epsilon68]

J'admire le tout le monde...

c'etait bien sûr un peu ironique ...
et ce que je vois des arguments du C++ vs C, ce sont les memes que du Java vs C++
en lisant les posts, je me dis que Java optimise a la volée son code suivant le materiel alors que le C++ non... donc Java finira donc par etre plus rapide

mais bon je m'egare

le debat du C++ vs C n'a aucune raison d'etre, ni comment l'objet peut etre mis en cause pour des raisons de performance. Il vaut mieux regarder Qt et GTK, il est clair que Qt progresse plus vite et a une API 10000 fois plus limpide...

[hegros]

en lisant les posts, je me dis que Java optimise a la volée son code suivant le materiel alors que le C++ non.

C++ l'optimise avant l'execution. Le seul avantage de Java dans ce cas c'est qu'on a pas besoin de recompiler (en théorie) pour passer d'une plateforme a l'autre