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

Une meilleure façon de voir les choses est que tout est plus lent que le C/C++ parce qu'il s'abstrait plutôt que de suivre le paradigme du bâton et de la boue. C'est ce qu'on appelle la programmation de systèmes pour une raison, vous programmez contre le grain ou le métal nu. En procédant ainsi, vous obtenez une vitesse que vous ne pouvez pas atteindre avec d'autres langages comme C# ou Java. Mais hélas, les racines du C sont de faire les choses à la manière forte, donc vous allez surtout écrire plus de code et passer plus de temps à le déboguer.

Le C est également sensible à la casse, et les objets en C++ suivent également des règles strictes. Par exemple, un cornet de glace violet n'est pas forcément le même qu'un cornet de glace bleu, bien qu'il s'agisse de cônes, ils n'appartiennent pas nécessairement à la famille des cônes et si vous oubliez de définir ce qu'est un cône, vous vous plantez. Ainsi, les propriétés de la crème glacée peuvent ou non être des clones. Maintenant, l'argument de la vitesse, C/C++ utilise l'approche de la pile et du tas, c'est là que le métal nu obtient son métal.

Avec la bibliothèque boost, vous pouvez atteindre des vitesses incroyables ; malheureusement, la plupart des studios de jeux s'en tiennent à la bibliothèque standard. L'autre raison est que les logiciels écrits en C/C++ ont tendance à avoir une taille de fichier énorme, car il s'agit d'une collection géante de fichiers au lieu d'un fichier unique. Notez également que tous les systèmes d'exploitation sont écrits en C, donc en général pourquoi se poser la question de ce qui pourrait être plus rapide !

De plus, la mise en cache n'est pas plus rapide que la gestion pure de la mémoire, désolé mais cela ne tient pas la route. La mémoire est quelque chose de physique, la mise en cache est quelque chose que le logiciel fait afin de gagner en performance. On pourrait également penser que sans mémoire physique, la mise en cache n'existerait tout simplement pas. Cela n'enlève rien au fait que la mémoire doit être gérée à un certain niveau, que ce soit de manière automatisée ou manuelle.

Answer 2

BTW, les applications critiques en termes de temps ne sont pas codées en C# ou Java, principalement en raison de l'incertitude quant au moment où le Garbage Collection sera effectué.

À l'heure actuelle, la vitesse d'application ou d'exécution n'est pas aussi importante qu'auparavant. Les calendriers de développement, la correction et la robustesse sont des priorités plus importantes. Une version rapide d'une application ne sert à rien si elle comporte de nombreux bogues, si elle se bloque souvent ou, pire encore, si elle rate l'occasion d'être commercialisée ou déployée.

Comme les calendriers de développement sont une priorité, de nouveaux langages sortent qui accélèrent le développement. C# est l'un d'entre eux. C# contribue également à la correction et à la robustesse en supprimant les caractéristiques du C++ qui causent des problèmes courants : les pointeurs en sont un exemple.

Les différences de vitesse d'exécution d'une application développée en C# et d'une application développée en C++ sont négligeables sur la plupart des plates-formes. Cela est dû au fait que les goulots d'étranglement de l'exécution ne dépendent pas du langage mais généralement du système d'exploitation ou des E/S. Par exemple, si C++ exécute une fonction en 5 ms mais que C# utilise 2 ms, et que l'attente des données prend 2 secondes, le temps passé dans la fonction est insignifiant comparé au temps d'attente des données.

Choisissez un langage qui convient le mieux aux développeurs, à la plate-forme et aux projets. Travaillez en fonction des objectifs de correction, de robustesse et de déploiement. La vitesse d'une application doit être traitée comme un bogue : donnez-lui la priorité, comparez-la aux autres bogues et corrigez-la si nécessaire.

Answer 3

Largement discuté, voir [c#] [performance]

mais beaucoup dépend de l'application et de la mise en œuvre.

Answer 4

Pourquoi écrire une petite application qui ne nécessite pas beaucoup d'optimisation en C++, s'il existe un chemin plus rapide (C#) ?

Answer 5

Il n'est pas vraiment possible d'obtenir une réponse exacte à votre question, à moins d'effectuer des tests de référence sur des systèmes spécifiques. Cependant, il est toujours intéressant de réfléchir à certaines différences fondamentales entre des langages de programmation comme C# et C++.

Compilation

L'exécution du code C# nécessite une étape supplémentaire au cours de laquelle le code est mis en forme (JIT). En ce qui concerne les performances, cela favorisera le C++. De plus, le compilateur JIT n'est capable d'optimiser le code généré qu'au sein de l'unité de code JIT (par exemple, une méthode), alors qu'un compilateur C++ peut optimiser les appels de méthode en utilisant des techniques plus agressives.

Cependant, le compilateur JIT est capable d'optimiser le code machine généré pour qu'il corresponde étroitement au matériel sous-jacent, ce qui lui permet de tirer parti des caractéristiques matérielles supplémentaires si elles existent. À ma connaissance, le compilateur JIT de .NET ne fait pas cela, mais il serait capable de générer un code différent pour les CPU Atom et Pentium.

Accès à la mémoire

L'architecture de collecte des déchets peut, dans de nombreux cas, créer des modèles d'accès à la mémoire plus optimaux que le code C++ standard. Si la zone de mémoire utilisée pour la première génération est suffisamment petite, elle peut rester dans le cache du CPU, ce qui augmente les performances. Si vous créez et détruisez un grand nombre de petits objets, le coût de la gestion du tas géré peut être inférieur à ce qui est requis par le runtime C++. Là encore, cela dépend fortement de l'application. Une étude Python de la performance démontre qu'une application Python gérée spécifique est capable de s'adapter beaucoup mieux que la version compilée, grâce à des modèles d'accès à la mémoire plus optimaux.