Discussion :

[thecat]

L'optimisation est importante je ne le nie pas, mais un compilo ferra beacoup mieux que toi et beaucoup plus proprement et surement ... regarde, rien que le garbage collector, c'est 'lourd' et couteux en ressource mais son interet est indeniable! L'inlining peut trés biens etre géré par le compilo (certains le font ...), la selection dynamique peut même être suprimé par le compilo quand elle est inutile pour accelerer l'appel de méthode et tu n'a toujours pas à t'en occuper!

Cepandant je suis d'accord que parfois, il faut "mettre les mains dans le combouis" mais pas pour ton application entierre!, pas de manierre systématique! beaucoup d'application tourne trés biens sans optimisation "qui vont biens car l'allocation en mémoire ce fait sur des addresse paire et patatipatata" regarde Java!

De plus, C# ce base sur une VM, qui est une abstraction de l'architecture sous-jacente; Reflechir à une optimisation pour une abstraction ? sa sonne un peu faux non?

Je ne reni en aucun cas l'utilité de l'optimisation, ni la nécessité! Mais elle doit etre exeptionelle pour le langage (surtout pour un langage moderne, objet, et tournant sur une VM), et ce langage ne doit pas obliger le développeur à y reflechir à chaque ligne de code.

[Traroth]

rien que le garbage collector, c'est 'lourd' et couteux en ressource mais son interet est indeniable!

Excellent exemple : Si tu programme correctement tes allocations et desallocations, ça ira beaucoup plus vite qu'avec un garbage collector.

ce langage ne doit pas obliger le développeur à y reflechir à chaque ligne de code

Comme dit, je ne suis pas un pro de C#, mais je ne pense pas qu'on en soit là

Je ne reni en aucun cas l'utilité de l'optimisation, ni la nécessité! Mais elle doit etre exeptionelle pour le langage

Le problème est qu'il est difficile d'optimiser en Java, en particulier en ce qui concerne la gestion memoire. C'est assez "piegeux", en fait. L'optimisation en Java, ça peut signifier utiliser plutot des variables locales que des variables de classes, par exemple. Pas très evident, à premiere vue.

[Clement Cunin]

Excellent exemple : Si tu programme correctement tes allocations et desallocations, ça ira beaucoup plus vite qu'avec un garbage collector.

Le principe du code manager, c'est justement de pas te laisser le controle de la memoire... Le "si tu programme correctement" implique qu'il existe une facon de pas le faire correctement... De plus les garbage collector actuelle sont largement optimisé et ne sont plus si couteux que ca !

Le problème est qu'il est difficile d'optimiser en Java

Oui, mais c'est pas toi qui optimise, c'est le JIT, chaqu'un sont boullot !
De plus, c'est pas très compliqué de comprendre que l'acces a des variables locales est TOUJOURS plus rapide que des variables de classes... pour le reste, laisse les compilo se debrouiller !

Ces remarques sont valables quelque soit le langage.

[Traroth]

Le "si tu programme correctement" implique qu'il existe une facon de pas le faire correctement

Exact. C'est comme ça pour tout. C'est pour ça que la programmation necessite un vrai savoir-faire et qu'on peut en faire son metier.

Oui, mais c'est pas toi qui optimise, c'est le JIT, chaqu'un sont boullot !
(...)pour le reste, laisse les compilo se debrouiller !

C'est ce type de raisonnement qui produit la qualité de code actuelle, souvent execrable en dehors du monde du logiciel libre (où les gens fignolent et optimisent, justement)

De plus, c'est pas très compliqué de comprendre que l'acces a des variables locales est TOUJOURS plus rapide que des variables de classes...

Pour le gars qui ne connait que les principes abstraits du langage, je pense que ça n'a rien d'evident.

[Causa Sui]

Je suis tout a fait opposé à thecat quand il dit qu'il ne faut pas utiliser C# (au profit de Java). Et cela pour plusieurs raisons. Notament celle mentionnée pas neo.51: pourquoi se fatiguer a faire des applications portables sur linux, solaris, unix et autres alors que le client ne demande qu'un programme windows? Pourquoi se fatiguer a utiliser des fonctions de Java alors que pour windows, celles de l'Api semblent mieux convenir.
Je crois que crois que thecat manque lourdement d'impartialité dans son attaque contre C#; il me semble qu'il vaut mieux regarder ce debat avec tempérance, et adapter sa réponse en fonction de ce qu'on demande au programme; il n'existe pas de "meilleur" language; il existe juste des languages qui conviennent mieu à une situation donnée!

[lunatix]

en tout cas, visiblement, C# n'est pas tellement plus rapide que java (voir moins rapide) pour les operations de base
http://www.tommti-systems.de/main-Da...enchmarks.html

faut aller jusqu'en bas de l'article

[bid0u]

même si mono est là, je vois pas pourquoi j'irais foutre du ms dans un système linux... on choisie linux par choix, c'est certainement pas pour apporter les bug ms avec nous

Euh... de quoi tu parles là??
il n'y a aucun code provenant de microsoft dans mono.

en tout cas, visiblement, C# n'est pas tellement plus rapide que java (voir moins rapide) pour les operations de base
http://www.tommti-systems.de/main-Da...enchmarks.html

faut aller jusqu'en bas de l'article

Nan là je suis obligé de réagir là parce qu'apparemment il y en a qui ne savent pas compter et lire anglais. Parce qu'en lisant l'article, C# bat java de loin. Et en plus, que vois-je?

they seems to use some lower precision for the sin, cos and tan functions

En plus de se faire sodomiser sec sur les temps de calcul, les opérations sur les virgules flottantes sous java sont imprécises et très lentes. Et ça veut être serieux avec ça.

Pour confirmer les choses, j'ai fait le test chez moi avec les valeurs maximales divisées par 10 pour ne pas attendre 5min devant l'ordi :
résultat :

Total C# benchmark time: 7529 ms
Total Java benchmark time: 19265 ms

Java prends 2,5 fois plus de temps sur ma machine. Ridicule.

[nicoo]

je prends le debat un peu au bond et donc je n'ai pas vraiment suivit les evolution mais ce que je peux dire cest que je suis autant java que c#. Je m'explique # a bel et bien copie sur java beaucoup de chose mais remarquer que java avec la futur version 1.5 fait de meme sur son omologue ex : les propriété en c# ...

DE plus c# plante mais pas autant que ce qu'on peut le dire. Par exéprience j'ai réalisé un serveur en java et en c# et je dois dire que en java fin de semaine je devais rebooter la machine car la machine virtuelle ne suivait plus et j'avais quand meme 1giga de ddr en ram donc ...

Avec mon serveur c# moins de probleme.

J'attends vos réaction tout en me faisant l'avocat du diable

[iolco51]

Nan là je suis obligé de réagir là parce qu'apparemment il y en a qui ne savent pas compter et lire anglais. Parce qu'en lisant l'article, C# bat java de loin. Et en plus, que vois-je?

Après avoir longuement parcouru l'article en question, je suis très étonné de voir que les performances de Java sont dans la majorité des cas supérieures au C# (les perfs sont en milli secondes, donc plus bas c'est mieux). Mieux vaut bien lire avant de réagir violemment.


Il est intérressant de noter la grosse faiblesse de la VM de sun pour les opérations mathématiques , et celle du C# pour la gestion des listes...

Ce ne sont que des tests très précis, et dans tous les cas je pense que C# offrira toujours des perfs meilleures sous windows ne serait-ce ce que parce qu'il nécessite moins de mémoire.
Je pense que cet écart sera d'autant plus grand que l'application va utiliser des composants graphiques, et là nous verrons que le C# est bien plus rapide que Java.

Enfin je ne pense pas que la peformance soit un critère déterminant, ni le C# ni le Java n'ont été conçus dans l'optique de performances fulgurantes, les langages compilés restent indétrônable, et sincèrement je m'en contrefiche un peu de savoir si mon programme Java va mettre 10ms de plus ou de moins à effectuer un calcul compliqué, car ce qui détermine avant tout les performances d'une application c'est la qualité du code du programmeur.


En fait un tel test permet surtout de comparer les machines viruelles.

En plus de se faire sodomiser sec sur les temps de calcul, les opérations sur les virgules flottantes sous java sont imprécises et très lentes. Et ça veut être serieux avec ça.

Un peu de tenue, de respect, et un langage chatié ne seraient pas du luxe, pourquoi es-tu aussi agressif?

Enfin :

they seems to use some lower precision for the sin, cos and tan functions

S'applique vraissemblablement uniquement à JET 3.5, qui offre malgré tout des performances similaires à C++ et C# sur le test trigo, encore une fois il faut lire le texte.

[sonialem2000]

il y a aussi ce bench:

http://www.osnews.com/story.php?news_id=5602

mis à part la trigo java s'en sort très bien...

le code pour .net n'est pas managed... mais il affirme qu'il y a pas de gain de performance... j'ai des doutes mais bon....

nicoo, c'est pas parce que ça plante chez toi que c'est partout pareil...si java serait aussi minable que ça et planterais autant, il ne serait jamais autant utilisé sur les serveur

faut pas s'attendre à des miracles de mono, c'est pas ms qui fait le boulot donc ils seront toujours en retard par rapport à eux et absolument rien ne garantie que ça sera pleinement fonctionnel avec ce qu' ms fait

[sonialem2000]

[quote="iolco51"]

Ce ne sont que des tests très précis, et dans tous les cas je pense que C# offrira toujours des perfs meilleures sous windows ne serait-ce ce que parce qu'il nécessite moins de mémoire.

bof bof c'est pas toujour vrai de plus... avec ce que windows nécessite en ram et surtout avec leurs prochain version... si on a pas de ram on peut pu faire grand chose

Je pense que cet écart sera d'autant plus grand que l'application va utiliser des composants graphiques, et là nous verrons que le C# est bien plus rapide que Java.

trop souvent les gens concoivent leur gui en java de façon incorrecte, ce qui amène a une gui lente...

ta plein de programme qui le montre telle que jajuk, jbuilder et cie

c'est aussi vrai pour le code des prog...
juste en retouchant une partie de prog de téléphonie qui utilisait énormément les string, les performances ont augement de 400%
merci les stringbuffer

ta de nombreux site expliquant les optimisants pouvant être fait en java...

faut regarder et savoir coder avant de critiquer

[blbird]

faut regarder et savoir coder avant de critiquer

Ce n'est plus savoir coder que de connaitre les bricolages nécéssaires d'un langage pour faire tourner à vitesse normale un programme.

Java n'est pas fait pour faire des interfaces graphiques. Ou plutôt les concepts utilisés dans Swing sont trop lourds.

Chaque langage a ses avantages et ses inconvénients. Aucun langage ne sait tout faire mieux que les autres. N'importe quel consultant technique sérieux vous le dira.

Concernant Swing, je dirais que ce framework est d'une lourdeur inimaginable, et d'une lenteur sidérente sur des machines actuelles. A force de vouloir trop bien faire (MVC à tout va), on en arrive a ne plus savoir rien faire correctement. Qui oserais comparer la VCL de Borland a Swing de Java? Je n'ose même pas en dire plus, préférant ne pas penser au centaines de lignes de codes nécéssaires pour faires des choses simples en Swing faites en quelques clicks de souris en VCL sous Delphi ou C++ Builder par ex, ni à la différence d'execution. Sans parler des bugs de JDK, toujours reglés ou améliorés dans le JDK suivant, ni même des invokeLater, qui sont une véritable plaie pour le débuguage et les performances.

Bref, jugement sans appel. Java très bien pour les wepApp. .Net fera-t-il mieux de ce côté là? Niveau applications et interfaces graphiques, je demande à voir ce que va nous faire .Net. En attendant, je resterais sur Delphi 8 .Net et la VCL qui tourne tellement bien depuis tant d'années.

[iolco51]

trop souvent les gens concoivent leur gui en java de façon incorrecte, ce qui amène a une gui lente...

ta plein de programme qui le montre telle que jajuk, jbuilder et cie

c'est aussi vrai pour le code des prog...
juste en retouchant une partie de prog de téléphonie qui utilisait énormément les string, les performances ont augement de 400%
merci les stringbuffer

ta de nombreux site expliquant les optimisants pouvant être fait en java...

faut regarder et savoir coder avant de critiquer

Je ne critique pas, mais j'enonce une realite.

L'API Swing est tres bien pensee, bien documentee, et c'est un regal de developper des applications avec.

Mais optimisations du programme ou non, une interface graphique en swing sera toujours bcp fois plus lente qu'une interface native, c'est lie a l'architecture de swing, et au choix de sun (que je trouve judicieux) de ne (presque) pas utiliser de composants natifs.

On a beau la critiquer, swing reste une excellent librairie destinee aux interfaces graphiques, aux performances tout a fait honnete, avec un look and feel pluggable, une tres bonne architecture (MVC entre autres), et 100% portable avec ca. On ne peut pas etre bon partout.

[stephane eyskens]

Une chose n'a pas été dite sur la question de la portabilité. On dit que C# devrait à court terme être portable sur Linux. Seulement, il y a linux et linux (Suse, Redhat, Mandrake,RHEL3...et j'en passe)

Et une version de linux n'est pas du tout l'autre

Je le constate de plus en plus souvent car mon entreprise a introduit sur le marché(il y a + de 10 ans) un spooler d'impression hyper complet portable sur TOUTES les plateformes sans exception (comme ce spooler est certifié par SAP, faut suivre SAP).

Mais celles qui nous posent régulièrement des problèmes sont les Linux.

Linux est hyper dur à suivre, les kernels changent tout le temps... A chaque release de Redhat, des problèmes apparaissent. Bref, c'est pas une mince affaire de suivre Linux. Les systèmes Unix eux sont plus beaucoup plus homogènes (AIX, HP,Solaris). Microsoft devrait peut-être d'abord s'attaquer à Unix plutôt qu'à Linux.

[alexrtz]

Une chose n'a pas été dite sur la question de la portabilité. On dit que C# devrait à court terme être portable sur Linux. Seulement, il y a linux et linux (Suse, Redhat, Mandrake,RHEL3...et j'en passe)

Linux est hyper dur à suivre, les kernels changent tout le temps... A chaque release de Redhat, des problèmes apparaissent. Bref, c'est pas une mince affaire de suivre Linux.

Je ne vois pas en quoi le changement de noyau peut influer négativement sur le portage du C#.
J'ai installé la même jvm sur des 2.4 et 2.6 et je n'ai eut aucun problème.
Sun n'a pas de problème majeur avec ça.
Et sur le fait que C# soit portable sous Linux à court terme j'ai des doutes.
De toute façon, la majorité des Linuxiens sera plus que réticente à coder en C#.

[os9]

Personnellement, j'ai répondu Java.
D'abord, je pense qu'un bon programmeur doit être ouvert sur tout les langages. On ne sait jamais, parfois on découvre un langage qui nous servira mieux.

Pour justifier mon je dirai que le Java est un langage complet. La communauté Java offre une multitudes d'outils et de plate-forme qui répondent à nos besoins (J2EE, J2ME,...) ainsi que des IDE de performances inégales.

Je vois que le C# apporte peu (pour ne pas dire il n'apporte presque rien) au Java. On a Java, il répond à nos besoins alors pourquoi le C#?
En terme de gestion de temps et de mémoire, je reconnais que le C# présente un plus par rapport à Java, mais par rapport à d'autre avantages (richesse de la bibliothèque Java,...), on peut s'en passer.

Voilà mon avis, merci à tout.

[sonialem2000]

je rajoute une chose, java a contribué je trouve à apporter de nombreux outils de qualité au développement, des méthodes de travail....

par exemple niveau patron, on cherche sur le net et la plupart du temps, tout est donné pour java

[Keihilin]

Et sur le fait que C# soit portable sous Linux à court terme j'ai des doutes.

...et pourtant Mono est maintenant là...et ça marche plutôt bien.
Mono n'est pas "en retard" d'un train par rapport aux avancées du framework d'origine, et cela augure plein de bonnes choses pour l'avenir.

De toute façon, la majorité des Linuxiens sera plus que réticente à coder en C#.

Ah bon, et pourquoi ? Par pure réaction anti-microsoft primaire et idiote ?

[lunatix]

...et pourtant Mono est maintenant là...et ça marche plutôt bien.

moué, enfin les winforms ne sont pas supportées et ne le seront probablement jamais completement, sans parler des problemes de brevets sur les api ADO.net, etc... mono est pas franchement capable de faire tourner tout ce qui est .net. Java a une vraie politique de portabilité, contrairement a .net

Ah bon, et pourquoi ? Par pure réaction anti-microsoft primaire et idiote ?

peut etre parce que microsoft pense que l'open source gpl est un cancer

[alexrtz]

Ah bon, et pourquoi ? Par pure réaction anti-microsoft primaire et idiote ?

Regarde ce qui a été fait au niveau technique et au niveau de la politique de communication menée par Microsoft jusqu'à maintenant et tu comprendras que cette réaction est loin d'être primaire et idiote.