Est-ce que c++ est vraiment plus lent que c

Version imprimable

Voir 40 message(s) de cette discussion en une page

25/02/2005, 12h49
r0d

Est-ce que c++ est vraiment plus lent que c

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.
25/02/2005, 13h10
moldavi

Beaucoup de jeux vidéos sont programmés en C++.

Moi ça me suffit comme réponse. :wink:
25/02/2005, 13h14
r0d

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!!
25/02/2005, 13h17
moldavi

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. :wink:
25/02/2005, 13h30
r0d

Citation:

Envoyé par moldavi

l'IA d'un jeu ce n'est pas la carte vidéo qui le gère. :wink:

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:
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.
25/02/2005, 13h44
Aurelien.Regat-Barrel

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.
25/02/2005, 13h45
Luc Hermitte

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.
25/02/2005, 14h36
mat.M

Citation:

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.

Pas évident .....je suis perplexe à ce sujet.
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 :D
Mais c'est un autre débat
25/02/2005, 14h36
Ti-R

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....
25/02/2005, 14h40
Aurelien.Regat-Barrel

Citation:

Envoyé par Ti-R

Un strlen en C c'est le même qu'un strlen en C++ !

Hum... là dessus C++ est plus performant:
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.
25/02/2005, 14h46
mtopoloff

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é.
25/02/2005, 14h47
r0d

Citation:

Envoyé par Ti-R

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....

Et bien justement, je suis tombé sur un os (pas un O.S. :lol: ). 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...
25/02/2005, 15h03
mtopoloff

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.
25/02/2005, 15h06
mat.M

Citation:

Déjà, le chargement des données est longue, car les fichiers sont énormes, mais ça, c'est autre chose.

là ce sont des problèmes d'I/O ce qui n'a pas forcément à voir avec C/C++

Citation:

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.

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++;
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]

Citation:

Envoyé par mtopoloff

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.

Et comment fais-tu pour adapter les traitements des classes MFC vers l'ASM ???
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 +
25/02/2005, 15h54
tut

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. :D
25/02/2005, 15h56
Ti-R

Citation:

Envoyé par Aurelien.Regat-Barrel

Citation:

Envoyé par Ti-R

Un strlen en C c'est le même qu'un strlen en C++ !

Hum... là dessus C++ est plus performant:
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.

Je voulais dire que l'appel de la fonction est le même, que le code asm derrière est le même !

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 ;)
25/02/2005, 16h22
mat.M

Citation:

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.

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 .
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 :lol:
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 ?? :D
N'est-ce pas mon cher Olivier Mazerolle ? :lol:

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:

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); }

25/02/2005, 16h30
Ti-R

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 :D
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 !!
25/02/2005, 16h51
r0d

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?

Voir 40 message(s) de cette discussion en une page