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.
Version imprimable
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. :wink:
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. :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:Citation:
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.
Pas évident .....je suis perplexe à ce sujet.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.
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
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:Citation:
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. :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.Citation:
Envoyé par Ti-R
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++Citation:
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++;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.
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 ???Citation:
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. :D
Je voulais dire que l'appel de la fonction est le même, que le code asm derrière est le même !Citation:
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 .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.
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:
2
3
4
5
6
7
8
9
10
11
12
13
14
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 !!
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?
pour ::
est-ce-que le C est plus Rapice que le C++ OUI
maintenant quelle est la porte de cette difference de performance ???
de l'ordre des nanoseconde !!??
ca ne vaut pas la pein de ce mettre au C pour cette raison.
mais il y en a d'autre raison pour faire du C
le C est un language extrordinairement puissant, facinant ideale pour la programmation system, et Considerer par certain comme du super assambleur, il te permet de faire du bas niveau
sur le developpement d'un OS par exemple le boot strapt est en ASM ensuite tu passe directement au C tu n'a aucune lib,include mais ces quand meme du C vois le project SOS
http://minso.free.fr/cavinfo/systeme/sos.html
sur ce pourquoi n'existe-t'il pas de boot strapt ecrit en C????
inline peut permettre ou pas de gagner en perf. Dépend de son utilisation. Et c'est la même chose en C++ et en C, cela dépend du compilateur ! :?
Le problème n'est pas de mélanger les mallocs avec le reste, mais de ne pas programmer en C++ comme on programme en C. En C on allouait des ressources sans se préoccuper que l'on pouvait sortir d'un bloc par 42 chemins. En C++, ce n'est plus possible. Bref, les mélanges, pourquoi pas, mais prudence!!
Après, on peut effectivement utiliser certaines choses plus rapides du C comme les FILE. Le prix à payer ? Plus facile de se planter dans les arguments des fonctions d'E/S, plus facile d'avoir des buffers overflow, codes simples moins souples, ... Je crois que tout le monde est d'accord là dessus.
Pour les autres fonctions ? celles de stdlib.h/string.h sont parfaitement enveloppées dans des abstractions C++ qui ne coutent pas plus cher à l'exécution (à moins d'avoir de mauvais couples compilo-SL), voire elles sont plus rapides (les abstractions C++), au détriment parfois d'un exécutable plus gros (pas pour std::copy, mais pour std::sort)).
Honnêtement je pense que tu t'égares avec cette question.
Evidement le C est plus primitif, donc potentiellement plus rapide.
Mais si tu envisages un portage C++ vers C (déjà, ça sonne faux),
tu vas bien te faire chier, et tu as peu de chance d'obtenir des changements significatifs.
Je rejoint ce qu'a dit Mtopoloff :
Essaye d'analyser ton code (avec Quantify par exemple) pour identifier les traitement couteux.Citation:
Envoyé par mtopoloff
Sinon, comme tu fais essentiellement du traitement de données, tu peux certainement gagner du temps sur la gestion de la mémoire:
Bien adapter le mode d'instanciation(pile/tas) et le mode de passage des paramètres (ref/copie).
Bon courage!
Bonsoir a tous ,
je vous conseille de trouver l'article
Il y a une petite comparaison la dedans et les resultat sont en faveur de C++Citation:
Learning Standard C++ as a New Language : Published in the May 1999 issue of "The C/C++ Users Journal".
Bonsoir,
Grand débat que la vitesse d’exécution des programmes, suivant le langage utilisé. Travaillant dans le monde de l’embarquer, et du temps réel depuis plus de 20 ans, c’est une question qui m’intéresse vivement. Il est difficile de donner un avis en quelques lignes. Le langage utiliser n’est pas le seul à mettre en cause, il faut tenir compte de la qualité du code, du compilateur et de l’OS cible.
Personnellement, je n’ai jamais vue un programme assembleur aller plus vite que le même programme écrit en C. Mise à part pour les premières versions des compilateurs C, qui étaient peut voir pas optimiser du tout. Si l’on est obligé d’utiliser l’assembleur pour aller plus vite, c’est plutôt le compilateur qu’il faut mettre en cause. Ou le développeur qui a but trop ou plutôt pas suffisamment de bière.
Même pour les petites cibles 8bits, les compilateurs C sont au moins, voir plus, efficace que de l’assembleur, et je ne parle pas de la portabilité entre cibles. Je réserve le C++ pour les cibles 16/32 et DSP qui on plus de mémoire. En therme de nombre d'instruction, il existe peut de différence en C/C++.
A suivre
Alain
Je pense que tout dépend du contexte, je reprends l'exemple des strings et des char* !
Quand on dit que la taille des strings est stockée et donc connue à l'avance et qu'il ne faut pas à chaque fois appeler strlen(), je dis ok....
Mais il y a un coup de calcul de la chaîne a chaque fois qu'il y à une modification de la dite string, et en C, on est pas non + obligé d'appeler bêtement strlen à chaque fois.... on peut le faire 1 fois et stocker le résultat dans une variable si on sait que l'on a besoin de connaître sa longueur tout le temps. Cela revient exactement au même...
De même j'ai vu un test où il "démontrait" via un algo que le java était + efficace que le C/C++ dans certain traitement, oui si on code n'importe comment java peut aller + vite.... car il gère un poil mieux la mémoire tt seul via smartpointeur et autre... mais on peut faire autant en C/C++, donc je dirais que le gros facteur qui limite la vitesse du C et du C++ c pas le langage en lui même, mais plutôt les programmeurs. Et cela ne sert à rien de dire que string c + puissant que char* si on ne compte pas les instructions utilisées dans l’algo déroulé. String est + simple d’utilisation c’est tout, mais clairement pas + rapide…
C'est généralement ce qu'on dit "mais on peut faire pareil il suffit de...".Citation:
Envoyé par Ti-R
En théorie les char * c'est plus performant et moins gourmand en mémoire. En théorie, je suis d'accord. Mais en pratique combien de personnes font des horribles trucs du genre:
pour pas s'embêter avec malloc et tout ça. C'est totalement pas sécurisé, super gourmand.Code:
2
C'est là le problème de char * selon moi : dans la pratique c'est la catastrophe. Et on parle pas de performance là, mais de code correct. Et même au niveau perf, strlen() est appelé de manière transparente de toutes façons. Genre strcat() doit appeler 2 fois strlen() pour connaitre la longueur des 2 chaines. Chaque fonction qui manipule les char * doit appeler strlen() ou rajouter un test pour '\0' (ce qui revient au même) : strcpy, strcat, printf, et toutes les fonctions qui acceptent un char *... et si tu stockes la longueur à part, ces fonctions n'en n'ont que faire, et il te faudra les recoder.
L'utilisation naturelle des char * en C c'est en tant que null terminated string. C'est comme ça que le C a été conçu. Si tu stockes la longueur de ta chaine, ce n'est plus une chaine C null terminated.
Tu dis que std::string est un mapper de char *, on peut pinailler là aussi. C'est laissé à la discrétion de l'auteur de la STL. Et souvent c'est beaucoup plus qu'un simple mapper. Par exemple certaines gèrent le Copy On Write. std::string de VC++ 7 utilise un petit tableau pour les chaines courtes ce qui évite de faire une alloc dynamique couteuse. D'autres sont thread safe... Et tout ça sans changer une ligne de code dans ton source. Il suffit de choisir la STL qui te convient.
Sans compter que c'est des templates, donc le code source est dispo, et donc le compilateur sait faire un inlining efficace.
Mais bon la performance en ce qui me concerne c'est pas le critère n°1. Jusque là en C++ elle a été largement suffisante, c'est ce qui compte. Savoir qu'avec des char * ma fonction qui prend 0,001 sec à s'exécuter aurait pris seulement 0,0005 sec... "Mille fois l'éclair c'est l'éclair".
std::string est bien plus lisible et fiable, c'est ce qui m'importe plus. Et c'est valable pour toutes les classes C++ en général. Tans pis si c'est plus lent.
Et encore, j'ai déjà fait le test, et c'est précisement ça qui m'a fait basculer (avant j'étais pro char *). std::string était à peine plus lent mais incomparablement plus lisible. Et si tu fais des tests d'utilisation genre std::map avec une std::string comme clé, tu tombes sur le *** sur les performances. Or c'est précisement sur des choses significatives comme ça que tu gagnes du temps : les algos de la STL (comme l'a dit Luc pour std::sort).
Citation:
Mais en pratique combien de personnes font des horribles trucs du genre:
Code:
char buffer[ 10000 ];
Pour être horrible c'est parfaitement horrible :D
Surtout que cela risque de fragmenter la mémoire.
Qui fait des choses pareilles, des coupables vite??? :lol:
bonsoir
Quelle est la première question à poser avant de dire que cela est horrible ?Code:
2
3
ALain
A quoi cela sert et dans quel contexte ;)
C'est sur qu'une belle chaîne dynamique pour un buffer comment dire.... cela donne aussi envie de vomir ;)
Le débat tourne autour des char * pour les chaines de caractères. Par exemple:Citation:
Envoyé par dvsoft
Code:
2
3
4
5
6
7
8
9
10
Pour revenir à la question initiale, je dirais que parler en vitesse pure n'a aucun sens. Deux personnes également compétentes et ayant tout le temps qu'ils veulent pour ça obtiendront les mêmes performances en C et en C++.
La bonne question est plus AMA : Pour un temps de développement indentique est assez contraint, quel langage permet d'obtenir rapidement les performances requises pour l'application. Et j'aurais tendance à dire que sauf dans des environnements avec des compilateurs C++ dépassés, ou avec peu de mémoire, le C++ permet en général de mieux y parvenir, pour les raisons suivantes :
- Il permet un niveau d'abstraction élevé : Le code va plus vite à écrire, et il reste donc plus de temps pour optimiser.
- Une bonne encapsulation y est plus simple à obtenir, et elle est nécessaire pour que l'optimisation puisse se concentrer sur les goulots d'étranglement sans que ça implique une refonte de tout le code à chaque fois.
- Il y existe des techniques basées sur les templates pour que la pénalité d'abstraction en C++ soit plus faible (voire nulle) qu'en C, l'exemple canonique étant le tri : Si le développeur recode son algo pour son cas spécifique, en C ou C++, pas de différence. S'il veut réutiliser un algo standard et donc un minimum générique, qsort (C) sera battu par std::sort (C++).
bonjour
Bonne question de Ti-R
Citation:
A quoi cela sert et dans quel contexte
Et oui, surtout que dans le cas present, le buffer est utiliser dans un driver bas niveau. FAT16 sur un support MMC, pour un logger embarqué.Citation:
C'est sur qu'une belle chaîne dynamique pour un buffer comment dire.... cela donne aussi envie de vomir
Je pense que le post de JolyLoic donne une reponse claire, et je suis de son avis (pas totalement mais bon)
Aller bon courage a tous
Alain
Bon alors pour essayer de donner un semblant de réponse à ce problème, je commencerais par dire que le C a été conçu pour être aussi rapide que le C. Et ils y sont arrivés.
Ensuite, il y a quelques bémols : deja, tout dépend de la façon de programmer.
Ensuite, tout dépend du compilateur : en C, on décide si telle ou telle variable est statique ou dynamique. En C++, c'est le compilateur qui décide tout (hé oui, votre joli new maclasse est peut-être même pas executé et l'objet est statique).
Après, je vois vraiment pas comment comparer un code C à un code C++. Je m'explique : si vous voulez comparer deux codes identiques, bah ca sera du C dans les deux cas, ou alors ils seront pas identiques.
Tout ça pour dire qu'en codant proprement, on PEUT faire en C++ un code ausi rapide que C. Le problème vient donc plutot des codeurs qui ne font bien souvent plus gaffe à la consommation de leur code.
Je vais finir en disant qu'à mon sens, un excellent code C++ ne pourra être qu'aussi bon (aux mieux) qu'un excellent code ASM. Pourquoi? tout simplement parce que le C n'est en fait rien d'autre qu'un ASM un peu agrandi et simplifié. THEORIQUEMENT, on PEUT fair un code C aussi rapide qu'un code ASM optimisé (sans utiliser le mot clé "asm"), sous peine de bien connaitre l'archi sur laquelle on bosse ET le compilateur utilisé.
Théoriquement non, certainement pas. Il y a des optimisations que l'on sait faire à la main que les compilateurs ne savent pas faire. Pour qu'ils y parviennent il leur faudrait une analyse contextuelle beaucoup plus développée. Voir carrément une réflexion poussée. Vous connaissez les système de prédiction des processeurs ? Si c'est le cas, vous êtes capable de savoir pour certains processeurs s'il est préférable d'écrire :
ou bien d'écrireCode:
2
3
4
Combien de compilateur si on leur donne le processeur en question saura utiliser cette optimisation ? Quel compilateur saura utiliser le remplacement de saut conditionel sur un branchement qui provoquera trop de missprediction ? Quel compilateur utilisera le binary flag du x86 ? Si vous en connaissez, faites moi signe, ça m'intéresse.Code:
2
3
4
Après, pour la question, ça a déjà été dit, mais il faut le répéter encore visiblement :
On ne compare pas la rapidité du langage C à la rapidité du langage C++, mais on compare la rapidité d'un programme écrit à la manière du C à celle d'un programme écrit à la manière du C++. Un programme en C, sauf quelques exceptions, pourra être compilé par un compilateur C++. Ca reviendrait alors à comparer les compilateurs. Et si l'un fait moins bien que l'autre, c'est que l'un est réelement moins bien que l'autre, mais absolument aucun rapport avec le langage.
L'optimisation ca peut être perdre énormément de temps pour des gains souvent imperceptibles. Il faut savoir identifier le code lent, et l'optimiser. Si l'utilisation d'objet intervient dans une portion de code critique, un développeur C++ pourra toujours oublier l'objet. Garder this dans un registre du processeur peut être très handicapant.
Savoir si le C est plus rapide que le C++ revient un peu pour moi à savoir si programmer purement en objet (ce que l'on tente généralement de faire en C++) est plus rapide que programmer en non objet (ce que l'on fait en général en C et même s'il existe des objets basiques dans ce langage)... j'ai été récemment confronté au problème dans le développement de librairies de traitement du signal et de maths appliquées et je me suis posé la même question... Ici les problèmes de lenteur sont essentiellement issus de la complexité des calculs, du nombre d'itérations à effectuer, du nombre d'objets en jeu... et pour tout dire il semble clair qu'une approche C serait plus rapide qu'une approche C++... 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... Certes cela peut sembler mineur lorsque les objets sont peu nombreux mais, dès que l'on manipule des quantités d'objets (à cycles de vie courts) beaucoup plus grandes (multi-agent par exemple) et sur un grand nombre d'itérations, toutes les opérations inhérentes à la vie d'un objet peuvent devenir gourmandes et ralentir l'exécution de manière non négligeable... Ceci n'est qu'un exemple mais il me semble d'ailleurs (sauf erreur de ma part) que la majorité des "bonnes" librairies de calculs (matriciel par exemple) est codée en C. Voilà ce que je pourrais dire d'après ma petite expèrience du C par rapport au C++ en termes de vitesse du code. Mais juste pour finir et surtout pour me contredire un peu, il me semble important de dire que j'écris à peu près tous mon code en C++ (en non pas en C !!) pour la simple et bonne raison (me semble-t-il !) que, même si je sais que je perds un peu de temps à l'exécution, j'en gagne quand même beaucoup dans la conception et l'écriture des sources : finalement ce débat est peut-être vraiment un faut débat !...
Je suis d'accord que ce débat est un faux débat. Mais aussi pour d'autres raison. Ta phrase me rappelle le débat sur le coût révé de la virtualité, que l'on a peut-être déjà abordé ici d'ailleurs. Le truc est que l'on paye pour les fonctionnalités que l'on utilise. Après, il faut voir de quelles fonctionalités on a besoin.
Juste une précision supplémentaire. Objet ne veut pas dire polymorphisme d'inclusion à tous les coins de rue. On n'est pas obligé d'hériter et d'introduire la liaison tardive parce que l'on veut écrire des objets. Cf ce qui dérive directement de la STL (j'écarte donc les flux propres à la SL). 0 héritage, 0 polymorphisme d'inclusion. Et pourtant 100% C++, 0% C.
Concernant les biblios mathématiques, la référence initale, ce sont les BLAS du Fortran. On trouve des adaptations C qui vont avoir de bonnes perfs, mais une interface de manipulation peu pratique. Et on trouve des biblios C++ qui rajoutent une expressivité "mathématique" tout en maintenant d'excellentes perfs. Dans le passé, on avait Blitz++ qui réalisait une utilisation intensive de méta-programmation template pour éliminer les temporaires, ... Visiblement, blitz++ ne semble pas se préoccuper des problèmes de pipeline aussi efficacement que d'autres biblios. Qu'à cela ne tienne, on a des alternatives construites sur la même philo que blitz++ qui savent encapsuler des biblios C à la BLAS.
En fait, pour le côté mathématique, la sémantique de valeur inhérente aux objets mathématique fait que l'on evite naturellement tout ce qui concerne le polymorphisme d'inclusion.
T'as pas pensé à comparer les perfs de tes conteneurs quand ils sont gonflés à bloc !? MFC datent un peu essayes aussi STL, surement plus rapides en la matière.Citation:
Envoyé par r0d
La RAM à beau être trés rapide de nos jours un redimensionnement auto d'un CArray de 1millions | 1milliard de lignes ça compte. Essaye de précalculer leurs tailles à l'avance + reservation mémoire. :cfou:
D'autant que d'aprés ce que tu me dis tes execs dessus semblent faire du vrai torture test (rien de pégoratif là dedans). Pis y t'on rien fait ces pov' conteneurs.
:yaisse:
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é.Citation:
Envoyé par JolyLoic