Version imprimable
Bonjour,
J'aurais aimé avoir des indications sur la performance du langage C# :
ce langage donne-t-il des résultats comparables au langage de programmation C++ en terme de rapidité ?
En particulier : le langage de programmation C# permet-il de réaliser des applications plus plus performantes que feu Visual Basic 6 ?
Merci d'avance pour votre aide
Il me semble que C# n'est ni plus rapide ni plus lent que VB.net (d'après quelques tests que j'ai fait). Et C++ est plus rapide...
Globalement le C# est logiquement un poil plus lent qu'un langage compilé natif vu qu'il passe par un pseudo code, une librairie enorme.
Maintenant la perf d'un programme est surtout liée à tes algoritmes, et seulement un peu à la performance pure du compilo. En dehors de besoins tres particuliers, tu t'en fous.
Mais tu n'as pas donnés tes besoins? On ne peut pas vraiment te répondre.
Malgré leur noms semblable (habile tactique commerciale), C# et C++ n'ont strictement rien à voir. Il n'ont pas été créer dans le même but, n'ont pas la même utilité, pas les mêmes possibilité et pas les même performances.
J'ai répondu à un post similaire sur ce forum il y a quelques jours en donnant de détails sur les écueils à éviter pour obtenir de bonnes performances.
si tu dois aller vraiment vite. C++ permet de "descendre" au plus près du processeur.
C# non !
C# n'a pas été développé pour permettre d'aller vite : pas de préprocesseur, pas de structures de données contigües. pas d'allocation globale de memoire.
Ca ne veut pas dire qu'il est tres lent mais pour un rendu graphique en temps réel ou un traitement de signal par exemple, il est définitivement hors course par rapport au C ( ++ ou non) qui lui , a gardé l'esprit de ses créateurs des années 60 et permet à peu près tout ce que le hardware autorise. Au prix d'un développement beaucoup plus long et pointu cependant
Je n'ai pas de conseil génial à donner, simplement , si tu fais vraiment du temps réel, C# ne suffira pas - et il est certain que ça ne change pas à l'avenir.
Dans cette logique, Java est aussi moins rapide que C++ ?? puisque Java et C# utilise presque le même principe, ou bien le faite que .net supporte bcp de langages influe sur la vitesse ? et pourquoi le java est utiliser pour des systèmes embarqués. ;)
Bah en même temps...Citation:
Envoyé par Midou45
Java, sous sa forme javacard est utilisé dans les carte à puce pour des raisons de sécurité et de cloisonnement des données, clairement pas pour ses performances...Citation:
Envoyé par Midou45
De même sur les téléphones portables, c'est une question de portabilité (quand une personne télécharge les binaires d'un jeu, pas besoin de se demander sur quel téléphone ça va être exécuté, juste qu'il y a une machine virtuelle) et de "sécurité" grace à la machine virtuelle qui sert de bac à sable. Là encore, rien à voir avec les perfs.
Mais ceci n'a rien à voir avec la question..
Citation:
Envoyé par alex_pi
Sa dépend de votre façon de voir les choses ! ;)
- C# est généralement aussi performant que VB.NET puisque c'est la même chose quasiment : dans les deux cas c'est basé sur le framework .NET et cela utilise la même technologie pour l'exécution.
- Sur une machine récente avec assez de mémoire vive disponible, une application C# ou VB.NET peut être plus performante qu'une application faites avec Feu l'ancien Visual Basic 6, car VB6 n'a pas de compilation native et la technologie d'exécution de DotNET est plus moderne et performante que l'exécution du code pseudo compilé du feu VB6.
- Généralement une applications compilée avec C++ pourra être plus rapide d'exécution qu'une application exécutée avec le framework .NET, cependant cela n'est pas toujours vrai car la technologie d'exécution des applications DotNET s'adapte dynamiquement à la machine cible alors que si tu diffuse un exécutable fait à partir de C++ il n'est nullement optimisé pour une machine cible en particulier. Bref avec les machines moderne dans plus de 90% des cas la performance des applications n'est pas un critère pour un choix technologique de cette importance.
C# et C++ peuvent sont comparables dans de nombreux domaines (Application bureau, UI etc.) mais il sera surement plus lent que me c++ si du fait du calcul lourd (3d, HPC etc.). Enfin il vaut mieux optimiser ses algorithmes d'abord, et l'augmentation de la productivité peut être plus important que la vitesse d'éxecution.
Dans 99% des cas ce n'est pas le language qui joue sur la performance mais le developpeur lui-meme, je pense pouvoir te rassurer en te disant que je pense que tu ne fais pas parti des 1% en tout cas pas encore.
Donc la question que tu dois te poser n'est pas une question de performance mais plutot de besoin, quel est de ces 2 languages m'est-il plus approprie pour un projet type donne.
Citation:
Envoyé par Tellmarch
Juste une petite réserve par rapport à ces affirmations... C'est vrai, à condition en VB.NET de ne pas utiliser le late binding (Option Strict Off). Sinon, les appels de méthodes sont résolus à l'exécution par réflexion, ce qui est très pénalisant pour les performances... C# ne permet pas le late binding, donc la question ne se pose pas (mais C# 4 introduit le type dynamic qui permet le late binding).Citation:
Envoyé par Pierre Louis Chevalier
Le langage non, mais la plate-forme d'exécution oui... C++ est compilé en code natif directement exécutable par le processeur, donc ça évite la phase de précompilation qu'on a sur la plate-forme .NET. Par contre, cette précompilation ne se fait que lors de la première exécution d'un assembly .NET : le code natif généré est mis en cache et réutilisé pour les exécutions suivantes, qui sont donc plus rapidesCitation:
Envoyé par zeavan
salut.
a mon avis avec la puissance des machines actuelle la rapidité n'est pas un atout majeur, par contre un bon langage est celui avec lequel on peut offrir a l'utilisateur plus de fonctionnalités en un laps de temps plus court, c'est le cas de C# avec le Framework .NET.
a+
Tout à fait :bravo:Citation:
Envoyé par aityahia
D'après ce que j'ai pu lire, il semble que le compilateur C# soit plus performant dans certains cas.Citation:
Envoyé par Pierre Louis Chevalier
Du coup, pour un "même" code C# et VB.NET, il y a moins de code MSIL avec le compilateur C#.
Je ne suis pas tout à fait d'accord, surtout dans le cadre d'une grosse application, les machines ne compensent pas à l'heure actuelle des programmes lourds et non optimisés.Citation:
Envoyé par aityahia
En revanche effectivement le langage n'est pas le critère qui va compter dans la rapidité d'un programme. Beaucoup moins que la conception et la simplification du code source.
En gros, C# est
- un peu moins performant que C++ car nécessite plus de mémoire au lancement d'une application, effectue une compilation préalable à chaque exécution, isole complètement l'application de l'OS (en principe) et du matériel.
- un peu plus performant que VB6 dont la machine virtuelle était de moins bonne qualité que le CLR.
Et puisqu'il faut également en parler, C#, VB.NET, J# et C++/CLI ont globalement des performances similaires car générant pratiquement les mêmes codes IL. Pour des programmes équivalents écrits dans ces différents langages, les différences de performances viendraient essentiellement de l'habileté des programmeurs ou de la qualité d'implémentation des compilateurs (à supposer que vous utilisiez des compilateurs de différents éditeurs; ceci est surtout vrai pour C# et VB.NET dont il existe des compilateurs tiers)
Maintenant la question est: "lequel dois-je utiliser?". Et la réponse est toute simple: ça dépend de ce que vous faites. C# est comme beaucoup de langages de sa génération optimisé pour le développement d'applications d'entreprise, le développement Web et le développement d'applications pour équipement mobile (qu'il ne faut pas confondre avec le développement d'applications embarquées; je doute que quelqu'un songe à utiliser du C# pour guider un missile tomahawk;); mais bon, sait-on jamais...). De son côté, C++ est essentiellement adapté à la programmation système, au développement de progiciels et à l'écriture de programmes hautement exigeants en performances (jeux vidéos, applications scientifiques, etc...). Il faut dire que cette donne varie en fonction des époques. Autrefois, l'on considérait que seul FORTRAN était réellement adapté à ce type de développement, que C était à peine tolérable et que C++ était résolument dédié au développement d'applications rapide. Aujourd'hui, beaucoup de gens considèrent C++ comme une référence en matière de performances. Ceci est en partie dû au fait qu'on le confonde très souvent avec le C son ancêtre. En vérité, même si les deux langages sont globalement compatibles, il est toujours bon de rappeler que CE N'EST PAS DU TOUT LE MÊME LANGAGE! Mais bon puisqu'il faut retenir l'essentiel, voici le classement des langages évoqués dans l'ordre décroissant des performances:
C, C++, {C#, VB.NET et les autres ...}, VB6.
Remarquez que s'il fallait les classer en fonction de la productivité, il suffirait d'inverser la liste.
Pour la performance, je voudrais relativiser ce qui a été dit plus haut. C'est actuellement à la mode de penser que la performance du langage est moins importante que la rapidité de développement qu'il permet, mais ce n'est pas toujours vrai.
Il faut vraiment effectuer son choix en fonction de ce qu'on veut faire.
Pour des tâches répétitives et relativement simples, les langages compilés sont BEAUCOUP plus adaptés.
A titre d'exemple, pour modéliser un ballon avec un algorithme simple basé sur la loi des gaz parfaits, on a besoin de
-Décomposer le ballon en une série de segments
-Faire une série d'opérations faisant évoluer la simulation à répétition, le plus vite possible parce que sinon d'une part le résultat à l'écran n'est pas fluide et d'autre part il perd en exactitude (ce qui est vraiment problématique dans certains cas).
En python, avec suffisamment de segments pour que la forme obtenue semble ronde, je pouvais obtenir une douzaine d'images par seconde sur une machine un peu datée. En C, on approchait plutôt de la cinquantaine avec le même algorithme :mouarf:
Les langages interprétés sont souvent plus pratiques, mais il ne faut pas leur confier des tâches onéreuses en ressources. Sinon, il faudra un PC de guerre pour faire tourner tes programmes... Je pense qu'il vaut mieux connaître les deux.
Exemples de cas où les langages interprétés sont plus adaptés :
-Applications graphiques qui affichent des fenêtres et des jolis boutons et stockent des réglages dans des fichiers (ex : panneau de configuration windows)
-Logiciels de bureautique
-Logiciels de lecture multimédia, widgets, et autres petites applications de bureau
-Applications destinées à tourner sur un grand nombre de machines différentes, avec des matériels et systèmes d'exploitation variés
Exemples de cas où ils sont à bannir, à part quand on a la chance de trouver une fonction toute faite (programmée en C :p) pour le faire :
-Simulation physique
-Édition multimédia
-Manipulation de fichiers nombreux ou lourds (ex : bases de données)
-Programmes qui doivent tourner très souvent (plusieurs fois par secondes)
certainement le choix d'un langage ce fait a base de l'orientation de l'application , si mon projet se rapporte une application qui nécessite de gros calculs tel que les application de modélisation 3D j'opterai certainement pour C++, mais dans un cadre d'entreprise ou les dirigeants exigent des solutions fonctionnelles ASAP ou le gains de quelque ms sur une action n'est pas salutaire.Citation:
Envoyé par Jidefix
par contre l'optimisation est crucial quelque soir le langage.
Et de C++ avec des frameworks qui s'imposent presque en standard.Citation:
Envoyé par aityahia
VB6 est totalement à proscrire et c'est une technologie dépassée par rapport à C#/NETCitation:
Envoyé par jejerome
*C# et .NET supportent enfin le multithreading.
C'était difficile de faire la même chose en VB6.
*les exceptions sont mieux gérées en .NET . Et même pour ce qui est du code non managed
Une dll écrite en C qui plante risque de faire planter le programme VB6 appelant.
*il n'y a pas le "dll hell" qu'il y avait avec VB6.
L'inconvénient majeur de C#/.Net c'est que la technologie est plus lourde donc il faut une machine plus puissante.
Dans quelles couches logicielles ces frameworks s'imposent en standard ? De ce que je connais et peux compiler avec code::blocks ou visual studio c'est plus du domaine de l'utilitaire :ccool:Citation:
Envoyé par Alp
Mouais.Citation:
Envoyé par hegros
Je ne considèrerais ni Boost ni Qt comme des "utilitaires". La différence c'est qu'il n'y a pas UNE boîte derrière le C++ pour tout gérer, et surtout le C++ n'a été normalisé qu'en 98 pour la première fois. Avant cela, et encore un peu après, chacun faisait ce qu'il voulait dans son coin.
Au passage, C++0x intègrera pas mal de chose, dont le support *standard* du multithreading, et pas mal d'autres choses intéressantes. Dans un Technical Report de C++0x on pourrait bien avoir le réseau (Boost.Asio) intégré en standard également. Une proposition a été faite.
Bref, si on se renseigne au bon endroit, on peut développer du code C++ pour une quantité impressionnante de plateformes (un code utilisant Qt même pour le GUI passe tel quel sur de plus en plus de portables, par exemple), avec l'efficacité, sans avoir à se trimballer des pointeurs partout (depuis des années, on voit les pointeurs partout comme une mauvaise pratique du C++, on parvient enfin à faire comprendre aux autres que le C++ moderne est un langage qui n'a plus tant de choses que ça de communes avec le C), à gérer la mémoire à la main, etc. Et des bibliothèques comme Boost ou Qt fournissent une quantité énorme d'outils, du GUI au réseau, du Multithreading à la métaprogrammation, de la manipulation avancée de flux à l'intéraction avec des BDD, etc ...
Bref, beaucoup de gens évoluent dans leur langage de prédilection sans ouvrir les yeux sur, par exemple, l'évolution du monde C++. Et ils se retrouvent donc à ressortir des arguments qui datent de 10 ans. Je le sais car je m'amuse à faire la même chose pour Java ;) (pour plaisanter)
C'est vrai c'est un peu fort de café avec boost et qt il y a vraiment une grande différence avec le c++ d'antan.
je n'ai encore pas testé qt ni boost pour voir le niveau de difficulté pour configurer un projet et explorer cela sera probablement intéressant :P
Ils sont très simples à installer (paquets linux / installateurs pour VC++ / compilation très facile à mettre en oeuvre).Citation:
Envoyé par hegros
Enfin, c'était juste pour donner une image plus proche du C++ d'aujourd'hui que ce qui était évoqué dans les précédents posts, après je ne nie absolument pas les qualités de C# ou Java :)
De toutes façons, la rapidité d'un programme, c'est 20% le matériel, 20% le langage, et 60% l'algo... C'est "empirique", mais c'est souvent très vrai.
On peut de toutes façons distinguer trois types de langages :
- Interprétés,
- Managés / pseudo-code,
- Natifs.
Les langages interprétés (Python, PHP, Ruby, LUA, Javascript, ...) nécessitent un interpréteur pour fonctionner (si, si, j'vous assure ! :D), et souvent uniquement un interpréteur, mais offrent alors une portabilité colossale... La plupart des interpréteurs sont en ligne de commande, et peuvent être compilés sur quasiment n'importe quel système existant.
De plus, ils permettent des choses difficilement accessibles aux autres langages, comme la modification de code à la volée et l'auto-modification des programmes.
Inconvénient, ils sont souvent très lents... Dans le cadre d'un séquenceur / système de contrôle, ça n'a aucune importance. Si c'est pour du calcul lourd, c'est plus que rédhibitoire. Certains de ces langages sont "améliorés" en terme de vitesse d'exécution via une "compilation" à la volée lors de la première exécution (PHP notamment est plutôt efficace à ce sujet).
Autre inconvénient, les erreurs de syntaxe ne sont pas forcément détectées au lancement du programme, parfois c'est lorsque l'on arrive sur la ligne fautive uniquement (voire avec des valeurs particulières en plus), ce qui rend le test extensif de tels programmes assez pénible.
Les langages managés / en pseudo-code (.NET, inclus C# bien sûr, et Java) sont nettement plus véloces que les langages interprétés, par contre ils nécessitent un compilateur, un débugger, un IDE / gestionnaire de projets, bref toute une chaîne de développement. Leur portabilité est limitée à celle du framework qui les soutient (JDK/JRE, .NET) : si le framework existe, les programmes pourront être portés. Sinon, ça risque d'être coton, voire infaisable sans l'aide de la société éditrice. Avantage, par contre, si le framework existe, le programme n'a pas besoin d'être recompilé pour être utilisé sur une autre plate-forme matérielle.
Là aussi, une compilation "native" du pseudo-code est en général faite à la première exécution, pour accélérer le traitement... Cela ne résoud pas tout, hélas.
Enfin, les langages natifs, les plus "lourds" à gérer, produisent du code directement exécutable par le processeur, et sont compilés pour un couple processeur / système d'exploitation "figé". Un exécutable C compilé pour PowerPC / Linux ne fonctionnera JAMAIS tel quel sur une machine Windows / x86... Le programme devra être recompilé impérativement. De plus, le code binaire produit n'est pas le même en fonction du compilateur, et encore moins en fonction du langage source. Le débuggage peut s'avérer difficile et fastidieux en fonction des optimisations du compilateur, voire dans certains cas quasi-impossible.
Par contre, c'est le seul moyen d'obtenir des performances maximales (ou presque), en fonction du langage utilisé toutefois, et normalement déployable sur n'importe quelle plate-forme compatible avec simplement un "jeu" de librairies dynamiques (runtimes) pour certaines applications.
Par exemple, en considérant à chaque fois un matériel identique et des algos optimisés au quart de poil, on a souvent le classement suivant pour les langages les plus connus : Assembleur < C < C++ < Pascal/Delphi < ADA
Après, il faut voir aussi la vitesse de développement avec chacun de ces langages : faire un truc qui ne crashe pas en assembleur, ça peut devenir vite une prise de tête colossale... En ADA, par contre, c'est plutôt "si ça compile, ça marche", vu la rigueur colossale du langage au niveau de la phase lexicale/syntaxique...
Cela ne change pas qu'entre un programme en C, avec un bon algo, et son équivalent Java avec un algo tout aussi optimisé, la différence de performances sera réelle, mais pas forcément aussi énorme qu'on pourrait le croire (hors calculs lourds, faut pas pousser non plus). Par contre, la vitesse de développement avec un langage de très haut niveau est bien plus réduite qu'avec un langage "bas niveau".
De même, en restant dans le domaine d'un "lourd" du domaine, C++ : entre un programme C++ "brut", où tout est développé / optimisé "à la main", et un programme C++ écrit en utilisant intensivement les templates, la STL et des API comme QT, le résultat final est là aussi clair et net : la version "à la barbare" est plus rapide (à optimisation d'algo égale, bien entendu), mais la version "soutenue" par des librairies de haut niveau a par contre pris deux fois moins de temps (au moins !!) à être écrite...
Quant à la perte de performances, même si elle est toujours mesurable, c'est parfois bien moins de 1% de différence si l'on n'est pas en train d'écrire une application de calcul lourd et/ou brassant d'énormes quantités de données...
Si c'est pour faire une application à usage unique / interne, une faisabilité, ou encore un outil de test, ou encore quelque chose de souvent modifié, il faut sérieusement se pencher sur la question du temps de développement... Et envisager les langages interprétés.
Si c'est pour quelque chose ne devant pas être touché, devant être rapide, diffusé largement, etc. alors les langages natifs sont à préférer.
Si cela ne doit pas être touché, diffusé largement mais que la rapidité d'exécution n'est pas cruciale, les langages managés sont l'idéal.
Comme dans presque tous les domaines de l'informatique, le choix du langage, c'est surtout une question de besoins et de contraintes de développement...
La réponse de Mac Lak est parfaite et précise bien les 3 types de technologies de développement d'application (interpréteur, pseudo-code managé, et compilation native) et leurs spécifités et limites.
J'ai juste un petit bémol d'étonnement sur la chaine comparative de la vitesse d'exécution qu'il nous propose pour les langages compilés:
Assembleur < C < C++ < Pascal/Delphi < ADA
En particulier comment justifie-t-il C < C++ et surtout C++ < Pascal/Delphi
Pour C < C++ je peux encore admettre une infime différence due aux indirections supplémentaires qu'induisent l'utilisation d'objets polymorphiques, en particulier lors des appels de méthodes virtuelles, mais en revanche comment justifier la différence C++ < Delphi, attendu que ces deux langages sont de technologies comparables, ne se différenciant essentiellement que par le choix de la syntaxe issue de C ou issue de Pascal. En ce qui me concerne je n'ai pas pratiqué le C++, j'ai développé longtemps sous Delphi avant de rejoinre le monde du pseudo code managé de C# .Net. Donc je suis mal placé pour véritablement juger de manière neutre et pragmatique d'une éventuelle différence d'efficacité fondamentale au bénéfice de C++ par rapport à l'excellent compilateur Delphi (et de ses optimisations du code généré) de feu Borland repris par Embarcadero. Je serais intéressé de connaitre les arguments qui permettent à Mac Lak de justifier son affirmation comparative.
Sinon, encore une fois son résumé est excellent.
C'est un beau déterrage de thread (presque 4 ans depuis le message précédent !), mais il tombe à pic : Microsoft vient d'annoncer .NET native, qui ambitionne de donner aux applications .NET les performances de C++ :)Citation:
Envoyé par ChipRaptor
salut Tomlev c'est une nouvelle incroyable,merci pour l'info et curieux que cela ne suscite pas plus de réaction..
il n'y aura plus d'intérêt à programmer en C++ alors :mrgreen:
Mat ! M'enfin... On est pas vendredi !
non mais faut bien alimenter les discussions :mouarf::mouarf:Citation:
Envoyé par Cirrus Minor