bonjour � tous,
je me demande � quel point une appli programm�e en C++ est plus lente qu'un appli �quivalente programm�e en C. Je cr�e un thread sur ce sujet car j'aimerais avoir l'avis d'un maximum de personnes.
merci.
bonjour � tous,
je me demande � quel point une appli programm�e en C++ est plus lente qu'un appli �quivalente programm�e en C. Je cr�e un thread sur ce sujet car j'aimerais avoir l'avis d'un maximum de personnes.
merci.
Beaucoup de jeux vid�os sont programm�s en C++.
Moi �a me suffit comme r�ponse.![]()
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
aouim�l� attention!! houuulalala!!! nonm�l� 'tention!!! fo pas m�langer!!!!
En ce qui concerne les jeux vid�o, on a besoin de vitesse au niveau de l'affichage!! Et l�, c'est le middleware qui g�re tout (directX bien souvent)!! Le middleware attaque directement les p�riph�riques, c'est pas pareil l�!! nononon!!
Pour l'affichage, je suis d'accord. Mais tu crois que les jeux actuels ne font que de l'affichage.
Juste un exemple: l'IA d'un jeu ce n'est pas la carte vid�o qui le g�re.![]()
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
Je suis d'accord, mais d'apr�s une humble et courte exp�rience personnelle dans le dev de jeux video, j'ai �tabli un constat sur l'utilisation des ressources par un jeu:Envoy� par moldavi
80% pour le graphisme (pas forc�ment en 3D, mais �norm�ment majoritaire)
5% pour l'audio (maximum)
15% pour le reste: IA, gestion des donn�es, moteur physique, etc...
Arhgh, je viens de penser � un truc aussi: tout ce qui concerne l'affichage est aujourd'hui g�r� par la carte gfx (qui a elle-m�me sa m�moire, son pross, ses shaders etc.) Donc tu as raison: le fait que les jeux soient eseentiellement d�velopp�s en C++ est un excellent argument.
Difficile de se prononcer. Moi je dirais qu'au m�me titre que d'autres langages le principal crit�re c'est le programmeur. Un bon programmeur C++ fera des logiciels plus performants qu'un mauvais programmeur C, et inversement.
Partant de l�, reste � savoir avec lequel des 2 il est le plus facile de faire des bons programmes. Et l� c'est un nouveau d�bat...
Sans compter que le compilateur joue beaucoup.
Il y a d�j� des fils qui en parlent.
Chercher par exemple le nr1359, et un article sur object mentor : "Why are you still using C?" de Grenning.
La rapidit� C vs C++ est un faux d�bat.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne r�ponds � aucune question technique par le biais de ce m�dia. Et de toutes fa�ons, ma BAL sur dvpz est pleine...

Pas �vident .....je suis perplexe � ce sujet.e me demande � quel point une appli programm�e en C++ est plus lente qu'un appli �quivalente programm�e en C. Je cr�e un thread sur ce sujet car j'aimerais avoir l'avis d'un maximum de personnes.
Si tu utilises des tas de templates , classes imbriqu�es les unes dans les autres etc... peut-�tre et encore, rien ne prouve que C++ soit plus lent que C.
Pour le jeu que je d�veloppe j'utilise la STL de VC++6 r�put�e pourtant lente et je ne vois pas de pertes de performances significatives ; j'ai tjs le m�me framerate.
Par contre Java Vs C++ l� oui Java est vraiment plus lent![]()
Mais c'est un autre d�bat
C et C++ c la m�me chose !!!
D'ailleurs tu peux m�langer les 2, et C++ est construit sur le C.
Un strlen en C c'est le m�me qu'un strlen en C++ !
Le C++ apporte simplement des m�thodes pour r�utiliser son code, via des class qui font + propre que des fonctions dans ts les sens, ne pas avoir a coder 36 milles fonctions, un template qui les refaits pour toi est bien plus claire....
Il y a plein d'exemples qui montre/d�montre, comme dit Luc, que c'est un faux d�bat.
Et finalement comme tu le dis toi m�me, cela repr�sente peut des perfs pour des applications gourmandes, c'est seulement comment sont cod� les algos....
Hum... l� dessus C++ est plus performant:Envoy� par Ti-R
http://c.developpez.com/faq/cpp/?pag...TRINGS_lenteur
C et C++, ce n'est pas la m�me chose. Utiliser strlen() en C++, c'est programmer en C.
Plus lent, moins lent, la n'est pas le debat.
On va coder avec les outils les plus adapt�s au probleme. Puis identifier les goulots d'etranglement, les retravailler (meme en ASM, s'il faut).
On ensemble logiciel peut comporter plusieures lengages qui interagissent. Et chaque langage va etre utilis� parcequ'il est le plus appropri�.
Et bien justement, je suis tomb� sur un os (pas un O.S.Envoy� par Ti-R
). Je suis en train de d�velopper une appli qui doit faire des statistiques � partir de donn�es r�cup�r�es sur des fichiers. D�j�, le chargement des donn�es est longue, car les fichiers sont �normes, mais �a, c'est autre chose. Mais le probl�me est que j'ai toute une foultitude de classes et methodes qui permettent de triturer les donn�es dans tous les sens afin d'en afficher des statistiques, et sur certains traitements, j'ai des ralentissements consid�rables.
J'utilise beaucoup de templates MFC(CList, CArray,...) de tableaux dynamiques � plusieurs diemensions, des classes qui se ressemblent mais que je ne parviens pas � factoriser, des hi�rarchies complexes entre mes classes, des m�thodes de recherche et de comparaison co�teuses, etc... Ici, il s'agit purement de gestion de donn�es (donc pas d'acces aux p�riph�riques etc.)
J'ai d�j� optimis� un max mes algos (je me suis r�gal� l�-dessus d'ailleurs), mais l�, je ne vois plus o� je peux gagner (ou ne pas perdre)du temps...
Ben tu tu arrives a identifier exactement la ou les methodes dans lesquelles tu passes le plus de temps (avec VTune par exemple) tu pourra le reecrire en assembleur en tirant profit des instriction sets des proc modernes (SSE, MMX & Co) et de la parallelisation.

l� ce sont des probl�mes d'I/O ce qui n'a pas forc�ment � voir avec C/C++D�j�, le chargement des donn�es est longue, car les fichiers sont �normes, mais �a, c'est autre chose.
L� c'est l'OS et t�ches de fond ( sous XP et NT il ya pas mal de services qui "bouffent" des ressources ) qui sont � mettre en cause et non C vs C++;Mais le probl�me est que j'ai toute une foultitude de classes et methodes qui permettent de triturer les donn�es dans tous les sens afin d'en afficher des statistiques, et sur certains traitements, j'ai des ralentissements consid�rables.
Comment veux-tu acc�lerer les traitements ?
En ASM ?
Si tu veux faire des calculs long alors mon cher il faut faire de la programmation multi-processus !
[quote]Et comment fais-tu pour adapter les traitements des classes MFC vers l'ASM ???Envoy� par mtopoloff
Pas �vident que cela soit plus performant et en plus faire des calculs en virgule flottante e ASM bonjour la difficult� surtout pour une appli de stats.
L� c'est 6 mois de d�veloppement en +
mais on diverge...
la question est de savoir lequel des deux langages est le plus rapide.
Pour les comparer, il faut les comparer avec les m�mes hypoth�ses :
- m�me machine,
- m�me qualit� de conception et d'impl�mentation,
- m�mes sp�cifications,
etc...
par exp�rience, je sais que l'on privil�gie le C au C++ dans les applis embarqu�es temps r�el, o� le cpu et la m�moire RAM / ROM sont limit�es, jsutement pour des questions de performances et de taille de programme.
Cela dit, avec l'augmentation moyenne de la taille des logiciels constat�es par je ne sais plus quel organisme (un truc de Thal�s je crois); beaucoup d'architectes de l'embarqu� commence � se pencher vers l'objet (et donc le C++), s�duits par les avantages de l'objet : r�utilisabilit�, etc...
D'o� la naissance d'hybrides : C+, ou faire de l'orient� objet en langage C, avec (presque) tous les m�canismes de l'objet : classes, polymorphisme, surcharge, etc...
Donc, avec les hypoth�ses pos�es pr�demment, et dans le type d'applications auxquelles je fais r�f�rence, je pense que le C est plus rapide / compact qu'une impl�mentation similaire en C++. Dans quelle mesure ? je n'en sais fichtre rien.![]()
Je voulais dire que l'appel de la fonction est le m�me, que le code asm derri�re est le m�me !Envoy� par Aurelien.Regat-Barrel
Et comme il est indiqu� dans ton lien tt d�pend de tes besoins....
Et un string c�est quoi.... c un char * c tt ! mapp� dans une class, j'ai fait de m�me, rien de sorcier... !
Ensuite tu peux utiliser des tableaux des smartpointer pour indexer tes cha�nes de caract�res tout d�pend de ton programme et de tes besoins.
Je ne vois pas trop pourquoi tout le monde veut coder qu'en C++ pur ou en C pur.... C++ est bas� sur les fonctions de C... donc je vois pas pourquoi on n�utiliserais pas les fonctions C. C++ � ces propres fonctions + prot�g�es mais qui sont que du "mapping" de celle du C.
Sinon pour en revenir au topique
Le probl�me est d�j� peut �tre la -> CList, CArray
D�pend comment tu g�res ts cela, tu dis que tu as beaucoup de donn�es, un nombre d'acc�s de liste important peu entra�ner une baisse de perf importante.
ASM c bien... mais faut pas dire ASM, ASM � chaque fois qu'on a un probl�me, quasi tout peu �tre r�solu avec quelques bons pointeurs et un acc�s direct aux donn�es. Avec des boucles optimis�es, et savoir ce qui est charg� en registre, et le nombre de calcul effectu� pour un acc�s de donn�e, cela se compte, en C et C++ pas qu'en ASM![]()

Il est pr�f�rable de programmer "orient� objet" en C++ plut�t qu'en C style parce que , comme tu l'as �crit pr�cedemment tr�s cher , en C++ c'est plus propre modulaire et r�utilisable .Je ne vois pas trop pourquoi tout le monde veut coder qu'en C++ pur ou en C pur.... C++ est bas� sur les fonctions de C... donc je vois pas pourquoi on n�utiliserais pas les fonctions C. C++ � ces propres fonctions + prot�g�es mais qui sont que du "mapping" de celle du C.
Par contre il y a des domaines comme l'embarqu� dont parle Tut o� le C est � privil�gier.
Bon ce sont des discussions qui reviennent un peu � se demander qui de la poule ou de l'oeuf est sorti en premier![]()
Et comme le dit Luc c'est un peu un faux d�bat ;
Mais je crois qu'il ya eu des d�bats l� dessus sur developpez , non ??![]()
N'est-ce pas mon cher Olivier Mazerolle ?![]()
C'est le m�me compilateur. Il est faux de dire que C est plus rapide. C'est l'utilisation que l'on fait de ces langages qui va acc�l�rer ou ralentir -- voir std::sort qui est g�n�ralement plus rapide que qsort, tandis que des exceptions vont avoir un impact.
perf des diverses choses du C++ -> n1359!!!!! (EDIT: n1359 et non nr1359 ; d�sol�...)
Pour l'embarqu�, j'ai plut�t l'impression que le probl�me du C++ est l'absence de fournisseurs de compilateurs d�cents (qui supportent ce qui doit l'�tre). Apr�s il existe un truc qui s'appelle le "Embedded C++". Au vu des sp�cs, je trouve que cela ressemble beaucoup au C++ du temps de l'ARM.
Pour ce qui est de m�langer C et C++ dans une m�me appli, les probl�mes sont que le C++ rajoute des choses qui non contr�l�es vont tr�s facilement rendre incorrect (perte de robustesse) un code hybride C-C++.
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14 { // Faux char * toto = malloc(a,b,c); // ou n'importe quelle ressource C: T*, FILE, socket, ... std::string titi(beaucoup); // ou n'importe quelle construction "échouable" free(toto); } { // Juste ScopedCBuff toto (malloc(a,b,c)); // à se coder! std::string titi(beaucoup); }
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne r�ponds � aucune question technique par le biais de ce m�dia. Et de toutes fa�ons, ma BAL sur dvpz est pleine...
J'ai pas dit qu'il fallait coder en C partout et tout le temps, d'ailleurs je suis pas fan du C pur
Mais si tu utilises une ou 2 fonctions C qui est + rapide � l'ex�cution dans la situation que tu connais, je vois pas pourquoi il faudrait s'en priver.... sous pr�texte que tu fais du C++ !!
Bien sur je suis assez fan de C++ et j'enveloppe un maximum de chose dans des objets, j'utilise � bon escient l'h�ritage ainsi et que les templates
Car j'aime bien r�utiliser mon code un maximum et que mon code soit propre.
Mais si j'ai besoin d'utiliser du C pour optimiser mon code dans mon enveloppe de C++, je ne me pose pas 36 questions, je l'utilise !
Je n�ai pas dit qu'il fallait faire n�importe quoi non + !
Et surtout pas commencer � m�langer new, malloc, delete, free, la c'est sur c'est mort !!
Et qu'en est-il des fonctions inline? Il me semble qu'en C++ �a ne change rien, alors qu'en C �a permet de gagner en performances non?
Partager