Combien de temps est C ++ que C #?

Ou est-ce maintenant le contraire?

D’après ce que j’ai entendu, il y a des domaines dans lesquels C # s’avère plus rapide que C ++, mais je n’ai jamais eu le courage de le tester moi-même.

Certains d’entre vous ont pu expliquer ces différences en détail ou me diriger vers le bon endroit pour obtenir des informations à ce sujet.

    Il n’y a pas de raison ssortingcte pour qu’un langage de type bytecode comme C # ou Java doté d’un JIT ne puisse pas être aussi rapide que le code C ++. Cependant, le code C ++ était beaucoup plus rapide pendant longtemps, et aujourd’hui encore, il l’est encore. Cela est principalement dû aux optimisations JIT plus complexes qui sont compliquées à mettre en œuvre, et les solutions vraiment géniales n’arrivent que tout à l’heure.

    Donc, le C ++ est plus rapide, dans de nombreux cas. Mais ce n’est qu’une partie de la réponse. Les cas où le C ++ est en fait plus rapide, sont des programmes hautement optimisés, où les programmeurs experts ont optimisé complètement le code. Cela prend non seulement beaucoup de temps (et donc coûte cher), mais entraîne souvent des erreurs dues à une optimisation excessive.

    En revanche, le code dans les langages interprétés est plus rapide dans les versions ultérieures du runtime (.NET CLR ou Java VM), sans que vous ne fassiez rien. Et il y a beaucoup d’optimisations utiles que les compilateurs JIT peuvent faire qui sont tout simplement impossibles dans les langages avec des pointeurs. En outre, certains soutiennent que la récupération de la mémoire devrait généralement être aussi rapide ou plus rapide que la gestion manuelle de la mémoire, et dans de nombreux cas, elle l’est. Vous pouvez généralement implémenter et réaliser tout cela en C ++ ou C, mais cela va être beaucoup plus compliqué et sujet aux erreurs.

    Comme l’a dit Donald Knuth, «l’optimisation prématurée est la racine de tout mal». Si vous savez vraiment que votre application consistera principalement en une arithmétique critique très performante, et que ce sera le goulot d’étranglement, et qu’elle sera certainement plus rapide en C ++, et que vous êtes sûr que C ++ ne sera pas en conflit avec vos autres exigences, allez pour C ++. Dans tous les autres cas, concentrez-vous sur l’implémentation correcte de votre application dans la langue qui vous convient le mieux, puis recherchez les goulots d’étranglement des performances si elle s’exécute trop lentement, puis réfléchissez à la manière d’optimiser le code. Dans le pire des cas, vous devrez peut-être appeler le code C via une interface de fonction étrangère. Vous pourrez donc toujours écrire des parties critiques dans un langage de niveau inférieur.

    N’oubliez pas qu’il est relativement facile d’optimiser un programme correct, mais qu’il est beaucoup plus difficile de corriger un programme optimisé.

    Donner des pourcentages réels d’avantages de vitesse est impossible, cela dépend en grande partie de votre code. Dans de nombreux cas, l’implémentation du langage de programmation n’est même pas le goulot d’étranglement. Prenez les points de repère sur http://benchmarksgame.alioth.debian.org/ avec beaucoup de scepticisme, car ceux-ci testent en grande partie le code arithmétique, qui n’est probablement pas du tout similaire à votre code.

    C # peut ne pas être plus rapide, mais cela rend VOUS / ME plus rapide. C’est la mesure la plus importante pour ce que je fais. 🙂

    C’est cinq oranges plus vite. Ou plutôt: il ne peut y avoir de réponse globale (correcte). C ++ est un langage compilé de manière statique (mais il y a aussi une optimisation guidée par les profils), C # s’exécute avec l’aide d’un compilateur JIT. Il y a tellement de différences que l’on ne peut pas répondre à des questions comme «combien plus rapidement», même en donnant des ordres de grandeur.

    D’après mon expérience (et j’ai beaucoup travaillé avec les deux langues), le principal problème avec C # par rapport à C ++ est la consommation élevée de mémoire et je n’ai pas trouvé de moyen de le contrôler. C’était la consommation de mémoire qui finirait par ralentir le logiciel .NET.

    Un autre facteur est que le compilateur JIT ne peut pas consacrer trop de temps à effectuer des optimisations avancées, car il s’exécute à l’exécution, et l’utilisateur le remarque si cela prend trop de temps. D’un autre côté, un compilateur C ++ a tout le temps nécessaire pour effectuer des optimisations au moment de la compilation. Ce facteur est beaucoup moins important que la consommation de mémoire, à mon humble avis.

    Je vais commencer par être en désaccord avec une partie de la réponse acceptée (et bien votée) à cette question en déclarant:

    Il existe de nombreuses raisons pour lesquelles le code JITted s’exécutera plus lentement qu’un programme C ++ optimisé (ou tout autre langage sans temps d’exécution), y compris:

    • Les cycles de calcul consacrés au code JITting au moment de l’exécution sont par définition indisponibles pour une utilisation dans l’exécution du programme.

    • tous les chemins d’access chauds dans JITter seront en concurrence avec votre code pour les instructions et le cache de données dans la CPU. Nous soaps que le cache domine en matière de performances et que les langages natifs comme le C ++, par définition, n’ont pas ce type de conflit.

    • le budget temps d’un optimiseur d’exécution est forcément beaucoup plus contraint que celui d’un optimiseur à la compilation (comme l’a souligné un autre commentateur)

    Bottom line: En fin de compte, vous serez certainement en mesure de créer une implémentation plus rapide en C ++ que vous pourriez en C # .

    Maintenant, avec cela dit, combien plus rapide n’est vraiment pas quantifiable, car il y a trop de variables: la tâche, le domaine problématique, le matériel, la qualité des implémentations et de nombreux autres facteurs. Vous aurez effectué des tests sur votre scénario pour décider si l’effort supplémentaire et la complexité en valent la peine.

    C’est un sujet très long et complexe, mais j’estime qu’il vaut la peine de mentionner que l’optimiseur d’exécution de C # est excellent et qu’il est capable d’effectuer certaines optimisations dynamics à l’exécution qui ne sont tout simplement pas disponibles à la compilation ( statique) optimiseur. Même avec ceci, l’avantage est toujours profondément dans la cour de l’application native, mais l’optimiseur dynamic est la raison du qualificatif ” presque certainement” donné ci-dessus.

    En termes de performance relative, j’ai également été troublé par les chiffres et les discussions que j’ai pu voir dans d’autres réponses, alors j’ai pensé que je mettrais la main à la pâte tout en soutenant les déclarations que j’ai faites ci-dessus.

    Une grande partie du problème avec ces tests de performances est que vous ne pouvez pas écrire de code C ++ comme si vous écriviez C # et espérez obtenir des résultats représentatifs (par exemple, des milliers d’allocations de mémoire en C ++ vous donneront des nombres terribles).

    Au lieu de cela, j’ai écrit un code C ++ légèrement plus idiomatique et comparé avec le code C # @Wiory fourni. Les deux principaux changements apportés au code C ++ ont été les suivants:

    1) vecteur utilisé :: reserve ()

    2) aplati le tableau 2D en 1d pour obtenir une meilleure localisation de cache (bloc contigu)

    C # (.NET 4.6.1)

    private static void TestArray() { const int rows = 5000; const int columns = 9000; DateTime t1 = System.DateTime.Now; double[][] arr = new double[rows][]; for (int i = 0; i < rows; i++) arr[i] = new double[columns]; DateTime t2 = System.DateTime.Now; Console.WriteLine(t2 - t1); t1 = System.DateTime.Now; for (int i = 0; i < rows; i++) for (int j = 0; j < columns; j++) arr[i][j] = i; t2 = System.DateTime.Now; Console.WriteLine(t2 - t1); } 

    Temps d'exécution (version): Init: 124ms, remplissage: 165ms

    C ++ 14 (Clang v3.8 / C2)

     #include  #include  auto TestSuite::ColMajorArray() { constexpr size_t ROWS = 5000; constexpr size_t COLS = 9000; auto initStart = std::chrono::steady_clock::now(); auto arr = std::vector(); arr.reserve(ROWS * COLS); auto initFinish = std::chrono::steady_clock::now(); auto initTime = std::chrono::duration_cast(initFinish - initStart); auto fillStart = std::chrono::steady_clock::now(); for(auto i = 0, r = 0; r < ROWS; ++r) { for (auto c = 0; c < COLS; ++c) { arr[i++] = static_cast(r * c); } } auto fillFinish = std::chrono::steady_clock::now(); auto fillTime = std::chrono::duration_cast(fillFinish - fillStart); return std::make_pair(initTime, fillTime); } 

    Temps d'exécution (Release): Init: 398µs (oui, c'est microsecondes), Fill: 152ms

    Temps d'exécution total: C #: 289 ms, C ++ 152 ms (environ 90% plus rapide)

    Observations

    • Changer l'implémentation C # pour la même implémentation de tableau 1d a donné Init: 40ms, Fill: 171ms, Total: 211ms ( C ++ était encore presque 40% plus rapide ).

    • Il est beaucoup plus difficile de concevoir et d'écrire du code "rapide" en C ++ que d'écrire du code "normal" dans l'un ou l'autre langage.

    • C'est (peut-être) étonnamment facile d'obtenir de mauvaises performances en C ++; nous l'avons vu avec la performance des vecteurs sans réserve. Et il y a beaucoup de pièges comme celui-ci.

    • Les performances de C # sont plutôt étonnantes quand on considère tout ce qui se passe à l'exécution. Et cette performance est relativement facile d'access.

    • Plus de données anecdotiques comparant les performances de C ++ et C #: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

    L'essentiel est que C ++ vous donne beaucoup plus de contrôle sur les performances. Voulez-vous utiliser un pointeur? Une référence? Emstackr de la mémoire? Tas? Polymorphisme dynamic ou élimination du temps d'exécution d'une vtable avec polymorphism statique (via templates / CRTP)? En C ++, vous devez ... faire tous ces choix (et plus encore) vous-même, idéalement pour que votre solution réponde au mieux aux problèmes que vous vous posez.

    Demandez-vous si vous voulez réellement ou avez besoin de ce contrôle, car même pour l'exemple sortingvial ci-dessus, vous pouvez voir que même s'il y a une amélioration significative des performances, il faut investir davantage pour y accéder.

    Un scénario particulier où C ++ a toujours le dessus (et le fera pour les années à venir) se produit lorsque des décisions polymorphes peuvent être prédéterminées au moment de la compilation.

    En général, l’encapsulation et la prise de décision différée sont une bonne chose car cela rend le code plus dynamic, plus facile à adapter à l’évolution des besoins et plus facile à utiliser comme cadre. C’est pourquoi la programmation orientée object en C # est très productive et peut être généralisée sous le terme de «généralisation». Malheureusement, ce type particulier de généralisation a un coût lors de l’exécution.

    Habituellement, ce coût n’est pas substantiel, mais il existe des applications où la surcharge des appels de méthodes virtuelles et de la création d’objects peut faire la différence (d’autant plus que les méthodes virtuelles empêchent d’autres optimisations telles que l’inlinéation d’appels de méthodes). C’est là que C ++ présente un avantage considérable, car vous pouvez utiliser des modèles pour obtenir un type de généralisation différent, sans impact sur l’exécution, mais qui n’est pas nécessairement moins polymorphe que la POO. En fait, tous les mécanismes qui constituent la POO peuvent être modélisés en utilisant uniquement des techniques de modèle et une résolution à la compilation.

    Dans de tels cas (et certes, ils sont souvent limités à des domaines à problèmes spéciaux), C ++ gagne contre C # et des langages comparables.

    C ++ (ou C en l’occurrence) vous donne un contrôle précis sur vos structures de données. Si vous voulez changer de bit, vous avez cette option. Les grandes applications Java ou .NET gérées (OWB, Visual Studio 2005 ) qui utilisent les structures de données internes des bibliothèques Java / .NET les transportent. J’ai vu des sessions de concepteurs OWB utilisant plus de 400 Mo de RAM et des fichiers BIDS pour la conception de cubes ou d’ ETL qui entrent également dans les 100 Mo.

    Sur une charge de travail prévisible (comme la plupart des tests de performances répétés plusieurs fois), un JIT peut vous fournir un code suffisamment optimisé pour qu’il n’y ait pas de différence pratique.

    IMO sur les applications volumineuses La différence n’est pas tant le JIT que les structures de données que le code lui-même utilise. Lorsqu’une application est lourde en mémoire, vous obtiendrez une utilisation du cache moins efficace. Les erreurs de cache sur les processeurs modernes sont assez coûteuses. Où C ou C ++ gagne vraiment, c’est là que vous pouvez optimiser votre utilisation des structures de données pour jouer avec le cache du processeur.

    Pour les graphiques, la classe C # Graphics standard est beaucoup plus lente que GDI accessible via C / C ++. Je sais que cela n’a rien à voir avec le langage en soi, plus avec la plate-forme .NET totale, mais Graphics est ce qui est offert au développeur en tant que remplacement GDI, et ses performances sont tellement mauvaises que je n’oserais même pas faire de graphismes avec ça.

    Nous avons un benchmark simple que nous utilisons pour voir à quelle vitesse une bibliothèque graphique est, et qui consiste simplement à dessiner des lignes aléatoires dans une fenêtre. C ++ / GDI est toujours rapide avec 10000 lignes alors que C # / Graphics a du mal à faire 1000 en temps réel.

    La récupération de la mémoire est la principale raison pour laquelle Java # NE PEUT PAS être utilisé pour les systèmes en temps réel.

    1. Quand le GC se produira-t-il?

    2. Combien de temps cela prendra-t-il?

    Ceci est non déterministe.

    Nous avons dû déterminer si C # était comparable à C ++ dans les performances et j’ai écrit des programmes de test pour cela (en utilisant Visual Studio 2005 pour les deux langues). Il s’est avéré que sans la collecte des ordures et en considérant uniquement le langage (pas le framework), C # a fondamentalement les mêmes performances que C ++. L’allocation de mémoire est beaucoup plus rapide en C # qu’en C ++ et C # a un léger avantage en matière de déterminisme lorsque les tailles de données augmentent au-delà des limites des lignes de cache. Cependant, tout cela a finalement dû être payé et il y a un coût énorme sous la forme de résultats de performances non déterministes pour C # dus à la récupération de place.

    Comme d’habitude, cela dépend de l’application. Il existe des cas où C # est probablement négligeable, et d’autres où C ++ est 5 ou 10 fois plus rapide, en particulier dans les cas où les opérations peuvent être facilement simulées.

    Je sais que ce n’est pas ce que vous demandiez, mais C # est souvent plus rapide que C ++, ce qui est un gros avantage dans un contexte commercial.

    Les langages .NET peuvent être aussi rapides que le code C ++, voire plus rapides, mais le code C ++ aura un débit plus constant, car le runtime .NET doit s’arrêter pour GC , même s’il est très intelligent sur ses pauses.

    Donc, si vous avez du code qui doit être exécuté rapidement sans aucune pause, .NET introduira une latence à un moment donné , même si vous faites très attention au moteur d’exécution.

    C / C ++ peut être beaucoup plus performant dans les programmes où il y a de grands tableaux ou des boucles / itérations lourdes sur des tableaux (quelle que soit leur taille). C’est la raison pour laquelle les graphiques sont généralement beaucoup plus rapides en C / C ++, car les opérations sur des tableaux lourds sous-tendent presque toutes les opérations graphiques. .NET est notoirement lent dans les opérations d’indexation de tableaux en raison de toutes les vérifications de sécurité, et cela est particulièrement vrai pour les tableaux multidimensionnels (et, oui, les tableaux rectangulars en C # sont encore plus lents que les tableaux en C #).

    Les bonus de C / C ++ sont plus prononcés si vous vous en tenez directement aux pointeurs et évitez les Boost, std::vector et autres conteneurs de haut niveau, ainsi que toutes les petites fonctions possibles. Utilisez des tableaux à l’ancienne si possible. Oui, vous aurez besoin de plus de lignes de code pour accomplir la même chose en Java ou en C # car vous évitez les conteneurs de haut niveau. Si vous avez besoin d’un tableau de taille dynamic, il vous suffit de vous rappeler de coupler votre new T[] avec une instruction delete[] correspondante (ou d’utiliser std::unique_ptr ) – le prix pour la vitesse supplémentaire est que vous devez coder plus soigneusement . Mais en contrepartie, vous vous débarrassez de la surcharge de la mémoire gérée / du ramasse-miettes, qui peut facilement représenter 20% ou plus du temps d’exécution de programmes fortement orientés object en Java et .NET coûts d’indexation de la masortingce de mémoire. Les applications C ++ peuvent également bénéficier de certains commutateurs astucieux du compilateur dans certains cas spécifiques.

    Je suis un programmeur expert en C, C ++, Java et C #. J’ai récemment eu la rare occasion d’implémenter exactement le même programme algorithmique dans les trois dernières langues. Le programme comportait de nombreuses opérations mathématiques et multidimensionnelles. Je l’ai fortement optimisé dans les 3 langues. Les résultats étaient typiques de ce que je vois habituellement dans les comparaisons moins rigoureuses: Java était environ 1,3 fois plus rapide que C # (la plupart des JVM sont plus optimisées que le CLR) et la version du pointeur brut C ++ était environ 2.1 fois plus rapide que C #. Notez que le programme C # n’utilisait que du code sécurisé – à mon avis, vous pourriez aussi bien le coder en C ++ avant d’utiliser le mot clé unsafe .

    De peur que quelqu’un pense avoir quelque chose contre C #, je terminerai en disant que C # est probablement ma langue préférée. C’est le langage de développement le plus logique, intuitif et rapide que j’ai rencontré jusqu’à présent. Je fais tout mon prototypage en C #. Le langage C # présente de nombreux petits avantages par rapport à Java (oui, je sais que Microsoft a eu la chance de corriger un grand nombre de problèmes de Java en entrant en jeu tardivement et sans doute en copiant Java). Toast à la classe de Calendar de Java n’importe qui? Si Microsoft consacrait un réel effort à optimiser le CLR et le .NET JITter, C # pourrait sérieusement prendre le relais. Je suis vraiment surpris qu’ils n’aient pas déjà fait – ils ont fait tellement de choses dans le langage C #, pourquoi ne pas les suivre avec des optimisations de compilateurs percutantes? Peut-être que si nous supplions tous.

    > D’après ce que j’ai entendu …

    Votre difficulté semble être de décider si ce que vous avez entendu est crédible et cette difficulté sera simplement répétée lorsque vous tenterez d’évaluer les réponses sur ce site.

    Comment allez-vous décider si les choses que les gens disent ici sont plus ou moins crédibles que ce que vous avez entendu initialement?

    Une façon serait de demander des preuves .

    Lorsque quelqu’un déclare “il y a des domaines dans lesquels C # s’avère plus rapide que C ++”, demandez-lui pourquoi il dit cela , demandez-lui de vous montrer des mesures, demandez-lui de vous montrer des programmes. Parfois, ils se sont simplement trompés. Parfois, vous découvrez qu’ils ne font qu’exprimer une opinion plutôt que de partager quelque chose qu’ils peuvent montrer comme étant vrais.

    Souvent, l’information et l’opinion sont mêlées à ce que les gens réclament, et vous devrez essayer de déterminer lequel est qui. Par exemple, des réponses à ce forum:

    • “Prenez les points de repère sur http://shootout.alioth.debian.org/ avec beaucoup de scepticisme, car ceux-ci testent en grande partie le code arithmétique, qui n’est probablement pas similaire à votre code.”

      Demandez-vous si vous comprenez vraiment ce que «ces tests sont en grande partie constitués de code arithmétique» , puis demandez-vous si l’auteur vous a réellement montré que sa revendication est vraie.

    • “C’est un test plutôt inutile, car cela dépend vraiment de l’optimisation des programmes individuels; j’ai réussi à accélérer certains d’entre eux de 4 à 6 fois ou plus, ce qui montre clairement que la comparaison entre des programmes non optimisés est plutôt idiot.”

      Demandez-vous si l’auteur vous a réellement montré qu’il était parvenu à «accélérer certains d’entre eux de 4 à 6 fois ou plus» – c’est une affirmation facile à faire!

    En théorie, pour une application de type serveur exécutant longtemps, un langage compilé par JIT peut devenir beaucoup plus rapide qu’un équivalent compilé en natif. Étant donné que le langage compilé JIT est généralement compilé en premier lieu dans un langage intermédiaire de niveau relativement bas, vous pouvez faire de nombreuses optimisations de haut niveau dès la compilation. Le grand avantage réside dans le fait que JIT peut continuer à recomstackr des sections de code à la volée, car il reçoit de plus en plus de données sur l’utilisation de l’application. Il peut organiser les chemins de code les plus courants pour permettre à la prédiction de twig de réussir aussi souvent que possible. Il peut réorganiser des blocs de code distincts qui sont souvent appelés ensemble pour les garder tous les deux dans le cache. Il peut dépenser plus d’effort pour optimiser les boucles internes.

    Je doute que cela soit fait par .NET ou par l’un des JRE, mais cela faisait l’object de recherches quand j’étais à l’université, il n’est donc pas déraisonnable de penser que ce genre de choses pourrait bientôt arriver dans le monde réel .

    Pour les problèmes “parallèlement embarrassants”, lors de l’utilisation d’Intel TBB et d’OpenMP sur C ++, j’ai observé une augmentation d’environ 10x des performances par rapport aux problèmes similaires (mathématiques pures) rencontrés avec C # et TPL. SIMD est un domaine où C # ne peut pas concurrencer, mais j’ai également eu l’impression que TPL a une surcharge considérable.

    Cela dit, je n’utilise que le C ++ pour les tâches critiques en termes de performances, où je sais que je pourrai effectuer plusieurs tâches et obtenir des résultats rapidement. Pour tout le rest, C # (et occasionnellement F #) est très bien.

    C’est une question extrêmement vague sans réelle réponse définitive.

    Par exemple; Je préfère jouer aux jeux en 3D créés en C ++ qu’en C #, car les performances sont certainement bien meilleures. (Et je connais XNA, etc., mais ça ne se rapproche pas de la réalité).

    D’autre part, comme mentionné précédemment; vous devriez développer dans un langage qui vous permet de faire ce que vous voulez rapidement, puis d’optimiser si nécessaire.

    Applications nécessitant un access intensif à la mémoire, par ex. La manipulation des images est généralement mieux écrite dans un environnement non géré (C ++) que dans un environnement géré (C #). Les boucles internes optimisées avec l’arithmétique des pointeurs sont beaucoup plus faciles à contrôler en C ++. En C #, vous devrez peut-être recourir à un code non sécurisé pour obtenir des performances similaires.

    J’ai testé le vector en équivalent C ++ et C # – les tableaux List et Simple 2D.

    J’utilise les éditions Visual C # / C ++ 2010 Express. Les deux projets sont des applications de console simples, je les ai testées en mode standard (pas de parameters personnalisés) et en mode débogage. Les listes C # s’exécutent plus rapidement sur mon PC, l’initialisation du tableau est également plus rapide en C #, les opérations mathématiques sont plus lentes.

    J’utilise Intel Core2Duo [email protected], C # – .NET 4.0.

    Je sais que l’implémentation vectorielle est différente de la liste C #, mais je voulais juste tester des collections que j’utiliserais pour stocker mes objects (et pouvoir utiliser un accesseur d’index).

    Bien sûr, vous devez effacer la mémoire (disons pour chaque new utilisation), mais je voulais garder le code simple.

    Test vectoriel C ++ :

     static void TestVector() { clock_t start,finish; start=clock(); vector> myList=vector>(); int i=0; for( i=0; i<500; i++) { myList.push_back(vector()); for(int j=0;j<50000;j++) myList[i].push_back(j+i); } finish=clock(); cout<<(finish-start)< 

    Test de liste C #:

     private static void TestVector() { DateTime t1 = System.DateTime.Now; List> myList = new List>(); int i = 0; for (i = 0; i < 500; i++) { myList.Add(new List()); for (int j = 0; j < 50000; j++) myList[i].Add(j *i); } DateTime t2 = System.DateTime.Now; Console.WriteLine(t2 - t1); } 

    C ++ - array:

     static void TestArray() { cout << "Normal array test:" << endl; const int rows = 5000; const int columns = 9000; clock_t start, finish; start = clock(); double** arr = new double*[rows]; for (int i = 0; i < rows; i++) arr[i] = new double[columns]; finish = clock(); cout << (finish - start) << endl; start = clock(); for (int i = 0; i < rows; i++) for (int j = 0; j < columns; j++) arr[i][j] = i * j; finish = clock(); cout << (finish - start) << endl; } 

    C # - array:

     private static void TestArray() { const int rows = 5000; const int columns = 9000; DateTime t1 = System.DateTime.Now; double[][] arr = new double[rows][]; for (int i = 0; i < rows; i++) arr[i] = new double[columns]; DateTime t2 = System.DateTime.Now; Console.WriteLine(t2 - t1); t1 = System.DateTime.Now; for (int i = 0; i < rows; i++) for (int j = 0; j < columns; j++) arr[i][j] = i * j; t2 = System.DateTime.Now; Console.WriteLine(t2 - t1); } 

    Heure: (Release / Debug)

    C ++

    • 600/606 ms init de tableau,
    • 200/270 ms remplissage du tableau,
    • 1sec / 13sec vecteur init & fill.

    (Oui, 13 secondes, j'ai toujours des problèmes avec les listes / vecteurs en mode débogage.)

    C #:

    • 20/20 ms tableau init,
    • Remplissage du tableau 403/440 ms,
    • 710/742 ms list init & fill.

    En fait ça dépend. Si le code d’octet est traduit en code machine (et pas seulement JIT) (je veux dire si vous exécutez le programme) et si votre programme utilise de nombreuses allocations / désallocations, cela pourrait être plus rapide car l’algorithme GC a besoin à travers toute la mémoire une fois, mais les appels normaux malloc / realloc / free C / C ++ entraînent une surcharge pour chaque appel (sur-appel, surcharge de la structure de données, échec du cache;)).

    Donc, c’est théoriquement possible (également pour d’autres langages GC).

    Je ne vois pas l’extrême inconvénient de ne pas pouvoir utiliser la métaprogrammation avec C # pour la plupart des applications, car la plupart des programmeurs ne l’utilisent pas de toute façon.

    Un autre gros avantage est que le SQL, à l’instar de “l’extension” LINQ , permet au compilateur d’optimiser les appels aux bases de données (en d’autres termes, le compilateur peut comstackr l’intégralité de LINQ en un “blob”). pour votre utilisation optimisée, mais je spécule ici).

    Je suppose qu’il y a des applications écrites en C # qui tournent vite, et qu’il y a plus d’applications écrites en C ++ qui tournent vite (eh bien C ++ juste plus vieux … et prennent aussi UNIX …)
    – la question est en effet – quelle est cette chose, les utilisateurs et les développeurs se plaignent de …
    Eh bien, à mon humble avis, en cas de C #, nous avons une interface utilisateur très confortable, une très bonne hiérarchie de bibliothèques et un système d’interface complet de CLI. Dans le cas de C ++, nous avons des templates, ATL, COM, MFC et un shebang complet de code déjà écrit et exécutable comme OpenGL, DirectX, etc. Les développeurs se plaignent d’augmenter indéfiniment le nombre d’appels GC en C # en une seconde – bang! c’est bloqué).
    To write code in C# very simple and fast (not to forget that also increase chance of errors. In case of C++, developers complains of memory leaks, – means crushes, calls between DLLs, as well as of “DLL hell” – problem with support and replacement libraries by newer ones…
    I think more skill you’ll have in the programming language, the more quality (and speed) will characterize your software.

    I would put it this way: programmers who write faster code, are the ones who are the more informed of what makes current machines go fast, and incidentally they are also the ones who use an appropriate tool that allows for precise low-level and deterministic optimisation techniques. For these reasons, these people are the ones who use C/C++ rather than C#. I would go as far as stating this as a fact.

    If I’m not mistaken, C# templates are determined at runtime. This must be slower than comstack time templates of C++.

    And when you take in all the other comstack-time optimizations mentioned by so many others, as well as the lack of safety that does, indeed, mean more speed…

    I’d say C++ is the obvious choice in terms of raw speed and minimum memory consumption. But this also translates into more time developing the code and ensuring you aren’t leaking memory or causing any null pointer exceptions.

    Verdict:

    • C#: Faster development, slower run

    • C++: Slow development, faster run.

    > After all, the answers have to be somewhere, haven’t they? 🙂

    Umm, no.

    As several replies noted, the question is under-specified in ways that invite questions in response, not answers. To take just one way:

    • the question conflates language with language implementation – this C program is both 2,194 times slower and 1.17 times faster than this C# program – we would have to ask you: Which language implementations?

    And then which programs? Which machine? Quel OS? Which data set?

    It really depends on what you’re trying to accomplish in your code. I’ve heard that it’s just stuff of urban legend that there is any performance difference between VB.NET, C# and managed C++. However, I’ve found, at least in ssortingng comparisons, that managed C++ beats the pants off of C#, which in turn beats the pants off of VB.NET.

    I’ve by no means done any exhaustive comparisons in algorithmic complexity between the languages. I’m also just using the default settings in each of the languages. In VB.NET I’m using settings to require declaration of variables, etc. Here is the code I’m using for managed C++: (As you can see, this code is quite simple). I’m running the same in the other languages in Visual Studio 2013 with .NET 4.6.2.

     #include "stdafx.h" using namespace System; using namespace System::Diagnostics; bool EqualMe(Ssortingng^ first, Ssortingng^ second) { return first->Equals(second); } int main(array ^args) { Stopwatch^ sw = gcnew Stopwatch(); sw->Start(); for (int i = 0; i < 100000; i++) { EqualMe(L"one", L"two"); } sw->Stop(); Console::WriteLine(sw->ElapsedTicks); return 0; } 

    Inspired by this, I did a quick test with 60 percent of common instruction needed in most of the programs.

    Here’s the C# code:

     for (int i=0; i<1000; i++) { StreamReader str = new StreamReader("file.csv"); StreamWriter stw = new StreamWriter("examp.csv"); string strL = ""; while((strL = str.ReadLine()) != null) { ArrayList al = new ArrayList(); string[] strline = strL.Split(','); al.AddRange(strline); foreach(string str1 in strline) { stw.Write(str1 + ","); } stw.Write("\n"); } str.Close(); stw.Close(); } 

    Ssortingng array and arraylist are used purposely to include those instructions.

    Here's the c++ code:

     for (int i = 0; i<1000; i++) { std::fstream file("file.csv", ios::in); if (!file.is_open()) { std::cout << "File not found!\n"; return 1; } ofstream myfile; myfile.open ("example.txt"); std::string csvLine; while (std::getline(file, csvLine)) { std::istringstream csvStream(csvLine); std::vector csvColumn; std::string csvElement; while( std::getline(csvStream, csvElement, ',') ) { csvColumn.push_back(csvElement); } for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j) { myfile << *j << ", "; } csvColumn.clear(); csvElement.clear(); csvLine.clear(); myfile << "\n"; } myfile.close(); file.close(); } 

    The input file size I used was 40 KB.

    And here's the result -

    • C++ code ran in 9 seconds.
    • C# code: 4 seconds!!!

    Oh, but this was on Linux... With C# running on Mono ... And C++ with g++.

    OK, this is what I got on Windows – Visual Studio 2003 :

    • C# code ran in 9 seconds.
    • C++ code – horrible 370 seconds!!!