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

Citation:

---

Envoy� par mchk0123

Citation:

---

Quelqu'un qui n'y connait rien en optim, mais qui connait Blitz++ (/boost.ublas / ATLAS / ...) �crira des choses plus performantes que le premier venu en assembleur. Il �crira m�me des choses plus performantes que quelqu'un qui croit s'y connaitre.

---

a- Raisonnement marketing et commercial.
b- Tu peux donner des exemples de ce que tu avances ?

---

a- C'est mal me connaitre :lol: C'est un raisonnement de fain�ant qui n'aime pas r�inventer la roue.
b- Hum .. Connais-tu les biblioth�ques que j'ai cit�e ? Ce sont des biblioth�ques robustes de calcul matriciel hautes performances en C++ et C (pour ATLAS).
Tu trouveras des benchmarks sur les divers sites ; quand on a atteint les perfs des BLAS, je pense que �a va. Et oui, je t'assure que le petit d�butant qui n'y connait que dalle en optimisation en assembleur ne saura pas �tre aussi performant que le petit d�butant qui n'y connait que dalle en optimisations en C ou C++, mais qui utilise des biblioth�ques d�di�es qui sont elles optimis�es. Je pourrais parler de pipeline, de fl�ts d'ex�cution, etc., je ne ferai que rejoindre ce que Jean-marc a dit.

Apr�s, il y vraiment des gens qui croient s'y connaitre mieux que les autres (j'en croise de temps � autre), qui veulent tout reprendre sur un ou�e-dire vieux de 10 ans, pour au final d�velopper des trucs instables et inutilisables, quand ils ne sont pas plus lents. Parfois ils ne connaissent juste pas le C++ et r�inventent la SL.

Citation:

---

Que viens faire le perl ici ?

---

Comme le C++ il y a 150 fa�ons diff�rentes de faire quelque chose en perl. Est-ce que pour cela on parle que statistiquement il y a plus de chances d'�tre lent parce que des gens ne connaitront pas la fa�on la plus optimale ?

Citation:

---

Citation:

---

Il y a des risques bien plus importants que les perfs quand on n'apprend pas � ce servir de ces langages. A quoi bon foncer dans un mur?

---

Tu peux d�velopper un peu ?...

---

OK. Il est juste facile de se tirer dans le pied en C, (et quand on y arrive en C++, c'est toute la jambe qui part. Vous connaissez le "dicton"). Et en C++, �tre robuste et maintenable demande un minimum d'initiation.

Ce que je dis n'a rien de marketeux. Ce n'est que mon exp�rience.

Citation:

---

Envoy� par deubelte

En ce moment, je m'efforce d'apprendre le C++. Alors si tout le monde passe en java ou C#, ca sert a rien d'apprendre le C++.
La question que je me pose n'est pas la rapidit� du C++, mais est ce que le C++ a encore de l'avenir ?

---

C'est un tout autre d�bat qui a son fil � lui. Je t'invite plut�t � y reposer ta question si tu penses que ce qui y a d�j� �t� dit n'y r�pond pas.
Accessoirement, si tu connais le C++, tu ne devrais avoir aucun mal avec les deux autres. Tu risques de te sertir brid� (c'est mon cas) si tu t'habitues trop aux templates, � la s�mantique de valeur, au RAII, ... Ils restent des langages diff�rents.
Parenth�se: ta question me fais penser � ce que j'avais lu sur le blog de Joel Spolsky (ortho?) (de joelonsoftware) qui regrette que les java schools soient aussi r�pandues, ce qui impliquerait un manque de culture et de familiarit� avec le cambou�.

Citation:

---

Envoy� par epsilon

et ce que je vois des arguments du C++ vs C, ce sont les memes que du Java vs C++

---

Sauf que le d�bat peut aussi traiter de fonctionalit�s dont est d�pourvu le Java. Alors que le C++ reprend �norm�ment de choses du C. Et que C comme Java ont peut-�tre des ABIS (ou assimil�) mieux d�finies que le C++.
Bref. Certes dans un cadre donn�, mais on ne peut pas dire "cela reprend presque tout", ce qui fait que le d�bat n'est pas vraiment le m�me.

Salut,

Citation:

---

Envoy� par mchk0123

Si mais pour la compr�hension des autres lecteurs tu peux d�velopper un peu ? Et surtout, pour rebondir sur le sujet du post, est-ce que les compilateurs C et C++ savent bien tirer profit de toute la complexit�e des CPUs modernes et de la gamme assez vari�e.

---

Il te suffit de regarder les option de compilation fournies par ton compilateur pour t'en convaincre:

Que ce soit gcc, g++, ou les compilos de chez microsoft, tu peux choisir, sur PC, l'architecture processeur � pour laquelle tu souhtaites qu'il optimise l'ex�cutable parmis la liste des architectures qui existaient au moment o� le compilo est devenu accessible.

Cela implique qu'il te faille alors choisir entre un code optimis� pour une architecture plus ancienne, mais donc susceptible de tourner sur plus de machine ou un code pour "la derni�re architecture" mais donc plus restrictif au niveau des machines sur lesquelles il sera en mesure de tourner...

Citation:

---

Envoy� par deubelte

ah oui, mais la non!!!
En ce moment, je m'efforce d'apprendre le C++. Alors si tout le monde passe en java ou C#, ca sert a rien d'apprendre le C++.

La question que je me pose n'est pas la rapidit� du C++, mais est ce que le C++ a encore de l'avenir ?

---

Ca c'est un autre d�bat, qui a d'ailleurs d�j� cours sur le forum, mais, bien sur que le C++ (tout comme tous les autres langages) ont de l'avenir...

Surtout si tu compares un(des) langage(s) compil� � un(des) langages interpr�t�s/n�cessitant une machine virtuelle pour fonctionner.

L'une des raisons "facile" est qu'il faudra des langages "compil�s" pour permettre la cr�ation de syst�mes d'exploitation sur lesquels faire tourner les interpr�teurs/machines virtuelles ;) mais de nombreuses autres raisons font que tous les langages ont malgr� tout de l'avenir (y compris les plus anciens que tu pourras trouver ;))

Pour en revenir au d�bat... et en se limitant � la comparaison C->C++, j'ai tendance � estimer que, bien plus que le langage en lui-m�me, trois grands crit�res ayant trait au programmeur sont de nature � influencer la rapidit� d'ex�cution de l'application:

• le niveau de tol�rence/ gestion/r�cup�ration d'erreur souhait�:
  
  Il n'est pas rare que, pour effectuer la gestion d'erreurs, et �ventuellement les r�cup�rer, on obtienne un code trois � quatre fois plus important, et au final *vraissemblablement* plus lent � l'ex�cution, que le code qui serait cr�� sans prendre cette gestion d'erreur en compte...
• l'algorithme utilis�:
  
  S'il n'est pas adapt�, ou pas optimis�, il y a vraiment peu de chances que l'application r�sultante soit rapide ;):P
• la connaissance et l'utilisation � bon escient des bibioth�ques ad-hoc mises � disposition
  
  une biblioth�que maltrait�e par de nombreuses personnes sera *vraissemblablement* bien plus optimis�e que le code fournis par quelqu'un qui essayerait de "r�inventer la roue"
  
  La connaissance d'une telle bibliotheque et son utilisation � bon escient sera au final *vraissemblablement* bien plus rapide et/ou s�curisante que le meme code "fait main" par quelqu'un qui pourrait sans doutes n'en avoir pas appr�hend� l'ensemble des tenant et des aboutissants ;)

Si l'on voulait �tendre le d�bat aux autres langages de programmation, la seule chose qui changerait est le fait que certains langages ont �t� cr��s pour des situations ou une utilisation pr�cise, ou des domaines particuliers et que, de fait, ils auront des chances d'�tre plus rapides dans leur domaine particulier que d'autres potentiellement plus "g�n�raux"...

Citation:

---

en lisant les posts, je me dis que Java optimise a la vol�e son code suivant le materiel alors que le C++ non... donc Java finira donc par etre plus rapide

---

�a, c'est une simple diff�rence entre compilation normale et compilation JIT.
Que ce soit pour Java ou pour C++, les deux sont possibles.

Il est d'ailleurs int�resser de m�langer les deux.
Mac OS X le fait pour acc�lerer son syst�me de rendu bas� sur OpenGL qui a une part de dynamisme (d�tection et chargement des extensions je pense)

Citation:

---

Envoy� par loufoque

�a, c'est une simple diff�rence entre compilation normale et compilation JIT.
Que ce soit pour Java ou pour C++, les deux sont possibles.

Il est d'ailleurs int�resser de m�langer les deux.
Mac OS X pour acc�lerer son syst�me de rendu bas� sur OpenGL qui a une part de dynamisme (d�tection et chargement des extensions je pense)

---

ok j'etais de mauvaise foi de toute facon :aie:
d'apres mes propres benchmarks le java (28sec) est significativement plus lent que C++ (8sec)

je prefere le C++ que ce soit clair, mais Java est une bonne alternative comme language simple et "assez" rapide dans la plupart des cas.

J'avais notamment le cas au boulot d'un environnement de production super restreint, ou seul Java pouvait etre utilis�. Au final juste quelque jars et hop le tour etait jou�.

Je n'utilise pas C++ au boulot, C# et Java sont les uniques axes de development (IT). Je pense meme que C++ est mort sur Windows avec leur tout .NET Serieusement ca m'inquiete un peu sur l'avenir de C++....

Citation:

---

Envoy� par epsilon68

C++ est mort

---

L'enterrement est pr�vu pour quand ?

Citation:

---

Envoy� par epsilon68

Je pense meme que C++ est mort sur Windows avec leur tout .NET Serieusement ca m'inquiete un peu sur l'avenir de C++....

---

Pas de soucis de ce c�t� l�, Studio permet encore de compiler du code C++ normalis� non CLI. Et puis il reste encore de bon compilo. gratuits.

... meme pire si je faisais une offre avec C++ dessus je serais elimin� au premier tour, il n'y aurait personne capable de le maintenir, et puis C++ ca fait peur a tout le monde point de vue temps de development, maintenabilit� ....

moi j'y peux rien, ce sont les clients et nos managers les premiers decideurs....
C++ n'est pas a la mode malheureusement ... du moins dans mon secteur ...

... alors C ... encore moins

Citation:

---

Envoy� par epsilon68

... meme pire si je faisais une offre avec C++ dessus je serais elimin� au premier tour, il n'y aurait personne capable de le maintenir, et puis C++ ca fait peur a tout le monde point de vue temps de development, maintenabilit� ....

moi j'y peux rien, ce sont les clients et nos managers les premiers decideurs....
C++ n'est pas a la mode malheureusement ... du moins dans mon secteur ...

... alors C ... encore moins

---

Mais l�, tu tires une g�n�ralit� tout � fait fausse du cas particulier qui est le tien...

Si je ne connais pass assez ton secteur pour te contredir dans ton secteur particulier, il est aberrant de g�n�raliser le fait que "personne" ne serait capable de maintenir du C++ ou que le C++ fait peur � tout le monde...

Quelque soit le langage envisag�, tu trouveras des gens qui auront peur de s'y frotter, et d'autres qui ne jureront que par lui...

je serais heureux d'avoir tort, et j'ai toujours dit en fonction de mon domaine d'activit�.
En meme temps dure d'etre general, il y a tellement de domaine...

vous etes dans quel domaine ?

ca pourrait etre int�ressant de partager les experiences dans les differents domaines non ?

personne ne veut parler de son domaine et m'aider a voir de facon plus generale ?

Citation:

---

Envoy� par epsilon68

personne ne veut parler de son domaine et m'aider a voir de facon plus generale ?

---

Si je te dis que mon domaine, c'est l'EDA (Electronic Design Automation, la CAO en �lectronique). Ca t'avance � quoi?

Je crois que le mythe � tuer, c'est le langage universel qui rempli tous les besoins. Je suis s�r que Java rempli certains besoins mieux que le C++; ce n'est simplement pas les n�tres.

Citation:

---

Envoy� par Jean-Marc.Bourguet

Si je te dis que mon domaine, c'est l'EDA (Electronic Design Automation, la CAO en �lectronique). Ca t'avance � quoi?

Je crois que le mythe � tuer, c'est le langage universel qui rempli tous les besoins. Je suis s�r que Java rempli certains besoins mieux que le C++; ce n'est simplement pas les n�tres.

---

Je me dis que c'est cool ...
moi je faisais de la 3d CAM avant mon emploi actuel, et je me suis fait un engine en Java pour voir la reelle difference... et il y en a une alors pour mes trucs persos je suis en C++

tu ne me convaincras pas sur le language universelle qui n'existe pas ... non je suis d�j� persuad�, mais bon je me demandais sur vos opinions / experiences...
tu fais un programme portable ? tu utilises quoi comme libs etc ?

Citation:

---

Envoy� par epsilon68

tu fais un programme portable ?

---

Nous �crivons du code relativement standard (c�d que nous ne nous en �loignons pas trop volontairement), mais je doute que l'ensemble puisse �tre port� facilement sur autre chose qu'un Unix.

Citation:

---

tu utilises quoi comme libs etc ?

---

Rien qui ne soit pas du d�veloppement interne. L'interface est fait en QT -- ou avec une couche au dessus -- mais je n'y touche pas.

Merci c'est cool

De mon point de vue C et C++ sont deux fr�res.
Ce qui fait une petite partie de la diff�rence est le style de code et comment il est ensuite compil�.
Le C++ apporte les classes et templates, une classe n'est simplement qu'une structure compos� d'un pointeur vers le tableau des pointeurs sur ses m�thodes, et des ses attributs ... � partir de l� il s'agit d'une l�g�re diff�rence de taille (le tableau est statique). Les templates sont g�n�r� en diff�rente fonctions ... ces fonctions seront selon le compilateur compil�e exactement de la m�me fa�on qu'en C (quel est le fou qui code 25 fois la m�me fonction pour des types diff�rents ?).
Donc au final la rapidit� ne se jouent pas sur l'assembleur g�n�r� puisque les instructions C++ sont en C ... le C++ permet principalement de r�duire la taille du code pour des probl�mes sp�cifiques (multi type, necessit� d'utiliser des objets etc..).

LA GRANDE PARTIE de la diff�rence de rapidit� viens du fait qu'une classe C++ est sens�e ne pas �tre destin�e � infliger de contraintes d'arguments, le but de la POO est de r�utiliser le code sans � chaque fois redefinir les predicats. J'en viens donc au fait que la rapidit� d�pend du nombre de verifications sur arguments ... en C++ on en vient m�me a wrapper les classes dans des smart_pointer pour �viter les boulettes ... une verification du plus ... et encore une ... ce qui rapproche la rapidit� de ce code C++ � celle du java o� tout est v�rifi� puisque les objets servent � tout et n'importe quoi.

D'apr�s moi, la meilleure fa�on de conserver l'�quilibre est de connaitre son code, et connaitre le fonctionnement de ses d�pendances (lire la classe vector ne fait pas de mal) d'une part. D'autre part d'�viter les v�rifications inutiles (miser sur l'intelligence du r�utilisateur ne vous fait rien perdre, no pity for dummies). Le C PEUT servir en C++, arretons un peu la bataille, un char* � la place d'une string c'est pas la mort � g�rer vous m�me et au moins on sait ce qu'il se passe (mais recodez strlen, vive le buffer overflow).

La r�gle d'or : on est jamais mieux servi que par soi-m�me ! Donc les libs ne les choisissez pas si c'est pour 10 fonctions ...

[j'utilise boost, avec parcimonie bien entendu ^^]

Un petit r�sum� :
C/C++ c'est pareil au niveau compilation ... les m�mes instructions compileront de la m�me mani�re ... La diff�rence vient du style de programmation. Ce style de programmation est choisi en fonction des besoins et performances cibles.
la performance se base sur : la vitesse, la portabilit�, la m�moire requise.
Et ces trois choses, on une importance diff�rente suivant le besoin.
Jeux utilisant des entit�s -> objets -> C++ (en style C quasiment impossible � r�aliser proprement)
Jeux 3D -> les ressources 3D sont des objets, le C++ est plus convenable
Jeux 2D -> C ou Java, le C sera plus rapide mais plus long � coder.
Appli de calcul -> asm, C ou C++ suivant le probl�me
Appli de gestion commerciale -> Java parce que tr�s utilis�, � la mode, et que ma soeur (non existante) de 6 ans arriverait � cliquer sur les corrections d'erreur d'Eclipse. Et la rapidit� dans ce cas n'est pas demand�, plus l'appli met de temps, plus le commercial est libre de penser � comment il va d�penser sa fortune le week-end.
Appli type gestion boursi�re : C / Caml / Prolog, des languages qui tiennent la route, le prolog est sans faille.

Citation:

---

Envoy� par ThiSpawn

De mon point de vue C et C++ sont deux fr�res.
...
Donc au final la rapidit� ne se jouent pas sur l'assembleur g�n�r� puisque les instructions C++ sont en C ...

---

+1

Citation:

---

Envoy� par ThiSpawn

le C++ permet principalement de r�duire la taille du code pour des probl�mes sp�cifiques (multi type, necessit� d'utiliser des objets etc..).

---

Le C++ t'apporte l'objet. L'objet t'apporte la possibilit� (mais pas la certitude) de coder fiable, robuste, maintenable et lisible y compris dans des projets complexes et volumineux.
La taille des projets en C est limit�e � ce que le cerveau du moins "m�moriel" (quel est le bon terme ?) de l'�quipe peut contenir comme information.

Citation:

---

Envoy� par ThiSpawn

D'apr�s moi, la meilleure fa�on de conserver l'�quilibre est de connaitre son code, et connaitre le fonctionnement de ses d�pendances (lire la classe vector ne fait pas de mal) d'une part.

---

C'est pour �viter cela qu'on a invent� l'objet. Pour que 40 personnes puissent travailler chacun sur le m�me code en �tant d'accord simplement sur l'interface (et donc sans avoir � lire le code des autres).

Citation:

---

Envoy� par ThiSpawn

La r�gle d'or : on est jamais mieux servi que par soi-m�me ! Donc les libs ne les choisissez pas si c'est pour 10 fonctions ....

---

M�me remarque.

Derniers �l�ments en vrac :

1. il existe des jeux 3D,en Java ,sur la march�, et qui font un carton Java utilise ici un autre atout qu'est la portabilit�.

2. on peut coder "bien" (au sens fanatique du terme) en Java, mais c'est dur. Beaucoup plus dur (selon moi) que de coder "bien" en C++, parce qu'il faut comprendre comment fonctionne la JVM.

3. L'actualit� nous montre que Java "marche" l� o� aucun autre langage n'a jamais r�ussi � fonctionner. Et il marche non-pas parce qu'il est rigoureux, non-pas parcequ'il est performant, non-pas parce qu'il est efficace, mais parce qu'il est facile � utiliser. Autrement dit : c'est plus facile de lever une arm�e de codeurs Java que de lever une arm�e de codeurs C++. De plus, l'arm�e de codeurs Java obtient des r�sultats (m�me moins bons) plus rapidement, et donc pour un r�sultat assez long � obtenir, seul Java permet une solution. Un exemple ici de quelque chose qu'on a longtemps essay� de faire, mais qu'on a jamais r�ussi en C et C++.