Discussion :

[Steinvikel]

La plupart des optimisations en langage "compilé" sont faites par le compilateur, pas par le codeur... et la qualité de l'optimisation dépend de : les paramétrage du compilateur, ses limites, et la verbosité du codeur. --> écrire simplement "auto i = 3;" et écrire "static const int i = 3;" n'entraine pas du tout la même profondeur d'optimisation suivant le contexte.

exemple en vidéo de 27:00 à 28:30
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
https://youtu.be/zBkNBP00wJE?t=1596
Dans ce cas précis, tu as oublié un "const" et paff, au lieu de 4 lignes assembleur en mémoire (il fait tourner l'ensemble du programme sur le cache du processeur) tu rajoutes plus de 350 lignes !!.

Je ne suis pas sûr que les erreurs courantes en C# et en C++ soient plus coûteuse chez l'un que chez l'autre, en revanche, il y a peut-être généralement plus de rigueur chez les C++ de par la pluralité paradigmatique (j'étais inspiré, dsl), à l'image du Pascal ou un pet de mouche empêche la compilation.
Bref, je pense que les problèmes de perf sont plus lié à des facteurs convergeant, comme les habitudes communautaires, les nécessités absolues, les facilités, les spécialisations... plutôt que le langage en lui même.

[Aurelien.Regat-Barrel]

Moi j'avais regarder ça : https://www.codeproject.com/Articles...-Csharp-vs-NET

On dit parfois que C++ ne donne pas de la performance, il donne accès à la performance. Les techniques d'optimisations sont les mêmes au delà du langage car c'est le hardware sous jacent qui dicte ça, et c'est une expertise à part entière. La différence en C++ c'est qu'il est plus "hardware sympathic" et en ne te faisant pas payer pour ce que tu n'utilises pas. Au hasard le garbage collector qui met régulièrement en micro-pause ton programme et déclenche des recopies complète de tes data en mémoire.

Pour ce qui est des micro benchmark, ile ne veulent pas dire grand chose car la performance dans und vraie application se trouve aussi (voire surtout) dans la data, et plus exactement dans l'empreinte et l'agencement mémoire de ton programme. Dès que tu satures la taille de tes caches (quelques Mo), les performances s'écroulent (du genre 10 à 50 fois plus lent). Et si tes data ne sont pas ordonnées de manière continue, c'est la même sanction. Et donc un langage qui t'imposent d'allouer à tout va sur le heap en rajoutant en plus un overhead pour le type System.Object de base obligatoire c'est catastrophique pour les perfs passé un certaine taille.

Une intro de qualité par un exellent speaker (vers la 22eme min):
https://channel9.msdn.com/Events/Build/2014/2-661

Concernant les erreurs de programmation qui dégradent les perf, la règle d'or en optimisation c'est de commencer par profiler ton code, ainsi tu découvres vite les erreurs de ce type. Mais aussi de nos jours on a des outils d'analyse statique de code (gratuits) qui peuvent détecter certaines copies inutiles. CLion par exemple te signale dans ton code ce genre de cas et t'invite à faire un move ou un const ref.

Enfin, la tendance moderne est de prendre en input un string_view ou un span quand tu ne fait que consulter la data, de cette manière il n'y a aucun risque en terme de perfs en plus d'avoir une meilleur sémantique vis à vis du code.

Ces exemples résument mes propos initiaux : oui en C++ il est facile (comme dans d'autres langages) d'écrire du code avec de mauvaises performances. Mais une fois localisé, on a beaucoup d'options assez simples pour régler efficacement le problème.

[Matthieu76]

Merci, tout cas est hyper intéressant mais en réalité je suis sur des 99% de la lenteur de mon code vient de la conception des algo et de l'architecture du code. Avoir du code avec des objets contenant des vectors d'objet contenant des vectors d'objet contenant des vectors de float et faire des calculs en boucle sur ces float ça doit être au moins 100 fois plus lent que si j'avais juste un tableau 3D de float. Après si j'avais juste des structs et des tableaux de float j'aurais un code plus rapide mais complètement imbitable avec des erreurs de calcul et d'index partout, un enfer à debugger !

PS : Ne pas oublier les options de compilation, le jour ou j'ai découvert ça j'ai rendu mon code 4 fois plus rapides !

[Juniper62]

il faudrait une traduction du belge vers le français... les nonante et les francisations à outrance, c'est bien de chez eux ça ... pourquoi parler de 'ramasse miettes' alors qu'on parle tous de 'garbage collector'? etc...
et bien, si tout ce que raconte l'article est réel, ça devient beaucoup moins sexy de coder sous Unity ... :s berk