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

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

Marsh Posté le 23-02-2010 à 18:36:13    

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!

Reply

Marsh Posté le 23-02-2010 à 18:36:13   

Reply

Marsh Posté le 23-02-2010 à 19:06:07    

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
Reply

Marsh Posté le 23-02-2010 à 19:39:22    

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.

Reply

Marsh Posté le 23-02-2010 à 19:45:00    

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.

Reply

Marsh Posté le 23-02-2010 à 20:03:53    

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.
 
 
 

Reply

Marsh Posté le 23-02-2010 à 20:24:54    

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

Reply

Marsh Posté le 23-02-2010 à 20:28:50    

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

Marsh Posté le 23-02-2010 à 21:27:04    

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 ?


---------------
.
Reply

Marsh Posté le 23-02-2010 à 21:36:44    

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
Reply

Marsh Posté le 23-02-2010 à 21:53:48    

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.

Reply

Marsh Posté le 23-02-2010 à 21:53:48   

Reply

Marsh Posté le 23-02-2010 à 21:54:12    

Glock 17Pro a écrit :


prog générique c'est template ?


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

Reply

Marsh Posté le 23-02-2010 à 21:56:01    

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.

Reply

Marsh Posté le 23-02-2010 à 22:04:40    

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
Reply

Marsh Posté le 23-02-2010 à 22:54:05    

@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
Reply

Marsh Posté le 24-02-2010 à 08:28:52    

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.

Reply

Marsh Posté le 24-02-2010 à 08:50:14    

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

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 24-02-2010 à 09:24:11    

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

Marsh Posté le 24-02-2010 à 09:40:37    

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

Reply

Marsh Posté le 24-02-2010 à 12:35:43    

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

Reply

Marsh Posté le 24-02-2010 à 12:48:39    

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

Reply

Marsh Posté le 24-02-2010 à 13:23:29    

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

Marsh Posté le 24-02-2010 à 13:55:25    

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

Reply

Marsh Posté le 24-02-2010 à 17:53:02    

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
Reply

Marsh Posté le 24-02-2010 à 20:25:20    

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

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 24-02-2010 à 21:48:26    

je plussoie el mucha :o

Reply

Marsh Posté le 26-02-2010 à 03:06:49    

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)

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed