Salut,
j'ai un choix de langage à faire pour un projet, la performance en terme de vitesse d'éxécution est une contrainte du projet.
Quand est-il aujourd'hui de la différence de vitesse c# et ++ ?
merci
Version imprimable
Salut,
j'ai un choix de langage à faire pour un projet, la performance en terme de vitesse d'éxécution est une contrainte du projet.
Quand est-il aujourd'hui de la différence de vitesse c# et ++ ?
merci
le c++ est en théorie plus rapide que le c#
en pratique ca peut etre différent, ou négligeable
par exemple un mauvais codeur c++ fera des trucs plus lent que certains en c#
après il faut aussi savoir réellement ce que tu as à faire
si c'est pas du calcul atomique ou météorologique, le c# peut amplement suffire, la différence de performance entre les 2 langages n'étant pas énorme, et les pc d'aujourd'hui plutot puissant
que dois tu faire dans ton programme ?
Salut,
Comme Pol63 l'a dit, selon ce que fait exactement le programme la différence peut être négligeable. Par contre, selon l'interface graphique, on peut dire qu'en C++ c'est souvent rapide à exécuter, et en C#... plus rapide à coder !
Par exemple, si ton appli a peu de fenêtres différentes, que le style par défaut (couleurs, bordures etc.) suffit, et que tu fais beaucoup d'appels à des fonctions système de Windows (timers très précis, gestion de handles...), ou si tu veux manipuler des pointeurs, prends C++.
Par contre si tu veux t'amuser à faire des trucs qui sortent de l'ordinaire dans l'interface (animations, skins...), que tu fais beaucoup d'appels à des bases de données, à des webservices ou autres, prends C#, c'est plus facile.
A noter que rien ne t'empêche non plus de créer une couche interface en C# et des modules en C++ pour le calcul ou autres.
bonjour ,
le c++ est le plus proche de langage machine car le compilateur c++ crée un code exécutable sur machine sans passe par le code intermédiaire comme le c# ou vb.net en plus c++ ne nécessite par un runtime pour s'exécute ce qui lui rend plus rapide mais moins portable.
faudra qu'on m'explique pour plein de setup installent c++ runtime alors ... (seulement pour le visual c++ ?)
Oui, Visual C++ a la facheuse tendance à lier tout les exécutables qu'il crée avec le runtime visual c++ de sa version, d'ou la nécessité de l'installer lors d'un déploiement. Si tu compile en natif avec Mingw tu n'en a pas besoin.
Il faut quand même préciser que cette règle générale n'est de toute manière valide qu'avec du C++ "natif" qui, comparé au C# toujours managé, sera en effet plus rapide (en considérant dans les deux cas un code optimal).Citation:
Envoyé par Pol63
Si on parle de C++ managé, il n'y a aucun avantage de performance à espérer.
Ca c'est valable quel que soit les langages considéré :DCitation:
par exemple un mauvais codeur c++ fera des trucs plus lent que certains en c#
Tiens c'est nouveau cela !Citation:
Envoyé par azstar
Tu devrais aller expliquer à Microsoft qu'il faut qu'ils arrêtent de livrer leurs OS avec le RT C++, puisqu'il ne sert à rien.
je parle pas d'un C++ de microsoft ou C++.NetCitation:
Tiens c'est nouveau cela !
Tu devrais aller expliquer à Microsoft qu'il faut qu'ils arrêtent de livrer leurs OS avec le RT C++, puisqu'il ne sert à rien.
moi je parle de C++ le le fils de C
Sauf que C++ utilise un RT, à moins de linker statiquement les librairies.Citation:
Envoyé par azstar
Microsoft n'a rien à voir la dedans.
je me demande si le code compile de C++ (de microsoft ) est traduit apres la compilation à un code intermidiare ?
si oui alors alors il necissite un RT.
mais si après la complication on a un code près à t'exécute (assembleur ) ,la pas besoin d'un RT ? n ec pas Bluedeep?!!
Tu mélanges tout.Citation:
Envoyé par azstar
En C++ managé, le code est traduit en IL comme avec n'importe quel langage .Net
En C++ natif,la notion d'IL n'existe pas et le compilateur génére un format COFF (comme tous les compilateurs natifs, du moins sur Unix et dérivés et Windows).
Ca n'a rien à voir avec le besoin d'utiliser un RT.
la je te dit désolé.
et le rôle de RT?
je dit que RT sert à exécute ou interpréter le code ?
alors si on est en IL on besoin d'un RT pour exécute notre code IL puisque 'il est compréhensible par RT?
A moins que les choses ont changées, il n'y a jamais eu besoin d'un runtime pour faire tourner une application en natif C ou C++.
Les seules choses nécessaires sont les bibliothèques système et celles qui sont inclus lors de la compilation (et encore si ils sont lié de façons dynamique).
Pour les binaires managés, il faut le RunTime puisque le processeur ne sait pas exécuter du code IL en natif.
toute a fait ketan.Citation:
je me demande si le code compile de C++ (de microsoft ) est traduit apres la compilation à un code intermidiare ?
si oui alors alors il necissite un RT.
mais si après la complication on a un code près à t'exécute (assembleur ) ,la pas besoin d'un RT ? n ec pas Bluedeep?!!
alors on peut dire C++ de microsoft est plus portable que C++ natif .
on prenant par considération que microsoft vise a rendre .NET exécutable en Linux .
C'est précisément la définiton générique que je donnerais d'un runtime, mais bon.Citation:
Envoyé par ketan
Tu ne peux pas faire tourner ton programme C++ (ou alors, si, dans le cas d'un programme C n'utilisant aucune bibliothèque) sans DLL installées, à moins de linker statiquement. (mais il existe - existait ? - un produit permettant de faire cela aussi avec .Net; je ne sais pas si il est toujours maintenu).
Après cela, on peut toujours jouer sur les mots et considérer que tes bibliothèques ne constituent pas un runtime.
wikipedia aurait tendance à donner raison à bluedeep
@azstar : essaye de te relire, parce que des fois on croirait que t'es pas francais
Alors à ceux qui mélanges les concepts.
Il y a plusieurs façon de développer avec C++ sous visual.
- La première par défaut : C++ natif avec liaison dynamique sur les RT VC++.
- La seconde C++ natif avec liaison statique sur les RT VC++ (dans ce cas elles ne sont plus nécessaires car le code utile à l'intérieur est rapatrié dans l'exécutable et les dll finales)
- La troisième qui consiste à utiliser C++/CLI et ne pas du tout utiliser la couche managée.... on se demande l'intérêt mais j'ai déjà vu ça.
Quelle différence entre C++ avec RT et C++/CLI ?
très simple, la runtime VC++ que l'on doit souvent installer n'a strictement rien avoir avec DOTNET, ce n'est en aucun cas le framework. Il s'agit d'une bibliothèque de code, que linux lie directement dans l'exécutable de sortie, et visual studio, permet de laisser dans une série de DLL externes.
Lier statiquement ou pas... tel est le choix du développeur, mais sans importance au final sur la rapidité d'exécution du code.
Pour ce qui est de C++/CLI il s'agit de C++ + Extensions DOTNET, dans ce cas la compilation peut avoir des résultats bien différent selon le contenue du code C++/CLI...
Un programme dotnet est compilé dans un langage intermédiaire -CIL- exécuté par la CLR du framework DOTNET, qui encore une fois n'a rien avoir avec les RT VC++ !!!
C++/CLI permet de coder en natif et en managé dans le même code et projet, ce qui engendre généralement un exécutable ou une dll à cheval entre les 2 mondes, avec un prélude natif et une assembly dotnet à l'intérieur.
Pour en revenir au sujet initial qui est la différence de vitesse d'exécution...
Et bien il n'y a pas de réponse toute faite, mais dans l'absolu la différence n'est pas perceptible.
La raison est simple, la CLR utilise un compilateur JIT (Just In Time) qui compile à la volée, en arrière plan, en code natif directement exécutable par le processeur, le code intermédiaire en CIL, et chose très intéressante, le C-JIT optimise le code obtenu, tout aussi bien que le fait gcc. (pour ceux qui connaissent le niveau d'optimisations très costaud de gcc)
Il en résulte un code final exécuté, en phase stabilisée, tout aussi rapide qu'un code écrit en C++ directement.
La grande différence se situe surtout au démarrage d'une application. En effet, au démarrage de l'application, la CLR n'a pas encore de code compilé, en cache, et donc il faut que la CLR se mette en branle puis lance la compilation JIT en arrière plan, ce qui prend du temps mais surtout des ressources, ce qui alourdit le démarrage de l'application et le temps nécessaire à sa stabilisation.
Il est évident que sur une application à durée de vie très courte, de l'ordre de quelques secondes, il vaut mieux développer en C++, car le temps que le compilateur de la CLR ne fasse son œuvre il est déjà temps de fermer l'application.
Mais sur des applications à durée de vie longue, donc supérieur à quelques secondes, cela devient tout à fait intéressant.
Au début la CLR compile avant tout le code qui est exécuté fréquemment, mais si tu laisse l'application tourner suffisamment longtemps, à terme toute l'application est compilée et mise en cache, et est donc aussi rapide que si elle avait été codée en C++ natif.
Tout dépend donc du besoin, des circonstances, des connaissances, et surtout de la plateforme de destination, plus que du temps d'exécution des cycles critiques.
Bluedeep pour DotNet, l'outil dont tu parle est un xenomorpheur de code, du nom de Xenocode32 qui compile directement le code en code natif, sans passer par les assemblies et le code IL, et donc lie statiquement toutes les dépendances à dotnet puisqu'il doit les compiler également.
La différence en utilisant xenocode, c'est que tu obtiens un exécutable sans avoir besoin du framework DotNet, mais qui en contrepartie est forcément "lourd". Sachant qu'au final la CLR utilise un compilateur JIT, il n'y a pas de gain réel à utiliser un xenomorpheur si ce n'est l'absence de dépendances, et surtout l'illisibilité du code résultant et le fait que le passer au débogage ne permettra pas de remonter aux sources originelles.
j'ajouterais que ngen.exe appliqué sur un exe .net managé (une fois celui ci arrivé à destination) permet de zapper le temps de compilation du jit tout en gardant les optimisations spécifiques à la machine
Pour ce qui est de la portabilité, encore une fois vous confondez un peu tout messieurs...
Le code écrit en C++/CLI pur avec EXCLUSIVEMENT du code managé, ou écrit en C#/VB.NET sera portable, plus ou moins, en le compilant sous mono sous linux.
Le code généré en C++ natif, n'est en aucun cas portable à moins de le recompiler lui aussi, et en aillant, pour cela, pris soin d'utiliser une écriture qui soit aussi bien comprise par gcc que par VC++, et avec pas mal de compilation conditionnelle sachant qu'il y a d'énormes différences entre la libc linux et la libc Windows, et je parle pas non plus de libc++, ou des usages directs des api Windows pour les sockets ou les threads qui n'ont absolument mais absolument rien avoir avec la gestion sous Linux...
Ici la portabilité n'est clairement pas gagnée... et ce que tu ai un code qui utilise ou non la RT VC++ qui je le rappel n'est pas un framework ni des runtimes à juste titre. En réalité si mes souvenirs sont bon, dans cette lib soit disant, runtime, on y trouve notamment tout le code de la libc++ qui n'est qu'une surcouche à la libc, et qui est donc une vulgaire librairie de code réutilisable, sans pour autant prétendre au titre de framework. Et à ce titre d'ailleurs il n'y a pas AUCUNE interprétation de code ou de pseudo-code, ou de code intermédiaire ou quoi que ce soit d'autre, mais bel et bien du code natif.
Pol63 exact pour ngen, intéressant d'ailleurs de le rappeler ici, puisque ce qui nous préoccupe, c'est les temps d'exécution :)
Donc guillaume07 à moins de besoins extraordinairement spécifiques tu peux tout à fait développer ton application en DotNet en utilisant C#, quitte à utiliser ngen après.
Mais bon, utiliser C++ pour gagner une nanoseconde par ci par là est tout aussi ridicule que d'écrire certaines routines en assembleur, avec quelques instructions asm directement, pour réaliser après tests d'exécution qu'une même routine écrite en C/C++ suffisamment bien écrite peut s'exécuter nettement plus vite car sur ce code, les compilateurs savent faire des optimisations, que tu ne penseras pas, ou ne saura pas faire dans ton propre code Assembleur.
Donc à moins d'un besoin encore une fois très spécifique, écrire en code natif pour cela, c'est un peu comme chasser le moustique avec un canon.