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...
 
Mes connaissances (passées...) en matière de prog sur PC sont le C et l'assembleur (16bit surtout , mais fait un peu joujou avec RosASM aussi), et j'ai un projet un peu (beaucoup... ) 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! ), 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!! ).
 
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!

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

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.

 
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.

 
 
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.
 
 
 

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

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

prog générique c'est template ?

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... ), 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!!
(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! )

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.

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

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.

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

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

@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 ) grand nombre d'"êtres" qui le composera, à base de règles comportementales élémentaires. (tout un programme! )

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.
 

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.

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

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

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

 
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.

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

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

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

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)

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

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

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.

je plussoie el mucha

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