Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2281 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  [C/C++] C ou C++ pour des performances optimales?

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[C/C++] C ou C++ pour des performances optimales?

n°1968646
Nival
Posté le 23-02-2010 à 18:36:13  profilanswer
 

Bonjour tout le monde!
 
Je vous explique mon "cas": je compte me remettre peu à peu à la programmation après 5 bonnes années d'inactivité dans le domaine, dur dur de se replonger... :pt1cable:
 
Mes connaissances (passées...) en matière de prog sur PC sont le C et l'assembleur (16bit surtout :D, mais fait un peu joujou avec RosASM aussi), et j'ai un projet un peu (beaucoup... :whistle:) ambitieux pour lequel je vais avoir besoin de performances (relativement...) optimales, du fait qu'il va y avoir pleins de choses à gérées avec pour objectif de faire une application "temps réel" (projet pouvant s'apparenter finalement à un "jeu vidéo" ).
 
C'est à voir quand je me serai "remis à niveau" mais pour l'instant j'envisage au final un gros du code en C ou C++, les routines les plus gourmandes en assembleur (j'ai jamais mélangé les deux encore, ça promet d'être épique! :D), l'interface graphique en OpenGL que j'apprend en ce moment (ancienne version pour l'instant en attendant plus de ressource sur le nouveau standard 3.x... Ça aussi ça promet un peu de boulot avant que je sois opérationnel!!) via la bibliothèque SDL (que je connais un peu) ou éventuellement les API Win32 (que j'ai manipulées un peu il y a LONGTEMPS!).
 
 
Le truc c'est que si je connais(sais) le C, je suis encore jamais passé au C++, chose qui a priori n'est pas "très compliqué" au demeurant, et pourrait m'aider vu l'ampleur du projet... Sauf que je me demande si, si on y gagne en manipulation d'"objets", on y perd pas en performance final du programme? (puisqu'a priori ça semble "plus haut niveau" que le C, en espérant pas dire trop de bêtises!! :whistle:).
 
Donc en gros la question: est-ce que ça vaut la peine dans mon cas que je me lance dans le C++ ou est-ce que je risque d'avoir au final un programme significativement moins performant qu'avec du C relativement bien optimisé, la performance étant un facteur critique de mon projet?
 
Merci par avance de vos réponses!

mood
Publicité
Posté le 23-02-2010 à 18:36:13  profilanswer
 

n°1968657
theshockwa​ve
I work at a firm named Koslow
Posté le 23-02-2010 à 19:06:07  profilanswer
 

tu pourras toujours faire aussi rapide que du C avec du C++. La philosophie du C++ est de ne payer que pour ce qu'on utilise. C'est pour ca que, par exemple, la virtualité des fonctions est optionnelle. Bref, C++, c'est autrement plus vaste que C, et tu vas peut-être passer pas mal de temps à assimiler les nouveaux concepts avant de pouvoir les utiliser intelligemment dans un projet conséquent.
 
Pour mixer C/C++ et assembleur, je ne saurais que trop te conseiller de considérer les intrinsics plutôt que de chercher à balancer du code asm baveux directement [:petrus75]
 
Après, de toute façon, les performances, tu as bien du temps avant de devoir t'en soucier (du moins, de t'en soucier au point de vouloir faire de l'assembleur), surtout si tu développes sur PC ...


Message édité par theshockwave le 23-02-2010 à 19:07:15

---------------
last.fm
n°1968690
Joel F
Real men use unique_ptr
Posté le 23-02-2010 à 19:39:22  profilanswer
 

C et C++ sont equivalent quand on fait du C++ propre (ie prog. générique et non objet).
 
Assembleur: ca sert àrien, le compilo ets plus fort que toi.

n°1968693
Joel F
Real men use unique_ptr
Posté le 23-02-2010 à 19:45:00  profilanswer
 

Nival a écrit :


Le truc c'est que si je connais(sais) le C, je suis encore jamais passé au C++, chose qui a priori n'est pas "très compliqué" au demeurant, et pourrait m'aider vu l'ampleur du projet...


 
J'avais pas vu. C et C++ n'ont en commun qu'une lettre, il faut VRAIMENT l'appréhender comme un langage à part avec ces idiomes particuliers, sinon tu vas faire de la soupe infame.

n°1968698
xilebo
noone
Posté le 23-02-2010 à 20:03:53  profilanswer
 

Joel F a écrit :

C et C++ sont equivalent quand on fait du C++ propre (ie prog. générique et non objet).
 
Assembleur: ca sert àrien, le compilo ets plus fort que toi.


 
 
Quand je vois les performances des algos qu'a écrit un des programmeurs avec qui je bosse en assembleur MMX et SSE pour faire un scale soft (avec filtrage bilinéaire) sur une image video (car pas de prise en charge matérielle par la carte vidéo), je ne serais pas aussi affirmatif.  
 
La différence de performance entre la version C et la version assembleur est loin d'être négligeable. Je n'ai pas les chiffres par contre.
 
 
 

n°1968701
Joel F
Real men use unique_ptr
Posté le 23-02-2010 à 20:24:54  profilanswer
 

bah ecoutes, le SSE ca fait 10 ans que j'en fais et les intrinsic suffise largement, pas besoin d 'assembleur :o
 
Je te renvois aussi à mes papeirs de confs :o

n°1968702
Un Program​meur
Posté le 23-02-2010 à 20:28:50  profilanswer
 

Joel F a écrit :

Assembleur: ca sert àrien, le compilo ets plus fort que toi.


 

xilebo a écrit :

Quand je vois les performances des algos qu'a écrit un des programmeurs avec qui je bosse en assembleur MMX et SSE pour faire un scale soft (avec filtrage bilinéaire) sur une image video (car pas de prise en charge matérielle par la carte vidéo), je ne serais pas aussi affirmatif.

 
 
En général, tant que tu essaies de respecter les mêmes contraintes que celles que le compilateur respecte, Joel a raison.  Si tu peux profiter du non respect de ces contraintes (ne pas respecter l'ABI, utiliser des instructions que le compilateur n'utilise pas, faire des hypothèses sur les valeurs, ...), tu peux gagner beaucoup.  Et parfois il y a des cas particuliers (ça ne me surprendrait pas que la vectorisation soit toujours un point relativement faible des compilateurs).
 


---------------
The truth is rarely pure and never simple (Oscar Wilde)
n°1968710
Glock 17Pr​o
Posté le 23-02-2010 à 21:27:04  profilanswer
 

Joel F a écrit :

C et C++ sont equivalent quand on fait du C++ propre (ie prog. générique et non objet).
 
Assembleur: ca sert àrien, le compilo ets plus fort que toi.


prog générique c'est template ?


---------------
.
n°1968712
Nival
Posté le 23-02-2010 à 21:36:44  profilanswer
 

Merci pour toutes ces réponses!
 
Bon je sais pas si le compilo fait mieux que moi, mais j'avais fait l'expérience de quelques lignes de codes écrites en ASM et le même code retranscrit en C (la simplicité du code en question devais assurer que mon code C soit proche du minimal faisable), et en décompilant le prog issu du C y'avait quand même beaucoup plus d'instructions que dans ma version assembleur "pur", notamment de mémoire des sauts conditionnels en pagaye quand mon code n'en utilisait qu'un (voire pas du tout...). Après la répercussion sur la vitesse d'exécution est peut-être insignifiante, c'est effectivement possible. En tout cas c'est ce qui me faisait penser que je pouvais y gagner en écrivant en ASM des routines simples mais qui devront se répéter des dizaines de milliers de fois par secondes (pour pas dire des millions de fois par seconde, j'ajusterai mes prétention à la réalité des choses... :D), plutôt qu'en C.
 
En revanche je ne connaissait pas les "intrinsic" et ma foi mes recherches faites sur la toile ne donnent pas beaucoup d'éléments de réponse quand à ce de quoi il s'agit concrètement et comment les utiliser (apparemment a dépend du compilo et du processeur (logique ma foi), j'ai vu notamment tout un index de références pour Visual C++, mais qu'en est-il des autres compilateurs??).
 
Sinon du coup pour ma question première C ou C++, je vais finalement me décider à jeter un œil au C++, et j'aviserai selon que la philosophie me parle ou pas par rapport à ce que j'entreprends de faire. En tout cas vous me rassurez sur le fait que l'utilisation du C++ ne "ralentira" pas mon programme (si bien utilisé j'entends bien ;) ).
 
Bon je verrai après pour l'ASM ou pas, j'ai le temps, je n'en suis qu'au tout début de l'entreprise, dire que je ne maitrise même pas encore les langages que je compte utiliser!! :D
(probablement que je commencerai par écrire les routines en C/C++, puis selon les performances obtenus je testerai l'ASM sur qqs routines "clefs" pour juger du gain, et poursuivrai l'optmisation à la main si les essais sont concluant ; enfin... dans l'hypothèse où j'arrive à intégrer de l'ASM pas trop "baveux" dans mon code, où encore si personne ne me convainc de me pencher plus avant ses fameux "intrinsic" à la place! ;) )

Message cité 1 fois
Message édité par Nival le 23-02-2010 à 21:45:47
n°1968714
Joel F
Real men use unique_ptr
Posté le 23-02-2010 à 21:53:48  profilanswer
 

Un Programmeur a écrit :

 
Et parfois il y a des cas particuliers (ça ne me surprendrait pas que la vectorisation soit toujours un point relativement faible des compilateurs).


Oui car la plupart des compilos ne vectorise qu'à l'etape de peep-hole optimization et ne vectorise rien des que les boucles ont des bornes non définis au compile-time. Mais je repete, les intrinsic C vectoriel suffise pas besoin d'assembleur pour ça.

mood
Publicité
Posté le 23-02-2010 à 21:53:48  profilanswer
 

n°1968715
Joel F
Real men use unique_ptr
Posté le 23-02-2010 à 21:54:12  profilanswer
 

Glock 17Pro a écrit :


prog générique c'est template ?


 
entre autre, c'ets surtout une méthode.
http://www.generic-programming.org/

n°1968716
Joel F
Real men use unique_ptr
Posté le 23-02-2010 à 21:56:01  profilanswer
 

Nival a écrit :


Bon je sais pas si le compilo fait mieux que moi, mais j'avais fait l'expérience de quelques lignes de codes écrites en ASM et le même code retranscrit en C (la simplicité du code en question devais assurer que mon code C soit proche du minimal faisable), et en décompilant le prog issu du C y'avait quand même beaucoup plus d'instructions que dans ma version assembleur "pur", notamment de mémoire des sauts conditionnels en pagaye quand mon code n'en utilisait qu'un (voire pas du tout...). Après la répercussion sur la vitesse d'exécution est peut-être insignifiante, c'est effectivement possible. En tout cas c'est ce qui me faisait penser que je pouvais y gagner en écrivant en ASM des routines simples mais qui devront se répéter des dizaines de milliers de fois par secondes (pour pas dire des millions de fois par seconde, j'ajusterai mes prétention à la réalité des choses... :D), plutôt qu'en C.


Ca fait des années que regarder le nombre d'instructions assembleur ne veut rien dire. Tout les procs sont des super-scalaires avec pipelines.
Se faire chier à ecrire de l'assembleur c'ets bien aimé ce casser le groin pour avoir du code non portbale et difficlement maitnenable.

n°1968720
bjone
Insert booze to continue
Posté le 23-02-2010 à 22:04:40  profilanswer
 

1 - Fait de l'OpenGl 3, a partir du moment où tu as du travail GPU c'est l'efficacité GPU qui prime
2 - Bien utilisé, le C++ est aussi perfs que le C, donc...
Pour l'asm dans un moteur 3D, tu as des zones chaudes coté CPU, mais ça reste d'abord un boulot algorithmique....


Message édité par bjone le 23-02-2010 à 22:07:04
n°1968727
Nival
Posté le 23-02-2010 à 22:54:05  profilanswer
 

@Joel F:
Peut-être bien mais comme les routines que je compte utiliser vont avoir besoin d'être probablement répétées de façon extrêmement denses dans le temps (gestion en temps réel d'interactions complexes entre de trés grands tableaux de données), autant économiser du pipeline, non?
Et pour ce qui est de ce "casser le groin", pour le type de fonctions individuellement relativement simples que je compte réaliser, je ne vois pas en quoi cela sera compliqué, j'ai jamais eu de soucis pour de l'algorithmie simple en assembleur.
Probablement plus "casse groin" en revanche d'intégrer ça a du code en C... Enfin je verrai bien le moment venu! :p

 

@bjone:
J'avoue que j'ai du mal à trouver des ressources pertinentes pour débuter l'OpenGL directement par la version 3, la plupart des pesonnes parlent plus de comment évoluer d'OpenGL 2 vers 3, donc actuellement je me résout à commencer par les "vielles" versions... :(
Sinon l'ASM c'est en fait pas pour le moteur 3D, que je gérerai effectivement essentiellement via l'OpenGL ;) (et pour lequel soit dit en passant je n'aurai pas grande prétention technique), mais pour la gestion de l'environnement pour laquelle mon but est de créer une sorte de modélisation d'écosystème en temps-réel avec donc des interactions riches et nombreuses entre le (plus ou moins :p) grand nombre d'"êtres" qui le composera, à base de règles comportementales élémentaires. (tout un programme! :D)

Message cité 2 fois
Message édité par Nival le 23-02-2010 à 23:02:51
n°1968744
Joel F
Real men use unique_ptr
Posté le 24-02-2010 à 08:28:52  profilanswer
 

Nival a écrit :

@Joel F:
Peut-être bien mais comme les routines que je compte utiliser vont avoir besoin d'être probablement répétées de façon extrêmement denses dans le temps (gestion en temps réel d'interactions complexes entre de trés grands tableaux de données), autant économiser du pipeline, non?


Non du tout. Cours lire un cours d'architecture des ordinateurs modernes car la tu melange un peu tout. Vouloir faire du l337 niveau optim sans connaitre comment une machine actuelle fonctionne, c'est un peu contre-productif. goto cours de Daniel Etiemble ou achéte le Henney&Patterson.
 
les pipelines sont justement là pour accélere les calculs en recouvrant temporellement des sections de codes indépendantes dans le flot d'exécution. Donc t'as plutto envie qu'il soit bien rempli ton pipeline.
 
Je me répéte mais actuellement le goulot d'étranglement n'est pas le proc mais la RAM, donc les optimsiations interessantes à faire sont celles qui ménagent le cache. Et celle là ce font très bien sans assembleur.
 

Nival a écrit :

@Joel F:
Et pour ce qui est de ce "casser le groin", pour le type de fonctions individuellement relativement simples que je compte réaliser, je ne vois pas en quoi cela sera compliqué, j'ai jamais eu de soucis pour de l'algorithmie simple en assembleur.


Ca devient compliqué quand tu voudras justement optimisé. Déroulé une boucle en C++ c'ets trivial, déroulé PROPREMENT (aka pipeline friendly) en asm, bon courage pour pas ecrire du caca ou pété ton banc de registre.

n°1968749
el muchach​o
Comfortably Numb
Posté le 24-02-2010 à 08:50:14  profilanswer
 

Nival a écrit :

Bonjour tout le monde!

 

Le truc c'est que si je connais(sais) le C, je suis encore jamais passé au C++, chose qui a priori n'est pas "très compliqué" au demeurant, et pourrait m'aider vu l'ampleur du projet... Sauf que je me demande si, si on y gagne en manipulation d'"objets", on y perd pas en performance final du programme? (puisqu'a priori ça semble "plus haut niveau" que le C, en espérant pas dire trop de bêtises!! :whistle:).

 

Donc en gros la question: est-ce que ça vaut la peine dans mon cas que je me lance dans le C++ ou est-ce que je risque d'avoir au final un programme significativement moins performant qu'avec du C relativement bien optimisé, la performance étant un facteur critique de mon projet?

 

Merci par avance de vos réponses!


Carmack, Abrash & co utilisent le C++ depuis au moins Quake, donc bon... vu que t'as un programme ambitieux, ça vaut le coup.


Message édité par el muchacho le 24-02-2010 à 08:52:35
n°1968756
Un Program​meur
Posté le 24-02-2010 à 09:24:11  profilanswer
 

Joel F a écrit :

Mais je repete, les intrinsic C vectoriel suffise pas besoin d'assembleur pour ça.


 
Si ce n'etait pas clair, nous sommes d'accord la-dessus.
 

Nival a écrit :

Peut-être bien mais comme les routines que je compte utiliser vont avoir besoin d'être probablement répétées de façon extrêmement denses dans le temps (gestion en temps réel d'interactions complexes entre de trés grands tableaux de données), autant économiser du pipeline, non?


 
C'est quoi le dernier processeur pour lequel tu as ete reellement capable d'ecrire de l'assembleur optimise.  (Moi a partir du pentium le probleme est devenu trop complexe pour ma petite tete; j'ai une comprehension d'ensemble assez bonne des micro-architectures, mais je n'en maitrise plus les details au point de pretendre etre capable d'ecrire du code optimise).
 

Joel F a écrit :

C++ propre (ie prog. générique et non objet).


 
J'ai du mal a considerer l'un plus propre que l'autre.  Dans les annees 90, je trouvais qu'on faisait de l'objet ou ce n'etait pas adapte (vu d'cici, Java & C# ont l'air d'avoir continue sur cette voie d'ailleurs), mais il y a eu un renversement de tendance et j'aurais plutot tendance a trouver qu'en C++, la mode est de l'eviter meme quand il est adapte.


---------------
The truth is rarely pure and never simple (Oscar Wilde)
n°1968760
Joel F
Real men use unique_ptr
Posté le 24-02-2010 à 09:40:37  profilanswer
 

Au lieu de propre j'aurait du dire, en effet ,adapté.  
Faire du c++ avec du polymorphisme dynamique qd c'est inutile,c'est balot

n°1968869
Nival
Posté le 24-02-2010 à 12:35:43  profilanswer
 

Ok, merci Joel pour toutes ces précisions, je vais d'abord me pencher sur le C++ alors avant d'essayer de maitriser les architectures "super-pipelinées", je verrai après si j'ai VRAIMENT besoin d'optimisation au delà de celle de mes algo et de mon code C++... ;)
 
@Programmeur: le dernier proc surlequel j'ai fait de l'ASM c'était un pentium première génération, mais je n'ai pas la prétention d'avoir fait qqchose de réellement optimisé... (surtout après avoir lu vos remarques!! :D)
 
@el muchacho: merci pour ces références plutôt rassurantes ma foi! (d'autant que sur le Quake premier du nom au moins, le moteur 3D fonctionnait entièrement en software, et marchait pas mal, qui plus est un des premiers moteurs "full 3D" si je ne m'abuse, et ça c'est du taf pour le proc!)

n°1968872
Nival
Posté le 24-02-2010 à 12:48:39  profilanswer
 

Ah oué j'ai une dernière interrogation en passant: sur un projet un peu ancien j'ai eu l'"impression" que le recours à des calculs en float ralentissait significativement l'exécution par rapport à l'utilisation exclusive de int.
 
Est-ce une réalité ou une vue de l'esprit, notamment sur les proc récents?
 
(sachant que ça ne me dérange absolument pas de travailler en int exclusif pour la partie "modélisation" (je ne parle pas du moteur graphique, OpenGL travaillant manifestement toujours en float))

n°1968881
Un Program​meur
Posté le 24-02-2010 à 13:23:29  profilanswer
 

L'ideal pour les proc recents est un mix des deux (sans trop d'interactions entre flottants et entiers).  Si tu deplaces trop dans un sens ou dans l'autre, tu es bloque.
 
Mais en general, ce qui gene le plus c'est la bande passante.  (Si tu veux faire des recherches, "memory wall" n'est pas un mauvais terme)


---------------
The truth is rarely pure and never simple (Oscar Wilde)
n°1968892
Nival
Posté le 24-02-2010 à 13:55:25  profilanswer
 

Ok thx, c'est clair que pour commencer les calculs ne se feront (autant que faire ce peu) qu'entre types homogènes.
Après "un mix des deux" c'est pour "bien remplir le pipeline" du coup? (pour paraphraser Joel ;)) Profiter de l'opportunité de traiter en parallèle du float et du int? (ou j'ai rien compris?? :pt1cable:)

n°1968985
Joel F
Real men use unique_ptr
Posté le 24-02-2010 à 17:53:02  profilanswer
 

Ce qui coutent c'ets le transtypage float<->int<->double mal maitrisés.
Ca fait lurette que les FPU sont efficace.

 


et chez moi, on ecris proprement puis on bench, on hotspot et on optimsie. On fait jamais à l'envers


Message édité par Joel F le 24-02-2010 à 17:53:42
n°1969015
el muchach​o
Comfortably Numb
Posté le 24-02-2010 à 20:25:20  profilanswer
 

Nival a écrit :

Ah oué j'ai une dernière interrogation en passant: sur un projet un peu ancien j'ai eu l'"impression" que le recours à des calculs en float ralentissait significativement l'exécution par rapport à l'utilisation exclusive de int.

 

Est-ce une réalité ou une vue de l'esprit, notamment sur les proc récents?

 

(sachant que ça ne me dérange absolument pas de travailler en int exclusif pour la partie "modélisation" (je ne parle pas du moteur graphique, OpenGL travaillant manifestement toujours en float))


J'ai moins d'expérience que Joel F et un prog sur l'optimisation C++, mais je crois que sur les processeurs actuels, ça n'est pas trop les unités de calcul qu'on va chercher à optimiser mais les accès mémoire, à savoir gestion des caches, échanges de données avec le GPU et vectorisation.
Et bien sûr multithreading. Tout ça pour dire que l'optimisation sur les architectures modernes est sensiblement plus compliquée qu'à l'époque du Pentium I parce que ça n'est pas trop de la micro optimisation.


Message édité par el muchacho le 24-02-2010 à 20:29:24
n°1969047
Joel F
Real men use unique_ptr
Posté le 24-02-2010 à 21:48:26  profilanswer
 

je plussoie el mucha :o

n°1969524
Nival
Posté le 26-02-2010 à 03:06:49  profilanswer
 

Eh bien un grand MERCI à tous pour vos précieuses réponses!! (et votre patience aussi... ;))
Bon beh j'ai plus qu'à potasser maintenant... :p
(et je vous tiendrai au courant si j'arrive un jour à qqchose! :D)

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  [C/C++] C ou C++ pour des performances optimales?

 

Sujets relatifs
C - attendre n milliseconds entre 2 iterations d'une boucle[C++/CLI] Surcharge de constructeur
C'est quoi un vecteur en language C ?[Résolu] Batch to C
Aide Programmation C ArgumentsIdentification utilisateur en C#
Mastermind en algo puis en CComparaison VB 6.0 / C#
[C++] Spécialisation d'une fonction template un peu tordue...[C/C++] Transformation de fichiers
Plus de sujets relatifs à : [C/C++] C ou C++ pour des performances optimales?


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR