Performances C++ vs Java/C#

JIT vs Compilateur statique

Comme déjà dit dans les articles précédents, JIT peut compiler IL/bytecode en code natif lors de l'exécution. Le coût de cela a été mentionné, mais pas à sa conclusion:

JIT a un problème énorme est qu'il ne peut pas tout compiler: la compilation JIT prend du temps, donc le JIT ne compilera que certaines parties du code, alors qu'un compilateur statique produira un binaire natif complet: Pour certains types de programmes, le compilateur statique surpassera simplement facilement le JIT.

Bien sûr, C# (ou Java, ou VB) est généralement plus rapide à produire une solution viable et robuste que C++ (ne serait-ce que parce que C++ a une sémantique complexe, et la bibliothèque standard C++, bien qu'intéressante et puissante, est assez médiocre par rapport à toute la portée de la bibliothèque standard de. NET ou Java), donc généralement, la différence entre C++ et. NET ou Java JIT ne sera pas visible par la plupart des utilisateurs, et pour les binaires qui sont critiques, eh bien, vous pouvez toujours appeler le traitement C++ à partir de C # ou Java (même si ce type d'appels natifs peut être assez coûteux en soi)...

Métaprogrammation C++

Notez que généralement, vous comparez le code d'exécution C++ avec son équivalent en C# ou Java. Mais C++ a une fonctionnalité qui peut surpasser Java / C # hors de la boîte, c'est le métaprogrammation de modèle: Le traitement du code sera effectué au moment de la compilation (augmentant ainsi considérablement le temps de compilation), entraînant une durée d'exécution nulle (ou presque nulle).

J'ai encore donc voir un vrai effet de la vie sur cela (je n'ai joué qu'avec des concepts, mais à ce moment-là, la différence était de secondes d'exécution pour JIT, et zéro pour C++), mais cela vaut la peine d'être mentionné, à côté du fait que le métaprogrammage du modèle n'est pas trivial...

Edit 2011-06-10: En C++, jouer avec les types se fait au moment de la compilation, ce qui signifie produire du code générique qui appelle du code non générique (par exemple un analyseur générique de string à type T, appelant l'API de bibliothèque standard pour les types T it est très facile et très efficace, alors que l'équivalent en Java ou C# est au mieux douloureux à écrire, et sera toujours plus lent et résolu à l'exécution même lorsque les types sont connus au moment de la compilation, ce qui signifie que votre seul espoir est que le JIT intègre le tout.

...

Edit 2011-09-20:, L'équipe derrière Blitz++ (page d'Accueil, Wikipédia) est allé de cette façon, et apparemment, leur objectif est d'atteindre les performances de FORTRAN sur les calculs scientifiques en passant autant que possible de l'exécution de l'exécution au temps de compilation, via la métaprogrammation du modèle C++. Donc, le" J'ai encore donc voir un effet de la vie réelle sur ce " partie que j'ai écrit ci-dessus apparemment existe dans la vie réelle.

Utilisation native de la mémoire C++

C++ a une utilisation de la mémoire différente de Java / C#, et a donc avantages/défauts.

Quelle que soit l'optimisation JIT, rien ne va plus vite que l'accès direct au pointeur à la mémoire (ignorons un instant les caches du processeur, etc.). Donc, si vous avez des données contiguës en mémoire, accédez-y via des pointeurs C++ (c'est-à-dire des pointeurs C... Donnons à César son dû) va fois plus vite qu'en Java / C#. Et C++ a RAII, ce qui rend beaucoup de traitement beaucoup plus facile qu'en C# ou même en Java. C++ n'a pas besoin de using pour étendre l'existence de ses objets. Et C++ n'a pas de clause finally. Ce n'est pas une erreur.

:-)

Et malgré les structures primitives C#, les objets C++ "sur la pile" ne coûteront rien à l'allocation et à la destruction, et n'auront pas besoin de GC pour travailler dans un thread indépendant pour faire le nettoyage.

En ce qui concerne la fragmentation de la mémoire, les allocateurs de mémoire de 2008 ne sont pas les anciens allocateurs de mémoire de 1980 qui sont généralement comparés à un GC: l'allocation C++ ne peut pas être déplacée en mémoire, c'est vrai, mais alors, comme sur un Linux système de fichiers: Qui a besoin de défragmenter le disque dur lorsque la fragmentation ne se produit pas? L'utilisation du bon allocateur pour la bonne tâche devrait faire partie de la boîte à outils du développeur C++. Maintenant, écrire des allocateurs n'est pas facile, et puis, la plupart d'entre nous ont de meilleures choses à faire, et pour la plupart d'utilisation, RAII ou GC est plus assez bon.

Edit 2011-10-04: Pour des exemples sur les allocateurs efficaces: Sur les plates-formes Windows, depuis Vista, le Segment de mémoire à faible Fragmentation est activé par défaut. Pour les versions précédentes, le LFH peut être activé en appelant la fonction WinAPI HeapSetInformation). Sur d'autres systèmes d'exploitation, des allocateurs alternatifs sont fournis (voir https://secure.wikimedia.org/wikipedia/en/wiki/Malloc pour une liste)

Maintenant, le modèle de mémoire devient quelque peu plus compliqué avec l'essor de la technologie multicœur et multithreading. Dans ce domaine, je suppose que. NET a l'avantage, et Java, m'a-t-on dit, a tenu le supérieure du sol. Il est facile pour certains hackers "sur le métal nu" de louer son code "près de la machine". Mais maintenant, il est beaucoup plus difficile de produire un meilleur assemblage à la main que de laisser le compilateur à son travail. Pour C++, le compilateur est devenu généralement meilleur que le hacker depuis une décennie. Pour C# et Java, c'est encore plus facile.

Néanmoins, la nouvelle norme C++0x imposera un modèle de mémoire simple aux compilateurs C++, ce qui normalisera (et simplifiera ainsi) efficacement multiprocessing / parallel / threading code en C++, et rendre les optimisations plus faciles et plus sûres pour les compilateurs. Mais ensuite, nous verrons dans quelques années si ses promesses sont tenues.

C++/CLI vs C#/VB.NET

Remarque: Dans cette section, je parle de C++/CLI, c'est-à-dire du C++ hébergé par.NET, pas du C++natif.

La semaine dernière, j'ai eu une formation sur l'optimisation.NET, et j'ai découvert que le compilateur statique est de toute façon très important. Aussi important que JIT.

Le même code compilé en C++ / CLI (ou son ancêtre, Managed C++) pourrait être plusieurs fois plus rapide que le même code produit en C# (ou VB.NET, dont le compilateur produit le même IL que C#).

Parce que le compilateur statique C++ était beaucoup mieux pour produire du code déjà optimisé que C#.

Par exemple, function inlining dans.NET est limité aux fonctions dont le bytecode est inférieur ou égal à 32 octets de longueur. Ainsi, un code en C # produira un accesseur de 40 octets, qui ne sera jamais intégré par le JIT. Le même code en C++ / CLI produira un accesseur de 20 octets, qui sera intégré par le JIT.

Un autre exemple est les variables temporaires, qui sont simplement compilées par le compilateur C++ tout en étant mentionnées dans l'IL produit par le compilateur C#. L'optimisation de compilation statique C++ entraînera moins de code, autorisant ainsi une optimisation JIT plus agressive, encore une fois.

La raison de cela a été spéculée pour être le fait compilateur C++ / CLI a profité des vastes techniques d'optimisation du compilateur natif C++.

Conclusion

J'adore le C++.

Mais pour autant que je le vois, C# ou Java sont dans l'ensemble un meilleur pari. Non pas parce qu'ils sont plus rapides que le C++, mais parce que lorsque vous additionnez leurs qualités, ils finissent par être plus productifs, nécessitant moins de formation et disposant de bibliothèques standard plus complètes que le C++. Et comme pour la plupart des programmes, leurs différences de vitesse (d'une manière ou d'une autre) seront négligeable...

Modifier (2011-06-06)

Mon expérience sur C#/. NET

J'ai maintenant 5 mois de codage C# professionnel presque exclusif (ce qui ajoute à mon CV déjà plein de C++ et Java, et une touche de C++/CLI).

J'ai joué avec WinForms (Ahem...) et WCF (cool!), et WPF (Cool!!!! À la fois via XAML et C#brut. WPF est si facile que je crois que Swing ne peut tout simplement pas se comparer à lui), et C# 4.0.

La conclusion est que même s'il est plus facile/plus rapide de produire un code cela fonctionne en C# / Java qu'en C++, il est beaucoup plus difficile de produire un code fort, sûr et robuste en C# (et encore plus difficile en Java) qu'en C++. Les raisons abondent, mais cela peut être résumé par:

1. Les génériques ne sont pas aussi puissants que les modèles (essayez d'écrire une méthode d'analyse générique efficace (de string à T), ou un équivalent efficace de boost::lexical_cast en C# pour comprendre le problème )
2. RAII reste inégalé (GC peut encore fuite (oui, j'ai dû gérer ce problème) et ne gérera que la mémoire. Même C # ' s using n'est pas aussi facile et puissant car écrire une implémentation Dispose correcte est difficile )
3. C #readonly et Java final ne sont nulle part aussi utiles que C++const ( Il n'y a aucun moyen d'exposer des données complexes en lecture seule (un arbre de nœuds, par exemple) en C# sans un travail énorme, alors que c'est une fonctionnalité intégrée de C++. Les données immuables sont une solution intéressante, mais tout ne peut pas être rendu immuable, donc ce n'est même pas suffisant, de loin).

Donc, C# reste un langage agréable tant que vous voulez quelque chose qui fonctionne, mais un langage frustrant au moment où vous voulez quelque chose quifonctionne toujours et en toute sécurité .

Java est encore plus frustrant, car il a les mêmes problèmes que C#, et plus encore: Manquant de l'équivalent du mot-clé using de C#, un collègue très compétent a passé trop de temps à s'assurer que ses ressources étaient correctement libérées, alors que l'équivalent en C++ aurait été facile (en utilisant des destructeurs et des pointeurs intelligents).

Donc je suppose que le gain de productivité de C#/Java est visible pour la plupart du code... jusqu'au jour où vous avez besoin que le code soit aussi parfait que possible. De ce jour, vous allez connaître la douleur. (vous ne croirez pas ce qui est demandé à partir de nos applications serveur et interface graphique...).

À propos de Java et C++côté serveur

J'ai gardé le contact avec les équipes serveur (j'ai travaillé 2 ans parmi elles, avant de revenir à l'équipe GUI), au de l'autre côté du bâtiment, et j'ai appris quelque chose d'intéressant.

Les dernières années, la tendance était de faire en sorte que les applications serveur Java soient destinées à remplacer les anciennes applications serveur C++, car Java a beaucoup de frameworks/outils, et est facile à maintenir, à déployer, etc. etc..

...Jusqu'à ce que le problème de la faible latence ait soulevé sa tête laide les derniers mois. Ensuite, les applications Java Server, peu importe l'optimisation tentée par notre équipe Java qualifiée, ont simplement et proprement perdu la course contre l'ancien, pas serveur C++ vraiment optimisé.

Actuellement, la décision est de garder les serveurs Java pour un usage courant où les performances, bien que toujours importantes, ne sont pas concernées par la cible à faible latence, et d'optimiser agressivement les applications serveur C++ déjà plus rapides pour les besoins à faible latence et à très faible latence.

Conclusion

Rien n'est aussi simple que prévu.

Java, et encore plus C#, sont des langages sympas, avec de nombreuses bibliothèques et frameworks standard, où vous pouvez code rapide, et ont des résultats très bientôt.

Mais lorsque vous avez besoin de puissance brute, d'optimisations puissantes et systématiques, d'un support de compilateur solide, de fonctionnalités de langage puissantes et d'une sécurité absolue, Java et C# rendent difficile de gagner les derniers pourcentages de qualité manquants mais critiques dont vous avez besoin pour rester au-dessus de la concurrence.

C'est comme si vous aviez besoin de moins de temps et de développeurs moins expérimentés en C#/Java qu'en C++ pour produire du code de qualité moyenne, mais d'un autre côté, le moment dont vous aviez besoin excellent pour perfectionner le code de qualité, il était soudainement plus facile et plus rapide d'obtenir les résultats en C++.

Bien sûr, c'est ma propre perception, peut-être limitée à nos besoins spécifiques.

Mais encore, c'est ce qui se passe aujourd'hui, à la fois dans les équipes GUI et les équipes côté serveur.

Bien sûr, je mettrai à jour ce post si quelque chose de nouveau se produit.

Modifier (2011-06-22)

" Nous constatons qu'en ce qui concerne les performances, C++ l'emporte par une grande marge. Cependant, il également requis le plus étendu efforts de réglage, dont beaucoup ont été faits à un niveau de sophistication ce ne serait pas disponible pour le programmeur moyen.

[...] La version Java était probablement la plus simple à implémenter, mais la plus difficile à analyser pour les performances. Plus précisément les effets autour de la collecte des ordures étaient compliqués et très difficiles à régler."

Sources:

• https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
• http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests

Modifier (2011-09-20)

"Le mot d'ordre chez Facebook est que" le code C++ raisonnablement écrit s'exécute rapidement, ", ce qui souligne l'énorme effort consacré à l'optimisation du code PHP et Java. Paradoxalement, le code C++ est plus difficile à écrire que dans d'autres langues, mais code efficace est beaucoup plus facile [pour écrire en C++ que dans d'autres langues]."

– Herb Sutter à //build/, citant Andrei Alexandrescu

Sources:

• http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T
• http://video.ch9.ms/build/2011/slides/TOOL-835T_Sutter.pptx

Chaque fois que je parle de performances gérées par rapport aux performances non gérées, j'aime pointer vers la série Rico (et Raymond) qui a comparé les versions C++ et C# d'un dictionnaire chinois/anglais. Cetterecherche Google vous permettra de lire par vous-même, mais j'aime le résumé de Rico.

Alors ai-je honte de ma défaite écrasante? Guère. Le code géré a un très bon résultat pour presque aucun effort. De vaincre la gestion Raymond a dû:

• Écrire ses propres trucs d'E/S de fichier
• Écrire sa propre classe de chaîne
• Écrire son propre allocateur
• Écrire sa propre cartographie internationale

Bien sûr, il a utilisé inférieur disponible nivelez les bibliothèques pour le faire, mais c'est encore beaucoup de travail. Pouvez-vous appeler ce qui est à gauche STL programme? Je n'ai pas pense que oui, je pense qu'il a gardé le std:: vector classe qui a finalement été jamais un problème et il a gardé la trouvaille fonction. Pratiquement tout le reste est allé.

Donc, oui, vous pouvez certainement battre le CLR. Raymond peut faire passer son programme encore plus vite je pense.

Fait Intéressant, le temps d'analyser la fichier tel que rapporté par les deux programmes les minuteries internes sont à peu près les mêmes -- 30ms pour chacun. La différence est dans généraux.

Pour moi, l'essentiel est qu'il a fallu 6 révisions pour que la version non gérée batte la version gérée qui était un simple port du code non géré d'origine. Si vous avez besoin de chaque dernier bit de performance (et ont le temps et expertise pour l'obtenir), vous devrez aller non géré, mais pour moi, je vais prendre l'avantage de l'ordre de grandeur que j'ai sur les premières versions sur les 33% que je gagne si j'essaie 6 fois.

La compilation pour des optimisations CPU spécifiques est généralement surfaite. Il suffit de prendre un programme en C++ et de compiler avec optimisation pour pentium PRO et de l'exécuter sur un pentium 4. Recompiler ensuite avec optimize pour pentium 4. J'ai passé de longs après-midi à le faire avec plusieurs programmes. Résultats généraux?? Généralement moins de 2-3% d'augmentation des performances. Donc, les avantages théoriques JIT sont presque aucun. La plupart des différences de performances ne peuvent être observées que lors de l'utilisation de fonctionnalités de traitement de données scalaires, quelque chose qui finira par avoir besoin d'un réglage fin manuel pour atteindre des performances maximales de toute façon. Les optimisations de ce type sont lentes et coûteuses à effectuer, ce qui les rend parfois inadaptées à JIT de toute façon.

Sur le monde réel et l'application réelle, C++ est toujours généralement plus rapide que java, principalement en raison de l'empreinte mémoire plus légère qui se traduit par de meilleures performances de cache.

Mais pour utiliser toutes les capacités C++, le développeur doit travailler dur. Vous pouvez obtenir des résultats supérieurs, mais vous devez utiliser votre cerveau pour que. C++ est un langage qui a décidé de vous présenter plus d'outils, en facturant le prix que vous devez les apprendre pour pouvoir bien utiliser le langage.

JIT (Just In Time Compiling) peut être incroyablement rapide car il optimise pour la plate-forme cible.

Cela signifie qu'il peut tirer parti de toute astuce du compilateur que votre CPU peut prendre en charge, quel que soit le PROCESSEUR sur lequel le développeur a écrit le code.

Le concept de base du JIT. NET fonctionne comme ceci (fortement simplifié):

L'Appel d'une méthode pour la première fois:

• Votre code de programme appelle une méthode Foo ()
• Le CLR regarde le type qui implémente Foo() et obtient les métadonnées qui lui sont associées
• À partir des métadonnées, le CLR sait dans quelle adresse mémoire l'IL (code octet intermédiaire) est stocké.
• Le CLR alloue un bloc de mémoire et appelle le JIT.
• Le JIT compile l'IL en code natif, le place dans la mémoire allouée, puis modifie le pointeur de fonction dans les métadonnées de type de Foo () pour pointer vers ce code natif.
• Le code natif est exécuté.

Appel d'une méthode pour la deuxième fois:

• Votre code de programme appelle une méthode Foo ()
• Le CLR examine le type qui implémente Foo() et trouve le pointeur de fonction dans les métadonnées.
• Le code natif à cet emplacement de mémoire est exécuté.

Comme vous pouvez le voir, la 2ème fois, c'est pratiquement le même processus que C++, sauf avec l'avantage des optimisations en temps réel.

Cela dit, il y a encore d'autres problèmes de surcharge qui ralentissent un langage géré, mais le JIT aide beaucoup.

J'aime la réponse de Orion Adrian, mais il y a un autre aspect à cela.

La même question a été posée il y a des décennies à propos du langage assembleur par rapport aux langages "humains" comme le FORTRAN. Et une partie de la réponse est similaire.

Oui, un programme C++ est capable d'être plus rapide que C# sur n'importe quelle donnée (non triviale?) algorithme, mais le programme en C# sera souvent aussi rapide ou plus rapide qu'une implémentation "naïve" en C++, et une version optimisée en C++ prendra plus de temps à se développer, et pourrait toujours battre la version C # par une très petite marge. Alors, est-il vraiment la peine?

Vous devrez répondre à cette question une par une.

Cela dit, je suis un fan de longue date de C++, et je pense que c'est un langage incroyablement expressif et puissant sometimes parfois sous-estimé. Mais dans de nombreux problèmes" réels "(pour moi personnellement, cela signifie" le genre que je suis payé pour résoudre"), C# fera le travail plus tôt et plus sûr.

La plus grosse pénalité que vous payez? De nombreux programmes. NET et Java sont des porcs de la mémoire. J'ai vu les applications.NET et Java prendre des "centaines" de mégaoctets de mémoire, lorsque les programmes C++ de complexité similaire grattent à peine les "dizaines" de MBs.

Je ne suis pas sûr de la fréquence à laquelle vous constaterez que le code Java fonctionnera plus rapidement que C++, même avec Hotspot, mais je vais essayer d'expliquer comment cela pourrait arriver.

Pensez au code Java compilé comme langage machine interprété pour la JVM. Lorsque le processeur Hotspot remarque que certaines parties du code compilé vont être utilisées plusieurs fois, il effectue une optimisation sur le code machine. Étant donné que l'assemblage de réglage manuel est presque toujours plus rapide que le code compilé C++, il est correct de comprendre ce code machine réglé par programme ne va pas être trop mauvais.

Donc, pour le code très répétitif, je pouvais voir où il serait possible pour Hotspot JVM d'exécuter le Java plus rapidement que C++... jusqu'à ce que la collecte des ordures entre en jeu. :)

Généralement, l'algorithmede votre programme sera beaucoup plus important pour la vitesse de votre application que le langage . Vous pouvez implémenter un algorithme médiocre dans n'importe quel langage, y compris C++. Dans cet esprit, vous pourrez généralement écrire du code plus rapidement dans un langage qui vous aidera à implémenter un algorithme plus efficace.

Les langages de haut niveau réussissent très bien à cela en fournissant un accès plus facile à de nombreuses structures de données prédéfinies efficaces et en encourageant pratiques qui vous aideront à éviter le code inefficace. Bien sûr, ils peuvent parfois aussi faciliter l'écriture d'un tas de code vraiment lent, donc vous devez toujours connaître votre plate-forme.

De plus, C++ rattrape les fonctionnalités "nouvelles" (notez les guillemets) comme les conteneurs STL, les pointeurs automatiques, etc see voir la bibliothèque boost, par exemple. Et vous pourriez parfois trouver que le moyen le plus rapide d'accomplir une tâche nécessite une technique comme l'arithmétique de pointeur qui est interdite dans un langage de niveau supérieur-bien qu'ils vous permettent typcially d'appeler à une bibliothèque écrite dans un langage qui peut l'implémenter comme vous le souhaitez.

L'essentiel est de connaître la langue que vous utilisez, son API associée, ce qu'elle peut faire et ses limites.

Je ne sais pas either...my Les programmes Java sont toujours lents. :- ) Je n'ai jamais vraiment remarqué que les programmes C# étaient particulièrement lents.

Voici un autre benchmark intersting, que vous pouvez essayer vous-même sur votre propre ordinateur.

Il compare ASM, VC++, C#, Silverlight, Applet Java, Javascript, Flash (AS3)

Démonstration de vitesse du plugin Roozz

Veuillez noter que la vitesse de javascript varie beaucoup en fonction du navigateur qui l'exécute. Il en va de même pour Flash et Silverlight car ces plugins s'exécutent dans le même processus que le navigateur d'hébergement. Mais le plugin Roozz fonctionne standard .EXE, qui s'exécutent dans leur propre processus, donc la vitesse n'est pas influencée par le navigateur d'hébergement.

, Vous devez définir le "faire mieux que..". Eh bien, je sais, vous avez posé des questions sur la vitesse, mais ce n'est pas tout ce qui compte.

• Les machines virtuelles effectuent-elles plus de temps d'exécution? Oui!
• Mangent - ils plus de mémoire de travail? Oui!
• Ont-ils des coûts de démarrage plus élevés (initialisation d'exécution et compilateur JIT) ? Oui!
• Ont-ils besoin d'une énorme bibliothèque installée? Oui!

Et ainsi de suite, c'est biaisé, oui ;)

Avec C# et Java, vous payez un prix pour ce que vous obtenez (codage plus rapide, gestion automatique de la mémoire, grande bibliothèque et ainsi de suite). Mais vous n'avez pas beaucoup de place pour marchander les détails: prenez le paquet complet ou rien.

Même si ces langages peuvent optimiser certains codes pour les exécuter plus rapidement que le code compilé, toute l'approche est (À mon humble avis) inefficace. Imaginez conduire tous les jours 5 miles à votre lieu de travail, avec un camion! C'est confortable, ça fait du bien, vous êtes en sécurité (zone de froissement extrême) et après avoir marché sur le gaz pendant un certain temps, il va même être aussi rapide qu'une voiture standard! Pourquoi n'avons-nous pas tous un camion pour aller au travail? ;)

En C++, vous obtenez ce que vous payez, pas plus, pas moins.

Citant Bjarne Stroustrup: "C++ est mon langage garbage collecté préféré car il génère si peu de déchets" texte du lien

Le code exécutable produit à partir d'un compilateur Java ou C# n'est pas interprété-il est compilé en code natif "just in time" (JIT). Ainsi, le premier code temporel dans un programme Java/C# est rencontré pendant l'exécution, il y a une surcharge car le "compilateur d'exécution" (alias compilateur JIT) transforme le code octet (Java) ou le code IL (C#) en instructions machine natives. Cependant, la prochaine fois que ce code est rencontré alors que l'application est toujours en cours d'exécution, le code natif est exécuté immédiatement. Ce explique comment certains programmes Java/C# semblent être lents au départ, mais fonctionnent mieux plus ils s'exécutent longtemps. Un bon exemple est un ASP.Net site web. La toute première fois que le site Web est accessible, il peut être un peu plus lent car le code C# est compilé en code natif par le compilateur JIT. Les accès ultérieurs entraînent un site Web beaucoup plus rapide-mise en cache côté serveur et côté client.

Quelques bonnes réponses ici sur la question spécifique que vous avez posée. J'aimerais prendre du recul et regarder la situation dans son ensemble.

Gardez à l'esprit que la perception de votre utilisateur de la vitesse du logiciel que vous écrivez est affectée par de nombreux autres facteurs que la façon dont le codegen optimise. Voici quelques exemples:

• La gestion manuelle de la mémoire est difficile à faire correctement (pas de fuites), et encore plus difficile à faire efficacement (mémoire libre peu de temps après que vous en avez terminé). À l'aide d'un GC est, dans général, plus susceptible de produire un programme qui gère bien la mémoire. Êtes-vous prêt à travailler très dur et à retarder la livraison de votre logiciel pour tenter de surpasser le GC?

• Mon C# est plus facile à lire et à comprendre que mon C++. J'ai aussi plus de façons de me convaincre que mon code C# fonctionne correctement. Cela signifie que je peux optimiser mes algorithmes avec moins de risque d'introduire des bogues (et les utilisateurs n'aiment pas les logiciels qui plantent, même s'ils le font rapidement!)

• Je peux créez mon logiciel plus rapidement en C# qu'en C++. Cela libère du temps pour travailler sur les performances, tout en livrant mon logiciel à temps.

• Il est plus facile d'écrire une bonne interface utilisateur en C# qu'en C++, donc je suis plus susceptible de pouvoir pousser le travail en arrière-plan pendant que l'interface utilisateur reste réactive, ou de fournir une interface utilisateur progress ou hearbeat lorsque le programme doit bloquer pendant un certain temps. Cela ne rend rien plus rapide, mais cela rend les utilisateurs plus heureux d'attendre.

Tout ce que j'ai dit à propos de C# est probablement vrai pour Java, je n'ai pas l'expérience pour le dire.

Si vous êtes un programmeur Java/C# apprenant le C++, vous serez tenté de continuer à penser en termes de Java/C# et de traduire textuellement en syntaxe C++. Dans ce cas, vous n'obtenez que les avantages mentionnés précédemment du code natif par rapport à interpreted/JIT. Pour obtenir le plus grand gain de performance en C++ par rapport à Java/C#, vous devez apprendre à penser en C++ et à concevoir du code spécifiquement pour exploiter les forces de C++.

Pour paraphraser Edsger Dijkstra: [votre langue maternelle] mutile l'esprit au-delà récupération.
Pour paraphraser Jeff Atwood: vous pouvez écrire votre première langue] dans une nouvelle langue.

L'une des optimisations JIT les plus significatives est l'inlining de méthode. Java peut même intégrer des méthodes virtuelles s'il peut garantir l'exactitude de l'exécution. Ce type d'optimisation ne peut généralement pas être effectué par des compilateurs statiques standard car il nécessite une analyse de l'ensemble du programme, ce qui est difficile à cause d'une compilation séparée (en revanche, JIT a tout le programme à sa disposition). L'inlining de méthode améliore d'autres optimisations, donnant des blocs de code plus grands à optimiser.

Mémoire standard l'allocation en Java / C # est également plus rapide et la désallocation (GC) n'est pas beaucoup plus lente, mais seulement moins déterministe.

Il est peu probable que les langages de machine virtuelle surpassent les langages compilés, mais ils peuvent se rapprocher suffisamment pour que cela n'ait pas d'importance, pour (au moins) les raisons suivantes (je parle pour Java ici car je n'ai jamais fait de C#).

1/ L'environnement d'exécution Java est généralement capable de détecter des morceaux de code qui sont exécutés fréquemment et d'effectuer une compilation juste à temps (JIT) de ces sections afin qu'à l'avenir, elles s'exécutent à pleine vitesse compilée.

2 / De vastes parties du Java les bibliothèques sont compilées de sorte que, lorsque vous appelez une fonction de bibliothèque, vous exécutez du code compilé, non interprété. Vous pouvez voir le code (en C) en téléchargeant l'OpenJDK.

3/ À moins que vous ne fassiez des calculs massifs, la plupart du temps, votre programme est en cours d'exécution, il attend l'entrée d'un humain très lent (relativement parlant).

4/ Étant donné qu'une grande partie de la validation du bytecode Java est effectuée au moment du chargement de la classe, la surcharge normale des vérifications d'exécution est considérablement réduire.

5/ Dans le pire des cas, le code exigeant des performances peut être extrait vers un module compilé et appelé à partir de Java (voir JNI) afin qu'il s'exécute à pleine vitesse.

En résumé, le bytecode Java ne surpassera jamais le langage machine natif, mais il existe des moyens d'atténuer cela. Le gros avantage de Java (comme je le vois) est la bibliothèque standard ÉNORME et la nature multiplateforme.

Orion Adrian , permettez-moi d'inverser votre message pour voir à quel point vos remarques sont infondées, car on peut aussi en dire beaucoup sur C++. Et dire que le compilateur Java/C # optimise les fonctions vides vous donne vraiment l'impression d'être pas mon expert en optimisation, car a) pourquoi un vrai programme devrait-il contenir des fonctions vides, sauf pour un code hérité vraiment mauvais, b) ce n'est vraiment pas une optimisation noire et saignante.

En dehors de cette phrase, vous avez râlé de manière flagrante à propos des pointeurs, mais les objets en Java et C# ne fonctionnent-ils pas essentiellement comme des pointeurs C++? Puissent-ils ne pas se chevauchent? Puissent-ils ne pas être null? C (et la plupart des implémentations C++) a le mot clé restrict, les deux ont des types de valeur, C++ a une référence à la valeur avec une garantie non nulle. Qu'offrent Java et C#?

>>>>>>>>>>

Généralement, C et C++ peuvent être tout aussi rapides ou plus rapides car le compilateur AOT - un compilateur qui compile votre code avant le déploiement, une fois pour toutes, sur votre mémoire élevée core build server-peut faire des optimisations qu'un programme compilé C# ne peut pas car il a une tonne de temps pour le faire. Le compilateur peut déterminer si la machine est Intel ou AMD; Pentium 4, Core Solo ou Core Duo; ou si prend en charge SSE4, etc., et si votre compilateur ne prend pas en charge la répartition d'exécution, vous pouvez résoudre cela vous-même en déployant une poignée de binaires spécialisés.

Un programme C# est généralement compilé lors de son exécution afin qu'il fonctionne décemment bien sur toutes les machines, mais ne l'est pas optimisé autant que possible pour une seule configuration (c'est-à-dire processeur, jeu d'instructions, autre matériel), et il doit passer un certain temps en premier. Des fonctionnalités telles que la fission de boucle, l'inversion de boucle, la vectorisation automatique, l'optimisation de l'ensemble du programme, l'expansion du modèle, l'introduction en bourse, etc., sont très difficiles à résoudre et complètement d'une manière qui n'ennuie pas l'utilisateur final.

De plus, certaines fonctionnalités de langage permettent au compilateur en C++ ou C de faire des hypothèses sur votre code qui lui permet d'optimiser certaines parties qui ne sont tout simplement pas sûres pour le compilateur Java/C#. Lorsque vous n'avez pas accès à l'id de type complet des génériques ou à un flux de programme garanti, il y a beaucoup d'optimisations qui ne sont tout simplement pas sûres.

C++ et C font également plusieurs allocations de pile à la fois avec une seule incrémentation de registre, ce qui est sûrement plus efficace que les allocations Javas et C# quant à la couche d'abstraction entre le garbage collector et votre code.

Maintenant Je ne peux pas parler pour Java sur ce point suivant, mais je sais que les compilateurs C++, par exemple, supprimeront les méthodes et les appels de méthodes lorsqu'ils sauront que le corps de la méthode est vide, ils élimineront les sous-expressions courantes, ils pourront essayer de nouveau de trouver une utilisation optimale du registre, ils n'appliqueront pas la vérification des limites, ils autovectoriseront les boucles et les boucles internes et inverseront l'intérieur vers l'extérieur, ils déplaceront les conditionnels hors des boucles, ils diviseront et décomplexeront les boucles. Il développera std:: vector en zéro natif tableaux généraux comme vous le feriez de la manière C. Il fera des optimisations inter-procédurales. Il construira des valeurs de retour directement sur le site de l'appelant. Il se pliera et propagera les expressions. Il réorganisera les données de manière conviviale. Il fera sauter le filetage. Il vous permet d'écrire des traceurs de rayons à la compilation sans surcharge d'exécution. Il fera des optimisations basées sur des graphiques très coûteuses. Il fera la réduction de la force, si elle remplace certains codes avec syntaxiquement totalement inégale mais code sémantiquement équivalent (l'ancien "xor foo, foo" est juste l'optimisation la plus simple, bien que obsolète de ce type). Si vous le demandez gentiment, vous pouvez omettre les normes IEEE à virgule flottante et activer encore plus d'optimisations comme la réorganisation des opérandes à virgule flottante. Après avoir massé et massacré votre code, il peut répéter tout le processus, car souvent, certaines optimisations jettent les bases d'optimisations encore plus certaines. Il peut également simplement réessayer avec des paramètres mélangés et voir comment le autres scores variantes dans son classement interne. Et il utilisera ce genre de logique tout au long de votre code.

Donc, comme vous pouvez le voir, il y a beaucoup de raisons pour lesquelles certaines implémentations C++ ou C seront plus rapides.

Maintenant, tout cela dit, de nombreuses optimisations peuvent être faites en C++ qui vont souffler tout ce que vous pourriez faire avec C#, en particulier dans le nombre crunching, realtime et domaine proche du métal, mais pas exclusivement là. Vous n'avez même pas besoin de toucher un seul pointeur pour venir longtemps façon.

Donc, selon ce que vous écrivez, j'irais avec l'un ou l'autre. Mais si vous écrivez quelque chose qui ne dépend pas du matériel (pilote, jeu vidéo, etc.), je ne m'inquiéterais pas des performances de C# (encore une fois, je ne peux pas parler de Java). Il va faire tout aussi bien.

En général, certains arguments généralisés peuvent sembler cool dans des messages spécifiques, mais ne semblent généralement pas certainement crédibles.

Quoi qu'il en soit, faire la paix: AOT est super, tel quel JIT. La seule réponse correcte peut être: Cela dépend. Et les vrais gens intelligents savent que vous pouvez utiliser le meilleur des deux mondes, de toute façon.

Cela ne se produirait que si l'interpréteur Java produit du code machine qui est en fait mieux optimisé que le code machine que votre compilateur génère pour le code C++ que vous écrivez, au point où le code C++ est plus lent que Java et le coût d'interprétation.

Cependant, les chances que cela se produise réellement sont assez faibles - à moins que Java ait peut-être une bibliothèque très bien écrite et que vous ayez votre propre bibliothèque C++ mal écrite.

En fait, C# ne fonctionne pas vraiment dans une machine virtuelle comme Java. IL est compilé en langage assembleur, qui est entièrement du code natif et s'exécute à la même vitesse que le code natif. Vous pouvez pré-JIT une application. NET qui supprime entièrement le coût JIT, puis vous exécutez du code entièrement natif.

Le ralentissement avec. NET ne viendra pas parce que le code. NET est plus lent, mais parce qu'il fait beaucoup plus dans les coulisses pour faire des choses comme la collecte des ordures, vérifier les références, stocker cadres de pile complets,etc. Cela peut être très puissant et utile lors de la création d'applications, mais a également un coût. Notez que vous pouvez également faire toutes ces choses dans un programme C++ (une grande partie de la fonctionnalité.NET de base est en fait du code. NET que vous pouvez afficher dans ROTOR). Cependant, si vous avez écrit à la main la même fonctionnalité, vous vous retrouveriez probablement avec un programme beaucoup plus lent car le runtime.NET a été optimisé et finement réglé.

Cela dit, l'une des forces du code géré est-ce qu'il peut être entièrement vérifiable, à savoir. vous pouvez vérifier que le code n'accèdera jamais à la mémoire d'un autre processus ou ne désagérera jamais les choses avant de l'exécuter. Microsoft a un prototype de recherche d'un système d'exploitation entièrement géré qui a étonnamment montré qu'un environnement géré à 100% peut effectivement fonctionner beaucoup plus rapidement que n'importe quel système d'exploitation moderne en profitant de cette vérification pour désactiver les fonctionnalités de sécurité qui ne sont plus nécessaires par les programmes gérés (nous parlons comme 10x dans certains cas). SE radio a un grand épisode parlant de ce projet.

Dans certains cas, le code géré peut en fait être plus rapide que le code natif. Par exemple, les algorithmes de garbage collection" mark-and-sweep " permettent à des environnements comme le JRE ou le CLR de libérer un grand nombre d'objets de courte durée (généralement) en un seul passage, où la plupart des objets de tas C/C++ sont libérés un à la fois.

À Partir de wikipedia:

À de nombreuses fins pratiques, les algorithmes d'allocation/désallocation intensifs implémentés dans les langages collectés par les ordures peuvent en fait être plus rapide que leurs équivalents en utilisant l'allocation manuelle de tas. Une raison majeure à cela est que le garbage collector permet au système d'exécution d'amortir les opérations d'allocation et de désallocation d'une manière potentiellement avantageuse.

Cela dit, j'ai écrit beaucoup de C# et beaucoup de C++, et j'ai beaucoup de points de référence. D'après mon expérience, C++ est beaucoup plus rapide que C#, de deux manières: (1) si vous prenez du code que vous avez écrit en C#, portez-le en C++ le code natif tend à être plus rapide. Comment beaucoup plus rapide? Eh bien, cela varie beaucoup, mais il n'est pas rare de voir une amélioration de la vitesse de 100%. (2) Dans certains cas, la récupération de place peut massivement ralentir une application gérée. Le. NET CLR fait un travail terrible avec de gros tas (disons, > 2 Go), et peut finir par passer beaucoup de temps en GC-même dans les applications qui ont peu-ou même pas-d'objets de durée de vie intermédiaire.

Bien sûr, dans la plupart des cas que j'ai rencontrés, les langues gérées sont assez rapide, à long terme, et le compromis de maintenance et de codage pour les performances supplémentaires de C++ n'est tout simplement pas bon.

Voici une référence intéressante http://zi.fi/shootout/

En fait, la JVM HotSpot de Sun utilise une exécution "en mode mixte". Il interprète le bytecode de la méthode jusqu'à ce qu'il détermine (généralement via un compteur quelconque) qu'un bloc de code particulier (méthode, boucle, bloc try-catch, etc.) va être exécuté beaucoup, puis il le compile JIT. Le temps requis pour compiler une méthode JIT prend souvent plus de temps que si la méthode devait être interprétée s'il s'agit d'une méthode rarement exécutée. Les performances sont généralement plus élevées pour le "mode mixte" car la JVM ne gaspille pas time JITing code qui est rarement, voire jamais, exécuté. C# et. NET ne le font pas. . NET JITs tout ce qui, souvent fois, perd du temps.

Allez lire à propos deDynamo de HP Labs, un interpréteur pour PA-8000 qui fonctionne sur PA-8000, et exécute souvent des programmes plus rapidement qu'ils ne le font nativement. Alors cela ne semblera pas du tout surprenant!

Ne le considérez pas comme une "étape intermédiaire" -- l'exécution d'un programme implique déjà beaucoup d'autres étapes, dans n'importe quelle langue.

Cela revient souvent à:

• Les programmes ont des points chauds, donc même si vous exécutez plus lentement 95% du corps de code que vous devez exécuter, vous pouvez toujours l'être performance-compétitif si vous êtes plus rapide à chaud 5%

• Un HLL en sait plus sur votre intention qu'un LLL comme C / C++, et peut donc générer du code plus optimisé (OCaml en a encore plus, et en pratique est souvent encore plus rapide)

• Un compilateur JIT a beaucoup d'informations qu'un compilateur statique n'a pas (comme, les données réelles que vous avez cette fois)

• Un compilateur JIT peut effectuer des optimisations au moment de l'exécution auxquelles les lieurs traditionnels ne sont pas vraiment autorisés do (comme réorganiser les branches pour que le cas commun soit plat, ou insérer des appels de bibliothèque)

Dans l'ensemble, C/C++ sont des langages assez moches pour les performances: il y a relativement peu d'informations sur vos types de données, aucune information sur vos données et aucun runtime dynamique pour permettre beaucoup d'optimisation de l'exécution.

Vous pouvez obtenir de courtes rafales lorsque Java ou CLR est plus rapide que C++, mais dans l'ensemble, les performances sont pires pour la durée de vie de l'application: voir www.codeproject.com/KB/dotnet/RuntimePerformance.aspx pour quelques résultats pour cela.

Voici la réponse de la Falaise Cliquez sur: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

Ma compréhension est que C/C++ produit du code natif pour s'exécuter sur une architecture de machine particulière. Inversement, des langages comme Java et C # s'exécutent sur une machine virtuelle qui fait abstraction de l'architecture native. Logiquement, il semblerait impossible pour Java ou C# de correspondre à la vitesse de C++ à cause de cette étape intermédiaire, mais on m'a dit que les derniers compilateurs ("hot spot") peuvent atteindre cette vitesse ou même la dépasser.

C'est illogique. L'utilisation d'un la représentation intermédiaire ne dégrade pas intrinsèquement les performances. Par exemple, llvm-gcc compile C et C++ via LLVM IR (qui est une machine virtuelle à registre infini) en code natif et obtient d'excellentes performances (battant souvent GCC).

C'est peut-être plus une question de compilateur qu'une question de langue, mais quelqu'un peut-il expliquer en anglais clair comment il est possible pour l'un de ces langages de machine virtuelle de mieux fonctionner qu'une langue maternelle?

Ici quelques exemples:

• Les machines virtuelles avec compilation JIT facilitent la génération de code à l'exécution (par exemple System.Reflection.Emit sur.NET) afin que vous puissiez compiler le code généré à la volée dans des langages comme C# et F#, mais vous devez recourir à l'écriture d'un interpréteur relativement lent en C ou C++. Par exemple, pour implémenter des expressions régulières.

• Des parties de la machine virtuelle (par exemple, la barrière d'écriture et l'allocateur) sont souvent écrites en assembleur codé à la main car C et C++ ne génèrent pas assez rapidement le code. Si un programme insiste sur ces parties d'un système, il pourrait théoriquement surpasser tout ce qui peut être écrit en C ou en C++.

• La liaison dynamique du code natif nécessite la conformité à un ABI qui peut entraver les performances et éviter l'optimisation de l'ensemble du programme, tandis que la liaison est généralement différée sur les machines virtuelles et peut bénéficier d'optimisations de l'ensemble du programme (comme les génériques réifiés de.NET).

Je voudrais également aborder certains problèmes avec paercebal réponse très upvoted ci-dessus (parce que quelqu'un continue de supprimer mes commentaires sur sa réponse) qui présente une vue polarisée contre-productive:

Le traitement du code sera effectué au moment de la compilation...

Par conséquent, la métaprogrammation de template ne fonctionne que si le programme est disponible au moment de la compilation, ce qui n'est souvent pas le cas, par exemple, il est impossible d'écrire une bibliothèque d'expressions régulières compétitive dans vanilla C++ car elle est incapable de générer du code à l'exécution (un aspect important de la métaprogrammation).

...jouer avec les types se fait au moment de la compilation...l'équivalent en Java ou C# est au mieux douloureux à écrire, et sera toujours plus lent et résolu à l'exécution même lorsque les types sont connus au moment de la compilation.

En C#, cela n'est vrai que pour les types de référence et n'est pas vrai pour les types de valeur.

Quelle que soit l'optimisation JIT, rien ne va plus vite que l'accès direct au pointeur à la mémoire...si vous avez des données contiguës en mémoire, y accéder via des pointeurs C++ (c'est-à-dire des pointeurs C... Donnons à César son dû) va fois plus vite qu'en Java / C#.

Les gens ont observé Java battant C++ sur le test SOR du benchmark SciMark2 précisément parce que les pointeurs empêchent les optimisations liées à l'aliasing.

Il convient également de noter que. NET tape la spécialisation des génériques dans les bibliothèques liées dynamiquement après la liaison alors que C++ ne peut pas car les modèles doivent être résolus avant lier. Et évidemment, le gros avantage des génériques par rapport aux modèles est les messages d'erreur compréhensibles.

En plus de ce que d'autres ont dit, d'après ma compréhension.NET et Java sont meilleurs dans l'allocation de mémoire. Par exemple, ils peuvent compacter la mémoire car elle est fragmentée alors que C++ ne le peut pas (nativement, mais il le peut si vous utilisez un ramasse-miettes intelligent).

Pour tout ce qui a besoin de beaucoup de vitesse, la JVM appelle simplement une implémentation C++, donc c'est une question plus de la qualité de leurs bibliothèques que de la qualité de la JVM pour la plupart des choses liées au système d'exploitation. Garbage collection réduit votre mémoire de moitié, mais l'utilisation de certaines des fonctionnalités STL et Boost les plus sophistiquées aura le même effet, mais avec plusieurs fois le potentiel de bogue.

Si vous utilisez simplement des bibliothèques C++ et beaucoup de ses fonctionnalités de haut niveau dans un grand projet avec de nombreuses classes, vous finirez probablement plus lent que d'utiliser une JVM. Sauf beaucoup plus sujettes aux erreurs.

Cependant, l'avantage de C++ est qu'il vous permet de vous optimiser, sinon vous êtes coincé avec ce que fait le compilateur/jvm. Si vous créez vos propres conteneurs, écrivez votre propre gestion de mémoire alignée, utilisez SIMD et passez à l'assemblage ici et là, vous pouvez accélérer au moins 2x-4x ce que la plupart des compilateurs C++ feront seuls. Pour certaines opérations, 16x-32x. C'est en utilisant les mêmes algorithmes, si vous utilisez mieux algorithmes et paralléliser, les augmentations peuvent être spectaculaires, parfois des milliers de fois plus rapide que les méthodes couramment utilisées.

Je le regarde à partir de quelques points différents.

1. Compte tenu du temps et des ressources infinis, le code géré ou non géré sera-t-il plus rapide? De toute évidence, la réponse est que le code non géré peut toujours au moins lier le code géré dans cet aspect - car dans le pire des cas, vous coderiez simplement en dur la solution de code géré.
2. Si vous prenez un programme dans une langue et que vous le traduisez directement dans une autre, à quel point cela sera-t-il pire? Sans doute beaucoup, pour tout deux langues. La plupart des langues nécessitent différentes optimisations et ont différents gotchas. La micro-performance consiste souvent à connaître ces détails.
3. Compte tenu du temps et des ressources limités, laquelle des deux langues produira un meilleur résultat? C'est la question la plus intéressante, car bien qu'un langage géré puisse produire du code légèrement plus lent (étant donné un programme raisonnablement écrit pour ce langage), cette version sera probablement faite plus tôt, ce qui permettra plus de temps consacré à l'optimisation.

Une réponse très courte: Compte tenu d'un budget fixe, vous obtiendrez une application java plus performante qu'une application C++ (considérations de ROI) En outre, la plate-forme Java a des profileurs plus décents, qui vous aideront à localiser vos hotspots plus rapidement