Discussion :

[philippe V]

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

[Ti-R]

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 !

[Luc Hermitte]

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

[Troll]

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 :

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'étranglement, les retravailler (meme en ASM, s'il faut).

Essaye d'analyser ton code (avec Quantify par exemple) pour identifier les traitement couteux.

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!

[scifire]

Bonsoir a tous ,
je vous conseille de trouver l'article

Learning Standard C++ as a New Language : Published in the May 1999 issue of "The C/C++ Users Journal".

Il y a une petite comparaison la dedans et les resultat sont en faveur de C++

[dvsoft]

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

[Ti-R]

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…

[Aurelien.Regat-Barrel]

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

C'est généralement ce qu'on dit "mais on peut faire pareil il suffit de...".
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:

Code :

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

1
2
 
char buffer[ 10000 ];

pour pas s'embêter avec malloc et tout ça. C'est totalement pas sécurisé, super gourmand.
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).

[mat.M]

Mais en pratique combien de personnes font des horribles trucs du genre:
Code:

char buffer[ 10000 ];

Pour être horrible c'est parfaitement horrible
Surtout que cela risque de fragmenter la mémoire.
Qui fait des choses pareilles, des coupables vite???

[dvsoft]

bonsoir

Code :

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

1
2
3
 
   const int IO_BUFFER_SIZE = 512;
   char IoBuffer[IO_BUFFER_SIZE];

Quelle est la première question à poser avant de dire que cela est horrible ?

ALain

[Ti-R]

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

[Aurelien.Regat-Barrel]

Code :

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

1
2
3
 
   const int IO_BUFFER_SIZE = 512;
   char IoBuffer[IO_BUFFER_SIZE];

Quelle est la première question à poser avant de dire que cela est horrible ?

Le débat tourne autour des char * pour les chaines de caractères. Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
   const int SIZE = 512;
   char Name[SIZE];
 
    cout << "Entrez votre nom : ";
    cin >> Name;
    if ( strcmp( Name, "Toto" ) )
    {
        cout << "Salut toto tu vas bien ?\n
    }

[JolyLoic]

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

[dvsoft]

bonjour

Bonne question de Ti-R

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

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

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

[MoLysS]

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

[Blustuff]

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 :

Code :

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

1
2
3
4
Si Condition1 Alors
  ...
Sinon
  ...

ou bien d'écrire

Code :

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

1
2
3
4
Si NON Condition1 Alors
  ...
Sinon
  ...

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.

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.

[rulianf]

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

[Luc Hermitte]

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.

[mchk0123]

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

J'utilise beaucoup de templates MFC(CList, CArray,...) de tableaux dynamiques à plusieurs diemensions.

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.

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.

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.

[mchk0123]

Presque entièrement d'accord,

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

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