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 ;)Citation:
Envoy� par mchk0123
Version imprimable
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 ;)Citation:
Envoy� par mchk0123
Surement moins d'impact que tu ne le penses sur la diff�rence C/C++.Citation:
Envoy� par rulianf
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. :marteau:
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.
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:
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 :P).Code:
2
3
4
5
6
7
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.
Je pr�cise ce que j'ai dit :Citation:
Envoy� par mchk0123
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.Citation:
Envoy� par mchk0123
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...
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.
Explication un peu plus clair de ma part :
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.Citation:
Envoy� par zais_ethael
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?
Raisonnement marketing et commercial. Tu peux donner des exemples de ce que tu avances ?Citation:
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.
Que viens faire le perl ici ?Citation:
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 ?
Tu peux d�velopper un peu ?...Citation:
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?
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.Citation:
Envoy� par Luc Hermitte
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.
C'est aussi pour ca que Java et C# existe et que tout le monde quitte le C++
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...)
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.
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.Citation:
Envoy� par mchk0123
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.Citation:
Envoy� par Jean-Marc.Bourguet
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�).Citation:
Envoy� par mchk0123
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.Citation:
mais pour la compr�hension des autres lecteurs tu peux d�velopper un peu?
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)Citation:
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 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++.
J'admire le tout le monde...Citation:
Envoy� par epsilon68
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 ?
c'etait bien s�r un peu ironique ...Citation:
Envoy� par Jean-Marc.Bourguet
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...
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'autreCitation:
Envoy� par epsilon68