Le langage C# pour .NET est il aussi performant en rapidité que C++ ?

Le , par jejerome, Membre du Club
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Mat.M Mat.M - Expert éminent sénior https://www.developpez.com
le 20/05/2009 à 20:53
Citation Envoyé par jejerome  Voir le message
En particulier : le langage de programmation C# permet-il de réaliser des applications plus plus performantes que feu Visual Basic 6 ?

VB6 est totalement à proscrire et c'est une technologie dépassée par rapport à C#/NET

*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.
Avatar de hegros hegros - Membre Expert https://www.developpez.com
le 21/05/2009 à 0:13
Citation Envoyé par Alp  Voir le message
Et de C++ avec des frameworks qui s'imposent presque en standard.

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
Avatar de Alp Alp - Expert éminent sénior https://www.developpez.com
le 21/05/2009 à 1:31
Citation Envoyé par hegros  Voir le message
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

Mouais.
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)
Avatar de hegros hegros - Membre Expert https://www.developpez.com
le 21/05/2009 à 2:06
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
Avatar de Alp Alp - Expert éminent sénior https://www.developpez.com
le 21/05/2009 à 2:09
Citation Envoyé par hegros  Voir le message
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

Ils sont très simples à installer (paquets linux / installateurs pour VC++ / compilation très facile à mettre en oeuvre).

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
Avatar de Mac LAK Mac LAK - Inactif https://www.developpez.com
le 03/06/2009 à 12:17
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 ! ), 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...
Avatar de ChipRaptor ChipRaptor - Nouveau Candidat au Club https://www.developpez.com
le 04/04/2014 à 9:32
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.
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 04/04/2014 à 9:58
Citation Envoyé par ChipRaptor  Voir le message
...

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++
Avatar de Mat.M Mat.M - Expert éminent sénior https://www.developpez.com
le 22/04/2014 à 12:33
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
Avatar de Cirrus Minor Cirrus Minor - Membre émérite https://www.developpez.com
le 22/04/2014 à 12:55
Mat ! M'enfin... On est pas vendredi !
Avatar de Mat.M Mat.M - Expert éminent sénior https://www.developpez.com
le 22/04/2014 à 14:55
Citation Envoyé par Cirrus Minor  Voir le message
Mat ! M'enfin... On est pas vendredi !

non mais faut bien alimenter les discussions
Offres d'emploi IT
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil