Un programme en C# est-il aussi performant qu'un prog en C++ ?

Un programme en C# est-il aussi performant qu'un prog en C++ ? - C#/.NET managed - Programmation

Marsh Posté le 07-12-2003 à 22:59:02    

je n'arrive pas à trouver des solutions claire à mon problème.
Je développe en java, et j'ai des anciennes connaissances de C++.
 
Afin d'être plus performant je pensais coder mon appli en C# (du fait de ses similitudes avec le Java).
 
Pour info, l'appli en question va être une gros programme de gestion (gestion en temps réel d'informations, système client/serveur, facturation, ...).
 
Pour des raisons de performances logicielles (rapidité d'exécution et consommation machine), le C# est-il un bon choix par rapport au C++ ?


---------------
༼ つ ◕_◕ ༽つ
Reply

Marsh Posté le 07-12-2003 à 22:59:02   

Reply

Marsh Posté le 07-12-2003 à 23:08:25    

oui c'est un moins bon choix. mais faut voir ou t'es à l'aise

Reply

Marsh Posté le 07-12-2003 à 23:14:27    

Taz a écrit :

oui c'est un moins bon choix. mais faut voir ou t'es à l'aise


je serais plus à l'aise en C#
 
Mais priorité est donnée aux perfs de l'application, elle doit pouvoir tourner efficacement sur des confifs plutôt anciennes (Pentium II mini). Si tu me dis que C# est moins performant est consomme + de ressources, dans ce cas, je me remettrai au C++ :jap:


---------------
༼ つ ◕_◕ ༽つ
Reply

Marsh Posté le 07-12-2003 à 23:26:33    

je connais pas vraiment C#, mais  connaissant bien le C++, je pense vraiment pas que C# soit plus rapide.

Reply

Marsh Posté le 08-12-2003 à 00:57:40    

c'est toujours pareil, les possibilités d'optimisation ne sont pas les mêmes. Le C# est optimisé plutôt en ligne, C++ plutôt spéculativement.
 
on peut largement penser que .net comme java vont avoir du mal à rejoindre C++ : ils sont partis avec beaucoup de retard (vu qu'avant java tout le monde se fouttait des VM) et peu de moyens (développer une VM ou un CLR avec une visée de performances est un gros projet).
 
Par contre, en continuant la voie de la sécurité d'exécution, incidement on ouvre une autre voie : celle de l'optimisation aggressive. Plus on peut prouver de choses sur un programme et plus on peut le transformer et le réécrire. Une des grosses faiblesses de C++ c'est que son système de types complètement transpercé (mais aussi la notion de pointeur arbitraire) rend l'analyse formelle difficile (en gros le système de type statique ne prouve rien sur les types, il faut tout revérifier derrière, car un simple cast fout tout en l'air).
 
Au-delà de la réécriture aggressive, une nouvelle mode se profile : celle de la simplicité, o'caml obtient de très bons résultats, alors que l'optimisation est basique (hum heu c'est pas de rigolot non plus hein) et qu'il y est fait usage d'assez peu de réécriture (ça joue surtout sur le boxing, la propagation des constantes, l'inlining basique, mais pas d'évaluation partielle par exemple). De même Haskell (ghc) pose des types primitifs sur la pile (au prix d'un "équipement" pour le GC plus complexe), propage les constantes, et inline mais pas non plus d'évaluation partielle poussée, de déroulage de boucles etc.
Même en C++ on parle de plus en plus de dérouler les boucles à la main par évaluation partielle (avec des templates et tout le cortège), de structurer le programme comme on veut qu'il soit exécuté, plutôt que de s'en remettre au compilo.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 08-12-2003 à 01:14:48    

nraynaud a écrit :


Même en C++ on parle de plus en plus de dérouler les boucles à la main par évaluation partielle (avec des templates et tout le cortège), de structurer le programme comme on veut qu'il soit exécuté, plutôt que de s'en remettre au compilo.

je crois que c'est la base de tout. Quand on fait de la métaprogrammation template, la phrase clef est "think you're a compiler"

Reply

Marsh Posté le 08-12-2003 à 02:00:39    

Un bon code C# sera certainement plus rapide qu'un mauvais code C++. Le facteur humain n'est pas à négliger. C# offre la possibilité de pouvoir, une fois que tout marche, commencer à optimiser des bouts à l'aide de pointeurs (ça ne va pas sans rappeler le C des fois) en mode unsafe, et si ça ne suffit pas, de réécrire en C++ ce qui ne va pas et de l'intégrer au code C# existant. L'optimisation est quelque chose de difficile qui requiert une bonne connaissance du langage et de l'envirronement d'exécution (bien comprendre .net et tout ce qu'il y a dessous). Y'a des exemples de gain de 1 à 100 de vitesse de traitement en C# en passant par des pointeurs.


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
Reply

Marsh Posté le 08-12-2003 à 02:23:59    

le graal du pointeur !
Les utilisateurs des produits Microsoft n'ont décidément pas fini de me faire rire. Quand je pense qu'ils ont des gens parmis les plus savants du monde en informatique dans leurs labos chez MS Research !


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 08-12-2003 à 02:28:09    

l'optimisation, c'est pas le truc qui permet d'accélérer un traitement sans altérer ses résultats et sa sécurité d'exécution ? [:dawa]

Reply

Marsh Posté le 08-12-2003 à 02:42:48    

> Pentium II mini
Voulah! deja que certains windows se vautrent avec ce type de config...
Donc si tu as un windows assez ancien (pre W2K) a supporter, ce que tu ecris en C# tournera t'il dessus??
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le 08-12-2003 à 02:42:48   

Reply

Marsh Posté le 08-12-2003 à 02:46:59    

ouais ca tourne sur w98 je crois, pas en dessous
par contre niveau vitesse je parierais pas bpc la dessus....

Reply

Marsh Posté le 08-12-2003 à 02:54:28    

C'est tout en 32 bits win98? je me souviens plus. Parce que j'ai pas souvenir que la CLR soit particulierement adaptée au 16 bit et autres joyeusetes.
A+,


Message édité par gilou le 08-12-2003 à 02:55:04

---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le 08-12-2003 à 04:02:07    

ouais, on peut mettre un processus 32 bits en mode protégé sur win 98. J'irais même jusqu'à dire que mettre autre chose est une galère.


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 08-12-2003 à 08:17:32    

Win9x est pseudo 32 bits. Ca ressemble à du 32 bits pmode préemptif, ça en a le goût, mais ça en est pas. La majorité de l'API Win32 sous ces OS effectue le travail nécessaire pour appeler Win16, directement issue de Win3.1
A partir de 98 c'est un peu mieux car les drivers 32 bits se généralisent, mais bon, on a beau mettre des atèles, quand on a des os en verre... (tiens elle est pas mal celle là, je vais me la noter :))


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
Reply

Marsh Posté le 08-12-2003 à 11:49:18    

nraynaud a écrit :

ouais, on peut mettre un processus 32 bits en mode protégé sur win 98. J'irais même jusqu'à dire que mettre autre chose est une galère.

Oui (j'ai maitrisé le dev sous windows, de windows 2.0 (!) a Win95 et de Win2K a WinXP, mais j'ai laisse tomber le dev sous Win98 et WinMe), c'est au niveau de certains passages de parametres que je me posais la question (certaines API ayant tendance a tronquer des parametres lors de la translation [interne] 32bit->16bit si mes souvenirs sont bons, ou a ne pas etre implementées du tout, sauf par un stub qui ne generait pas d'erreur [cas de certains appels en mode unicodes] )
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le 08-12-2003 à 22:39:09    

Rapidement :
-> Sous 98, à mon humble avis, outre le problème d'être ou non du vrais 32 bits, il va se poser un énorme problème de performances. En effet, convertir des appels 32 bits en appel 16 bits, puis reconvertir le résultat en 32 bits pour fonctionner, ça prends beaucoup de temps.
Donc clairement, il faut oublier le C# sous 98, à moins de se cantonner à HelloWorld (l'exemple hein, pas le gus ;))
Par contre, il y a NT 4.0, qui tourne parfaitement sur un PII, et qui est full 32 bits. WinNT est en lui-même plus lent que Win98, mais son support de .NET étant meilleur, il devrait bien mieu s'en sortir.
 
Mais bon, dans tous les cas, faire tourner du P-Code sur des vieux chameaux comme ça, c'est pas vraiment ce qu'il y a de mieu.
 
Je pense que tu devrais commencer par faire quelques tests d'agressivité sur les machines actuelles avant d'aller plus loin. Mais au lieu de passer au C++ si le C# est trop lent, je te conseille de faire la pression nécessaire pour mettre ces vieilleries au rebus. Ou alors tu les passes sous Linux. Vu l'état d'avancement du support de .NET sous Linux, d'ici que tu aies fini, il devrait être tout à fait utilisable ;)

Reply

Marsh Posté le 08-12-2003 à 22:42:16    

je déconne à moitié, mais entre l'arrêt du support (s'il en a un jour mérité le nom) et les recommandations à la hausse, on est là dans la logique bien connue de Microsoft et de ses amis les constructeurs -> nouveau logiciel = nouveau matériel

Reply

Marsh Posté le 08-12-2003 à 22:51:03    

Taz a écrit :

je déconne à moitié, mais entre l'arrêt du support (s'il en a un jour mérité le nom) et les recommandations à la hausse, on est là dans la logique bien connue de Microsoft et de ses amis les constructeurs -> nouveau logiciel = nouveau matériel


ouais ben... dénonce pas trop fort non plus ;)
 
parceque la dernière fois que j'ai trouvé que mon P100 avec Win95 ramait, j'ai mis une débian dessus, avec un GUI le plus léger possible (chais plus ce que c'était, ça gérait qu'un bouton de la souris, pis 4 couleurs... pas d'icônes, juste des fenêtres que tu lancais en ligne de commande... le truc le plus limité possible quoi...)
Bah j'ai réinstallé Win95 au bout de 20 minutes...
Donc Linux, aussi léger soit-il, est lui aussi de plus en plus gourmand. Son seul avantage à ce niveau, c'est qu'au niveau gourmandise, il est très en retard sur M$ (au moins 3 ans) donc permet d'utiliser des machines qui ne sont plus de première jeunesse dans des conditions honorables... Mais pour les vieux tromblons, bah même Linux s'avère être une usine à gaz.

Reply

Marsh Posté le 08-12-2003 à 22:53:35    

J'ai WindowsXP, VS2003, Office2003 et un Atlhon500 300Mo de RAM. Ca marche très bien. Je vais changer en Janvier mais c'est surtout pour les jeux, et parce que j'en ai l'occasion. Linux n'étant pas concerné par cela, je comprends qu'on y vive heureux avec un pII :p


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
Reply

Marsh Posté le 08-12-2003 à 22:56:38    

Citation :

c'est qu'au niveau gourmandise, il est très en retard sur M$ (au moins 3 ans)


[plaisirperso][donotreply][troll]Ben c'est en général qu'il a 3 ans de retard[/troll][/donotreply][/plaisirperso]


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
Reply

Marsh Posté le 08-12-2003 à 22:58:06    

HelloWorld a écrit :

Citation :

c'est qu'au niveau gourmandise, il est très en retard sur M$ (au moins 3 ans)


[plaisirperso][donotreply][troll]Ben c'est en général qu'il a 3 ans de retard[/troll][/donotreply][/plaisirperso]


[QuiCaMoi?ChuisPuLà]Tu m'enlèves les mots de la bouche[/QuiCaMoi?ChuisPuLà]

Reply

Marsh Posté le 08-12-2003 à 23:00:11    

MagicBuzz a écrit :

(...) je te conseille de faire la pression nécessaire pour mettre ces vieilleries au rebus.
(...)


je me vois mal obliger une 100aine de sociétés  de changer de parc informatique :/


---------------
༼ つ ◕_◕ ༽つ
Reply

Marsh Posté le 08-12-2003 à 23:03:28    

oui et non. on est d'accord que pour l'interface graphique, linux a des exigences plus hautes. pour le reste un linux se debrouille très bien sur un tout petite bécane. par contre, on n'apprécie pas de devoir changer de bécanes entre 2 windows, alors qu'ils sont identiques (9x en particulier)

Reply

Marsh Posté le 08-12-2003 à 23:10:49    

Sinon, j'ai une question bête...
 
=> Si j'ai bien compris, tu comptes faire un mini-ERP. C'est ça ?
 
Alors dans ce cas, généralement, on tourne en client/server.
 
Pour le serveur, qui devrait être une bonne machine je pense, C# ne sera pas un souci. Et même dans ce type d'environnement, à moins que tu t'amuses à recompiler chez claque client, le C# devrait mieu s'en sortir (le C# s'adaptant à la volée à l'environnement matériel dans lequel il évolue).
 
Donc tu peux faire un serveur en C#, ce qui me semble un très bon choix, puisqu'à la fois le langage et l'IDE VS.NET sont tout à fait adaptés pour les gros projets.
Et faire le client dans un langage plus léger, puisqu'il devrait se cantonner à afficher des informations récupérées sur le serveur.
 
Sinon, pour bosser actuellement pour GE Medical Systems Europe Accessories and Supplues (ouf!), gros tromblon avec environ 1000 personnes connectées toute la journée sur le serveur, avec un total au moins 5 fois suppérieur d'utilisateurs, j'ai pu voir différents ERP et leur politique actuelle.
 
GENERIX. C'est un petit ERP français, actuellement utilisé par le siège, qui est en France, et donc par tout le monde.
 
Ils ont une version telnet qui offre de très bonnes performances (mais une interface à faire vomir un troll), et une version "client/server" qui m'a fait pisser de rire (3 Go sur le disque, en fait, elle se connecte directement à la base et fait tous les traîtements elle-même...)
 
Donc, GENERIX, du haut de cette erreur a décidé de rectifier le tir, et ses dernières versions "client/serveur" sont sous forme d'un serveur Web et d'un site, couplé à quelques activeX qui s'occupe de l'éditique en local ou autre. Ainsi, aucun problème de performances sur les postes clients.
 
Oracle Solutions. Ils sont en train de commencer à percer, et GE Corporate est en train de planifier la migration de toutes ces branches sous ce nouvel ERP.
Lui aussi se manifeste sous forme d'un serveur Web, avec une interface client bourrée d'applets Java. (par contre, lui il est vraiment merdique, et les applets foutent à genoux mon PIV 2.4 !)
 
Enfin... Je pense qu'il est à considérer ce mouvement actuel. Le plus grand ERP après SAP, et un autre (plus certainement d'autres que je ne connais pas) se tournent vers le système 100% centralisé d'une appli intranet. C# permet de faire des pages web. Je pense donc que c'est à considérer comme solution.
 
En effet, si tu dois déployer ta solution dans des environnements hétérogènes, alors il faut prendre en considération notamment le fait que les utilisateurs ayant des machines rapides n'apprécieront pas que tu sacrifies une partie des fonctionnalités/ergonomie/présentation afin d'alléger la charge pour les personnes qui ont des PC à pédales.


Message édité par MagicBuzz le 08-12-2003 à 23:13:13
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed