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

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 :

Citation:

---

Envoy� par 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!

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

Citation:

---

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

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�

Citation:

---

Envoy� par Ti-R

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:

---

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

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

Code:

---

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

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

Citation:

---

Envoy� par dvsoft

Code:

---

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:

---

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 }

---

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

---

Citation:

---

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

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 :

Code:

---

1 2 3 4

Si Condition1 Alors ... Sinon ...

---

ou bien d'�crire

Code:

---

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.

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.

Citation:

---

Envoy� par r0d

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

Citation:

---

Envoy� par JolyLoic

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