Discussion :

[notalp]

Bonjour,
Je cherche des tests de performance entre .Net et C++.
Merci à tous ceux qui ont des liens ou des résultats

++

[SaumonAgile]

C'est général comme question, les possibilités de test sont infinies, qu'est ce que tu recherches ?
De plus tu peux faire dire n'importe quoi à un test de performance, l'idéal est de comparer sur un programme complet, et pas sur le temps d'exécution d'une fonction.

[notalp]

dans le principe je suis d'accord mais on peut de manière formelle comparer la rapidité d"un language.
Par exmple dans la gestion de gdes matrices ou la manipulation d'une gde quantité de données...

[Keihilin]

dans le principe je suis d'accord mais on peut de manière formelle comparer la rapidité d"un language.

Mouais...Le problème est que les performances d'un langages ne sont pas toujours uniformes en fonction des scénarii. Un langage x peut être plus rapide que y sur certains types de traitement (et d'architecture) et plus lent sur d'autres...

Concernant .Net Vs C++, ne te casse pas trop la tête, C++ est globalement plus performant (en terme de rapidité d'exécution de code, entendons-nous bien). Cela dit, la différence est parfois très négligeable et même inexistante grâce à certaines optimisations à la volée effectuées par le CLR que C++ ne peut pas faire...

Google te fournira sans doute des tonnes de liens vers des tests...

[cinemania]

C'est meme encore plus compliqué que cela.

Non seulement la CLR peut faire des optimisations que C++ ne peut pas faire, mais en plus la CLR compile en arriere plan des pans entiers de code MSIL en code natif, puis exécute le code natif lorsqu'il est prêt en lieu et place de l'interprétation du MSIL. Et une fois qu'elle a achevé les fonctions critiques, elle compile tjs en arriere plan, le code moins usité. Le code pas ou peu utilisé n'est pas compilé.

Cette technique fait qu'au démarrage une appli .NET est lente, mais prend de vitesse avec le temps. Si l'appli est "petite" le temps de stabilisation est de l'ordre de quelques secondes.
Une appli .NET stabilisée en exécution peut parfois battre une appli directement codé en C++ natif, dans la meme boucle critique.

En effet, la CLR va appliquer la compilation avec des optimisations qu'elle peut faire qui vont dépendre du contexte d'exécution.
ton appli C++ est compilée à la compilation... et ces simplifications ne peuvent pas être évaluées puisqu'elles dépendent d'une phase qui suit la compilation.

Globallement, une application .NET demeure un peu plus lente qu'une appli native C++, mais le gain est souvent négligeable... sauf applications ultraspécifiques...
Quand à la manipulation de données, globallement si par manipulation de données tu entends base de données, là le rapport s'inverse littérallement et les appli .NET battent a plate couture tes appli C++ pour des bases supportées nativement comme SQL Server ou Oracle. (Cela vient des pilotes et des bibliothèques qui entre en jeu)

Ensuite tout dépend aussi de ta facon de programmer, mais globallement, un programme très bien écrit en .NET n'a pas a rougir face à son pendant C++ Natif.
En revanche alors que les techniques sont les memes entre la JVM et la CLR, globallement les appli JAVA sont nettement plus lente, et ca se ressent par rapport à une application native, et c'est encore pire si on a le malheur d'utiliser les SWING.

C'est pourquoi Java est a proscrire impérativement pour tout ce qui est serveur (a forte charge et réponse rapide), applications mathématiques lourdes.
.NET peut encore faire l'affaire, mais après tout dépend des besoins, et surtout de la façon dont sera programmée l'application.
Des mécanismes comme la Reflexion ou le Remoting sont très lent par essence, (cependant il n'y a pas d'équivalent de la Reflexion en natif)
et plombent littérallement les performances d'une application, mais sinon...

[notalp]

ok merci
Mais qui pourrait me communiquer un bench déja réaliser qui donne des exemples chiffrées pour (par exemple) les matrices, vecteurs, tableaux ...

Merki d'avance

[Kujara]

Dans le principe je suis d'accord mais on peut de manière formelle comparer la rapidité d"un language.

Non.

Au mieux tu peux comparer l'efficacité des compilateurs ....

En effet, la CLR va appliquer la compilation avec des optimisations qu'elle peut faire qui vont dépendre du contexte d'exécution.
ton appli C++ est compilée à la compilation... et ces simplifications ne peuvent pas être évaluées puisqu'elles dépendent d'une phase qui suit la compilation.

Techniquement faux aussi.

Profile guided optimisation.

Apres, c'est vrai que c'est peu utilisé, j'avoue >.<

[Keihilin]

Techniquement faux aussi.

Profile guided optimisation.

Apres, c'est vrai que c'est peu utilisé, j'avoue >.<

Oui bon, avant de clamer "Techniquement faux", comparons ce qui est comparable...

L'optimisation dont tu parles en C++ est une optimisation de compilation en 3 phases :

1. Instrumented Compilation
2. Instrumented Execution
3. Feedback Compilation

Au final, tu obtiens un exécutable optimisé selon une architecture précise et fortement dépendante du jeu de tests utilisé.

Bref, un travail réalisé à la volée par la CLR qui ne t'oblige pas à recommencer le cycle complet en cas de changement d'environnement d'exécution.

Soyons pragmatiques; une machine virtuelle ne peut pas dépasser un code C++ en terme de performance (sauf quelques cas particuliers), et un compilateur C++ (statique) ne peut pas réaliser les mêmes optimisations à l'exécution, et avec la même souplesse qu'une machine virtuelle.

[cinemania]

Quoi qu'il en soit,

tu ne trouvera pas de vrais Benchmarks de comparaison qui soient valables.
Si tu développe la meme application en .NET et C++ natif tu aura des variations au niveau du résultat en terme de compilation, ensuite il faut faire des comparaisons sur des choses comparables.

Si ton appli démarre fait un calcul et arrete... meme là le bench est sans intéret car tu ne saura pas exactement ce que tu aura mesuré, ni sur l'appli native, ni sur l'appli managée.
Et oui... quand tu lance ton appli native, le systeme met un certains temps à la charge, la démarrer, après avoir tout alloué... ce temps varie systematiquement d'un lancement à l'autre.
Quand tu lance ton appli managée, il lance la CLR (et oui domage l'est pas intégré totalement à l'OS) et ensuite le CLR lance ton appli... ensuite on sait tous qu'une appli .NET est lente à démarrer (deja en partie à cause de ca)

résultat : les temps mesurés dans l'une et l'autre ne concernes pas ton calcul vectoriel, mais la totalité de l'application ce qui n'est pas une bonne chose.
Et oui dans une appli managée toute mémoire alloué est systematiquement libérée à la fin du cycle de vie de l'appli (ou du moins persiste peu de temps après, merci le GC)
Ton appli native pour peu qu'elle oublie de bien nettoyer derrière elle (oublie de désalloué TOUT ce qui a été alloué... c'est très souvent le cas) va déjà gagner du temps. (en effet, windows ne nettoie pas derrière, et là pas de ramasse miettes...)

[Kujara]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Au final, tu obtiens un exécutable optimisé selon une architecture précise et fortement dépendante du jeu de tests utilisé.

J'ai jamais dis le contraire

Je tenais juste a signaler a ceux qui ne le savaient pas, qu'en c++ il est possible d'optimiser selon le contexte.
C'est dur, c'est pas super efficace si ton appli change, mais si c'est toujours la meme utilisation, meme architechture et que ton panel de test est représentatif, c'est possible .

Cela dit, c'est evident que la clr et la jvm en java font les optimisations runtime de façon beaucoup plus souple et sans necessiter de travail coté programmeur.

[Kujara]

(en effet, windows ne nettoie pas derrière, et là pas de ramasse miettes...)

Euh, hein ?

Windows libere la mémoire quand tu quitte un programme compilé normal.

A partir de la, meme si la mémoire n'est pas mise a zero, quand tu relance ton programme, les variables metterons autant de temps a se creer.

Apres, si tu parles point de vue prefetch du code, mise en memoire des dlls etc, ça doit valoir aussi pour c#, non ?


De plus , si tu fait un bench de performance d'un programme codé toi meme, tu peux probablement faire un timer interne, qui ne demarre qu'une fois que le programme rentre dans *ton* code, donc ça ne prendrait pas en compte le temps de chargement CLR / Dlls. Donc resultats beaucoup plus fiables.

[SaumonAgile]

Tout ça pour dire que le client final s'en br.... complètement de savoir si ça prend un dizième de quart de seconde en plus pour effectuer une action en managé qu'en non managé. Lui, ce qu'il veut, c'est que ce soit intuitif et fiable.
Des fois, vous avez le don de perdre votre temps pour des bétises...

[Keihilin]

Tout ça pour dire que le client final s'en br.... complètement de savoir si ça prend un dizième de quart de seconde en plus pour effectuer une action en managé qu'en non managé.

Dans ton petit monde merveilleux peut être, mon ami

Mais il y a des cas ou ce dixième de quart de seconde est très très important...

[SaumonAgile]

Dans ton petit monde merveilleux peut être, mon ami

Mais il y a des cas ou ce dixième de quart de seconde est très très important...

Oui mais dans ce cas là, les concepteurs ne se posent pas ce genre de questions...
Toujours est-il que l'intérêt de ce sujet est plus que limité, ne serait que par le fait qu'il soit on ne peut plus général. La question fut-elle "je dois développer une application haute disponibilité pour un système temps réel dans la contrainte principale est le délai de réponse à un évenement réseau, quel est le meilleur choix entre du managé et non managé ?", il peut y avoir débat. Mais un enième troll du genre c'est quoi le meilleur entre managé et non managé...