Le C# est-il vraiment plus lent que le C++, par exemple ?

Question

Cela fait un moment que je m'interroge sur cette question.

Bien sûr, certains éléments du C# ne sont pas optimisés pour la vitesse, et l'utilisation de ces objets ou de modifications du langage (comme LinQ) peut rendre le code plus lent.

Mais si vous n'utilisez aucun de ces ajustements, et que vous comparez simplement les mêmes morceaux de code en C# et C++ (il est facile de traduire l'un à l'autre). Sera-t-il vraiment beaucoup plus lent ?

J'ai vu des comparaisons qui montrent que le C# pourrait même être plus rapide dans certains cas, car en théorie le compilateur JIT devrait optimiser le code en temps réel et obtenir de meilleurs résultats :

Géré ou non géré ?

Il ne faut pas oublier que le compilateur JIT compile le code en temps réel, mais il s'agit d'une surcharge ponctuelle, le même code (une fois atteint et compilé) ne doit pas être compilé à nouveau au moment de l'exécution.

Le GC n'ajoute pas non plus beaucoup de surcharge, sauf si vous créez et détruisez des milliers d'objets (comme en utilisant String au lieu de StringBuilder). Et faire cela en C++ serait également coûteux.

Un autre point que je souhaite soulever est la meilleure communication entre les DLL introduite dans .Net. La plate-forme .Net communique beaucoup mieux que les DLL basées sur Managed COM.

Je ne vois pas de raison inhérente pour laquelle le langage devrait être plus lent, et je ne pense pas vraiment que C# soit plus lent que C++ (à la fois par expérience et par manque de bonne explication) .

Ainsi, un morceau du même code écrit en C# sera-t-il plus lent que le même code en C++ ?
Et si oui, alors POURQUOI ?

Une autre référence (qui en parle un peu, mais sans explication sur le POURQUOI) :

Pourquoi vouloir utiliser C# si c'est plus lent que C++ ?

Answer 1

Ne laissez pas la confusion s'installer !

• Si une application C# est écrite dans le meilleur des cas et une application C++ est écrite dans le meilleur des cas, le C++ est plus rapide.
  Il existe de nombreuses raisons pour lesquelles le C++ est plus rapide que le C# de manière inhérente, comme le fait que le C# utilise une machine virtuelle similaire à la JVM de Java. Fondamentalement, un langage de plus haut niveau est moins performant (s'il est utilisé dans le meilleur des cas).

• Si vous êtes un programmeur professionnel expérimenté en C#, tout comme vous êtes un programmeur professionnel expérimenté en C++, le développement d'une application en C# est beaucoup plus facile et rapide qu'en C++.

De nombreuses autres situations entre ces situations sont possibles. Par exemple, vous pouvez écrire une application C# et une application C++ de sorte que l'application C# fonctionne plus rapidement que l'application C++.

Pour choisir une langue, vous devez tenir compte des circonstances du projet et de son sujet. Pour un projet commercial général, vous devriez utiliser C#. Pour un projet exigeant des performances élevées, comme un convertisseur vidéo ou un projet de traitement d'images, vous devez choisir C++.

Mise à jour :

OK. Comparons quelques raisons pratiques expliquant pourquoi la vitesse de C++ est supérieure à celle de C#. Considérons une application C# bien écrite et la même version C++ :

• C# utilise une VM comme couche intermédiaire pour l'exécution de l'application. Cela entraîne des frais généraux.
• AFAIK CLR ne pourrait pas optimiser tous les codes C# dans la machine cible. Une application C++ pourrait être compilée sur la machine cible avec la plupart des optimisations.
• En C#, l'optimisation la plus poussée possible pour l'exécution signifie une VM la plus rapide possible. La VM a une surcharge de toute façon.
• C# est un langage de plus haut niveau et génère donc plus de lignes de code de programme pour le processus final. (Considérez la différence entre une application Assembly et une application Ruby ! La même situation se présente entre C++ et un langage de plus haut niveau tel que C#/Java).

Si vous préférez obtenir des informations supplémentaires sur la pratique en tant qu'expert, voir ceci . Il porte sur Java mais s'applique également à C#.

Answer 2

La principale préoccupation n'est pas la vitesse, mais la stabilité à travers les versions et les mises à jour de Windows. Win32 est en grande partie immunisé à travers les versions de Windows, ce qui le rend très stable.

Lorsque les serveurs sont mis hors service et que les logiciels sont transférés, il y a beaucoup d'anxiété autour de tout ce qui utilise .Net et généralement beaucoup de panique à propos des versions .Net, mais une application Win32 construite il y a 10 ans continue de fonctionner comme si de rien n'était.

Answer 3

Je me spécialise dans l'optimisation depuis une quinzaine d'années et je réécris régulièrement du code C++, en utilisant autant que possible les intrinsèques du compilateur, car les performances du C++ sont souvent très éloignées de celles dont le CPU est capable. Les performances du cache doivent souvent être prises en compte. De nombreuses instructions mathématiques vectorielles sont nécessaires pour remplacer le code C++ standard à virgule flottante. Une grande partie du code STL est réécrite et s'exécute souvent beaucoup plus rapidement. Les mathématiques et le code qui font un usage intensif des données peuvent être réécrits avec des résultats spectaculaires, lorsque le CPU approche de ses performances optimales.

Rien de tout cela n'est possible en C#. Comparer leurs performances relatives en temps réel est vraiment une question d'une ignorance stupéfiante. Le morceau de code le plus rapide en C++ sera celui où chaque instruction d'assembleur est optimisée pour la tâche à accomplir, sans instructions inutiles - du tout. Lorsque chaque morceau de mémoire est utilisé lorsqu'il est nécessaire, et non copié n fois parce que c'est ce que la conception du langage exige. Chaque mouvement de mémoire requis fonctionne en harmonie avec le cache. Lorsque l'algorithme final ne peut être amélioré, sur la base des exigences exactes en temps réel, en tenant compte de la précision et de la fonctionnalité.

Vous vous approcherez alors d'une solution optimale.

Comparer C# à cette situation idéale est stupéfiant. Le C# ne peut pas rivaliser. En fait, je suis en train de réécrire tout un tas de code C# (quand je dis réécrire, je veux dire le supprimer et le remplacer complètement) parce qu'il n'est même pas dans la même ville, sans parler du parc de balles quand il s'agit de performances en temps réel.

Alors s'il vous plaît, arrêtez de vous faire des illusions. Le C# est lent. Très lent. Tous les logiciels ralentissent, et C# ne fait qu'aggraver ce déclin de la vitesse. Tous les logiciels fonctionnent en utilisant le cycle fetch execute en assembleur (vous savez - sur le CPU). Si vous utilisez 10 fois plus d'instructions, le logiciel sera 10 fois plus lent. Si vous paralysez le cache, il sera encore plus lent. Si vous ajoutez le garbage collect à un logiciel en temps réel, vous êtes souvent trompé en pensant que le code s'exécute "bien", il y a juste ces quelques moments de temps en temps où le code devient "un peu lent pendant un moment".

Essayez d'ajouter un système de collecte de déchets à un code où chaque cycle compte. Je me demande si le logiciel de négociation boursière dispose d'un système de collecte des déchets (vous savez, sur le système fonctionnant sur le nouveau câble sous-marin qui a coûté 300 millions de dollars). Pouvons-nous économiser 300 millisecondes toutes les 2 secondes ? Qu'en est-il du logiciel de contrôle de vol de la navette spatiale - le GC y est-il correct ? Qu'en est-il des logiciels de gestion du moteur des véhicules de compétition ? (où la victoire en une saison peut valoir des millions).

La collecte d'ordures en temps réel est un échec total.

Donc non, catégoriquement, le C++ est beaucoup plus rapide. C# est un bond en arrière.