Artisan Numérique » Java, C# et C++, performances comparées (verison 3)

Java, C# et C++, performances comparées (verison 3)

Je croyais en avoir fini avec les benchmarks, mais vu le nombre de questions et demande que j'ai reçu en privé et commentaires, il m'a fallut remettre rapidement cela. Alors il s'agit toujours des mêmes types de tests mais qui ont un peu évolué en qualité de code. Mais surtout, cela inclus beaucoup plus de plateformes (windows, ms.Net, etc.).

Préambule

L'objectif ici n'est absolument pas de lancer un grand débat théologique mais de tenter de se rendre compte au mieux des performances réelles de chaque plate-forme de développement. Il n'y a pas de langage meilleur que d'autre et chacun a son usage, même le Lisp, c'est dire...

Le seul intérêt de ce type de test est avant tout de prendre conscience des faiblesses de la plateforme que l'on utilise ou d'en choisir en connaissance de cause lorsque ce choix est encore libre. Après il ne s'agit que d'un ordre d'idée. Tout benchmark est par essence faux car l'observateur influe forcement sur son sujet. De plus les tests peuvent avoir des résultats différents d'une architecture physique à l'autre, gardez cela en tête.

Protocole

Les tests sont à l'origine codés par Christopher W. Cowell-Shah puis ont été modifiés par Thomas Bruckschlegel, puis enfin par moi-même pour finalement ne plus ressembler à rien de tout cela.

Ils sont encapsulés dans le même framework que mes précédents benchmarks (rejoués 10fois, etc..).

Les tests sont lancés dans leur propre processus. Deux tests, qu'ils soient de même type sur deux plateformes, ou issus du même test répété, n'utilisent jamais les mêmes fichiers (tentative de réduction de l'effet "cache").

Chaque test est répété 10 fois de suite, le meilleur score est retenu. Ce score est ensuite inversé puis mis à l'échelle de l'architecture de référence, Java 6. Cela donne la formule score= 100* (1/temps)/(1/temps_reference). Ainsi un score de 100% indique que le test est aussi rapide que son équivalent Java 6. 200% deux fois plus rapide et 50%, deux fois plus lent.

Plateformes testées

La plate-forme physique de test est un Q6600 2go de RAM avec un Windows XP SP3 et un Mandriva 2008.1 (kernel 2.6.24). Dans les deux cas le maximum de service a été fermé pour ne pas influencer les résultats. Dans les deux cas, le disque utilisé pour les entrées-sorties est le même, un disque seagate SATA 500G formaté en EXT3.

Les plateformes de développement testées sous Linux sont :

g++ version 4.2.3 avec les options -pipe -fomit-frame-pointer -O3.
gcj 4.3.0 avec les options -pipe -fomit-frame-pointer -O3.
Java 1.3.1 sp19.
Java 1.4.2 sp13.
Java 5 1.5.0 sp14.
Java6 1.6.0 sp4 (l'architecture de référence).
Java7 1.7.0.
Mono 1.2.6.
IKVM 0.36.0.5.

Et pour windows :

g++ MinGW 3.4.5 avec les options -pipe -fomit-frame-pointer -O3.
gcj MinGW 3.4.5 avec les options -pipe -fomit-frame-pointer -O3.
Java6 1.6.0 sp6.
Mono 1.0.1.
MS dotNet 3.5.

Les sources

Les sources sont disponibles ici.

Sinon, vous pouvez avoir directement accès à la documentation du code :

Les Threads

C'est un nouveau test que j'ai créé pour Java et C#, pas pour CPP, je n'ai pas eu le courage alors si ça tente quelqu'un...

Basiquement cela consiste en un anneau de N threads (120 dans le test car java/windows explose à plus...). Un signal (entier équal à 1000xnombre_threads) est injecté dans le premier thread qui l'envoie à son voisin en le décrémentant. Lorsqu'un thread reçoit une valeur négative, il meurt. Le temps est donc celui qui permet de construire les 100 threads, faire circuler le messages 1000 fois et de faire nourrir tous les threads. Le test utilise massivement les blocks synchronisés pour attendre les messages et se réveiller à leur arrivée.

Le meilleur dans ce domaine reste étrangement le JDK v3. Les performances dans ce domaines avaient baissées jusqu'au jdk v5 (le pire) pour remonter jusqu'au 7 qui aujourd'hui est à peu prés aussi rapide que le v4.

Mono lui est mauvais dans ce domaine, sous Linux comme sous Windows. Et vu la simplicité du test, je doute que cela vienne des sources. Ceci dit, sous Windows, le threading est globalement plus lent que sous Linux même aidé par les 4 cores du processeur.

GCJ se débrouille aussi bien qu'un JDK standard mais IKVM lui est à la ramasse, sûrement un problème d'implémentation car ses performances devraient au moins être en phase avec Mono.

Les nombres

Les entiers "courts"

Côté JDK, le travail sur les entiers s'est amélioré avec la version 5 et cela s'est globalement maintenu ainsi. Les machines .net sont elles un peu en retrait, au niveau des anciens JDK 3 et 4.

Après les résultats sont globalement homogènes entre 80 à 110%. Le meilleur temps étant pour GCJ sous Linux et le plus mauvais pour GCJ pour Windows. Ce qui n'est pas si choquant que cela vu que les versions testées ne sont pas les mêmes.

Les entiers longs

Là c'est clairement le natif qui l'emporte avec cependant un bonne performance de MS.Net et Java sous Windows. Mono est lui comme toujours en retrait sur les deux OS.

Côté JDK, Iced-Tea remonte la pente sous Linux pour obtenir un score très proche de celui du JDK 6 sous Windows.

Les doubles

Ici nous avons trois groupes. Les plus performant qui sont étrangement les JDK 5 et plus, et MS.Net. Mono est encore en retrait (et IKVM pareil), au niveau des veilles VM (JDK 4 et moins).

Chose étonnante, le natif n'est pas si efficace que cela sur ces tests, peut-être lié à une implémentation des doubles utilisée par gcc/gcj.

Trigonométrie

Une des bêtes noires de Java même si en constante amélioration. Et GCJ n'apporte cette fois pas grand chose. Les meilleurs dans ce domaine sont en premier le CPP, ensuite les .Net.

Entrées-Sorties

Sur fichier

Là c'est pas ma peine de chipoter, .Net deux fois meilleur que Java, c'est difficile à nier. Et pourtant je vous assure que j'ai essayé d'aider le code par tous les moyens possible mais le résultat reste peu ou prou le même.

Pour le reste, même les versions natives n'arrivent pas à dégommer MS.Net et sont à peu prés au même niveau de performance que les autres. J'aurais pu croire que mon protocole était le fautif si Mono n'avait pas eu les mêmes résultats que ces voisins. J'ai d'ailleurs sorti IKVM du test tant ses performances étaient ici mauvaises.

Itératif

Boucles imbriquées

Encore une excellent performance de GCJ qui est ici dans son coeur de métier et combat fièrement au côté de GCC.

Côté JVM, j'aime bien ce test de 6 boucles imbriquées car il montre comment Hotspot se débrouille pour avec les traitements itératifs. On voit bien l'évolution de ses performances au fur et à mesure du temps. A noter qu'il a du se passer quelque chose dans cette VM du JDK 6 car les performances sont un peu moins bonnes à partir de là.

Pour la concurrence le meilleur reste définitivement gcc. Mono est une fois de plus dans le décors mais pas plus que MS.Net cette fois qui sont les grands perdants de ce tests si l'on exclue les JVM obsolètes.

Tri

Toujours des boucles, mais cette fois pour faire quelque chose de sérieux : trier un énorme tableau (1 million de lignes).

Mono y est un peu moins mauvais que d'habitude à ce jeu et l'on constate que sur ce genre de "cas réel", on est pas si loin de GCC qui reste cependant 50% plus rapide que le pool des VM.

Notez que GCJ est ici aussi efficace que GCC, ce qui est logique vu son métier de compilateur natif qui ici n'utilise aucunement les librairies sous-jacentes. C'est sur ce genre de traitement que GCJ montre tout son interêt.

Ce que l'on notre aussi c'est qu'IKVM obtiens les mêmes scores que Mono. Ce qui là aussi est logique car généralement IKVM doit faire appel à une traduction du JDK, ce qui n'est ici pas le cas. En traitement pure, c'est bien Mono qui est le goulot.

Multiplication de matrice

Cette fois on mélange le tout boucles, tableaux et calculs pour une simple multiplication de deux grosses matrices d'entiers.

Je passe encore Mono qui décidément est bien malade sous Linux comme sous Windows où pourtant j'ai utilisé la toute dernière version. Les meilleurs ici sont clairement les natifs même si GCJ déçoit un peu en peinant sûrement sur l'allocation et la gestion des grands espaces mémoire ou encore le calcul sur les entiers.

Notons enfin que MS.Net est ici un peu plus rapide que Java mais surtout que l'on a clairement perdu de la performances en montant de JDK. Ce qui est d'autant plus incompréhensible que le calcul sur entiers s'est lui amélioré et que les boucles sont elles aussi plus performantes. D'où l'intérêt de ce genre de tests plus "vraie vie".

Concaténation de chaînes

Gagnants incontestables, les natives. Après viennent les machines .Net pour Windows qui se débrouillent un peu mieux que Mono sous Linux.

Pour Java, la performance d'IKVM semble indiquer que StringBuffer n'est pas une bête de vitesse, tirant vers le bas toutes les version Java, GCJ compris.

Structures de données

Tables de Hash

Là j'ai pas mal remanier le code C++ qui était la cause des mauvais résultats dans la précédente version du benchmark. Maintenant tout devient plus logique et les version natives sont en tête.

Cependant, MS.Net sous Windows et Mono sous Linux sont dans ce domaine assez brillant et frisent la performance que GCC obtient sous Linux. Heureusement le JDK 7 semble se relever et n'est pas si loin de ces meilleurs scores.

Vecteur

Là, tous aussi bon, ou tous aussi mauvais, je ne sais pas bien dire. Mais seule MS.Net semble se distinguer ici, mais dans le mauvais sens du terme. Et c'est bien lui le problème puisque Mono sous Windows ne semble lui pas souffrir plus que cela.

Divers

Exceptions

Gagnant, GCC sous Windows qui explose la version Linux qui est pourtant plus "évoluée". GCJ, IKVM et MS.Net sont eux les tristes perdants avec des scores juste nuls. Notons enfin une amélioration des performances de JDK7 dans ce domaine qui frise les X2.

Ceci dit, un test sur les exceptions vaut ce qu'il vaut dans la vraie vie où l'on n'est pas sensé en générer un millions à la volée...

Temps de démarrage

Ca c'est un test que j'ai un peu changé dans sa philosophie. En effet, en devant passer sous Windows, je me suis heurter au problème du vidage du cache disque et je n'ai absolument rien trouvé sous ce drôle d'OS pour faire une chose aussi simple. Du coup j'ai changé mon fusil d'épaule en relançant, sans vider le cache, le test 5 fois de suite et en prenant le meilleur temps. Ce résultat donne donc quelque chose de très stable indiquant les temps de chargement d'une plateforme "encore chaude".

Et même dans ce nouveau cadre Java reste le plus lent de tous, et IKVM est encore pire. Le seul qui arrive à descendre aussi bas est Mono sous Windows... MS.Net sous Windows en revanche obtiens de très bon scores en démarrant 3 fois plus vite que Java. Je passe le cas des natives qui sont clairement les plus rapides, évidemment...

Alors oui Java teste plein de chose en plus, valide chaque classe, décompresse l'énorme rt.jar,etc.. Et encore oui, avec le système de la 6, ce temps est amélioré mais franchement, c'est toujours pas le top. Une longue seconde pour une "application" qui fait 5 kilo, c'est juste mauvais. Et pour 500mo ? Euh, ça s'appelle Eclipse

Alors je ne sais pas, il est peut-être temps de larguer le concept de .jar, de faire comme Mono avec ses assemblies, d'ajouter une option qui shunte les vérifications au démarrage, bref, faut faire un truc car si aujourd'hui on trouve Java lent, c'est psychologiquement lié à ce point là. Ce n'est certes pas un point crucial d'un point de vue technique mais c'en est clairement un d'un point de vue image.

Et petite surprise, le problème ne s'est pas amélioré avec GCJ qui ne démarre qu'un peu plus vite que ses sœurettes.

Résumé

Du JDK 3 au JDK 7, les performances n'ont fait que monter pour arriver à des performances 1.5 fois inférieures à celles d'un code équivalent natif. Donc première chose, oui Java c'est plus lent que du C++, malgré tous les benchmarks comiques que j'ai pu voir dans ce domaine. Alors maintenant il serait aussi intéressant de tester C++ avec un garbage collector histoire d'avoir une vision vraiment iso-fonctionnelle des choses. Mais que ce soit toujours plus rapide n'est pas tellement surprenant. Ce qui est intéressant en revanche c'est que ce n'est pas tellement plus rapide que certains autres voudraient le faire croire. Un facteur 1.5 pour la différence de confort et de maintenabilité, je ne trouve pas cela très cher payer.

Maintenant de .Net à Java, la performance reste du côté de Java malgré les très bons score de MS.Net sur les IO. Notez que j'ai exclus du résumé les Exceptions (pas assez pertinent dans la vraie vie) et les temps de démarrage. Mono est quant à lui un peu en retrait côté performance mais pas si loin de MS.Net. IKVM quant à lui est encore jeune et de toute façon destiné à faire coopérer du code java et C#. En effet, rien ne prouve, et même au contraire, que la CLR soit plus rapide que la JVM.

Pour ce qui est de GCJ c'est un peu décevant sur la globalité et tend à prouver qu'une bonne partie de la "lenteur" de Java ne tiens pas plus à la JVM qu'aux librairies.

Enfin, désolé pour les Pro-Windows ou les Pro-Linux mais globalement sur ces tests, les scores se valent d'une plateforme à l'autre.

Conclusions

En tout cas la mouture 6 de Java est clairement une réussite en terme de performance. Et la 7 est plus que prometteuse même si Iced-Tea est encore un projet en progression. Et les conclusions des tests, même s'ils ne sont que des tests à prendre avec toutes les précautions d'usage, prouvent que pour un confort largement supérieur (question de goût ?, Java est loin de se laisser aussi distancer que la légende veut bien le faire croire, même par du code en C, compilé de manière optimisée.

Commentaires

Il serait intéressant aussi de tester le même traitement dans d'autres langages...comment Delphi for Win32, Delphi for dotNet et Kylix (aka Delphi for Linux)

Ce serait une bonne idée en effet, intéressé pour écrire les tests en pascal object ? Il serait aussi intéressant de lancer ces tests sous WIndows, ne disposant que d'une VM, je ne suis pas sur que je puisse le faire dans de bonnes conditions.

Salut

Très intéressant, nous faisons des tests similaires et j'ajouterais qq remarques:

1/ Sur ce genre de test l'option -server de java est indispensable pour avoir les perf max (d'ailleurs sur les archi actuelles (dual core) même en mode GUI c'est plus interessant).
2/ Pour comparer avec C++, ta procedure de test contient-elle un certain nombre de run pour permettre au JIT de compiler les classes avant les mesures?
3/ L'option -O3 de gcc est fortement déconseillée, en effet il optimise tellement ... que parfois les resultats ne sont plus bon !, L'option -02 est réputée pour être la plus stable.
4/ Il faudrait comparer mono avec un run sur une CLR win32 sur la meme machine

Cdlt
Christophe (aka ouaibsky)

Bonjour,

Je vais répondre point à point si tu veux bien

1/ Yep, je suis d'accord, l'option -server est très efficace et souvent oubliée.

2/ Non, absolument pas, c'est même une marge d'amélioration des performances notable (sauf si l'on applique le 1/ ce qui revient au même). Mon idée était déjà de comparer les systèmes "brut de coffrage" et de constater que les performances n'était pas celles communément admises.

3/ Ca ne ne savait pas, faudrait que je refasse les tests en O2 alors, surtout pour GJC qui reste ma grosse déception.

4/ Tout à fait d'accord, le seule problème est que je n'ai pas de windows pour faire ce test. Je pensais à un moment utiliser VMWare pour faire ces tests mais je ne suis pas encore bien sur du protocole et de la validité de l'ensemble. Et comme il est hors de question que je magane mes machines avec un windows...

En tout cas, si tu fais d'autres tests ou as d'autres idées, n'hésites pas !

Pour moi le vrai problème de Java n'est pas la performance brute, mais le temps de démarrage qui le rends difficilement utilisable pour toutes les applications ponctuelles (Desktop, ligne de commande, etc..).

Nous avons en effet une problématique differente: Nous considerons que nous disposons d'un applicatif assez lourd "up toute la journée" et effectivement nous tentons de mesurer la perf brute. Dans ce cas, le coup de demarrage, mais aussi le JIT, size des zones mémoire, zone de cache ne nous interesse pas.

Sinon sur le 4/, le coup de la VM me semble pas très valide.
Sur le 2/, je ne pense qu'il ne faut pas confondre l'option -server qui permet un parametrage par defaut different et le temps d'exécution d'un test, qui comprend l'exécution mais aussi le chargement des classes, l'initialisation des zones statiques, ....

Pour le 4/ je suis intuitivement d'accord sans bien savoir pourquoi Anyway, là s'arrête mon tribus car je ne suis pas décidé pour l'instant à installer un windows en direct, peut-être plus tard si mon travail m'y oblige.

Pour le 2/ il me semblait que tout l'intérêt d'un -server était justement de précompiler le code ?

D'un point de vue général, les performances que vous recherchez sont finalement celles des plus grandes utilisations de java. C'est à dire côté server avec un JBoss & co, tomcat, serveur de traitement, etc... Mais du coup, l'utilisation "interactive" de Java est resté complètement en retrait. Et c'est là que .Net tente de se faire passer pour un bien meilleur compétiteur. Mais le problème (ou l'avantage selon les points de vues) de cette stratégie, c'est qu'il y a beaucoup plus d'application "interactive", en volume, même si elles sont beaucoup moins importantes, en taille. Donc suivant cette idée, on va aboutir à interactif en Net et serveur en Java. Mais comme, les première sont plus nombreuse que les secondes, cela va entraîner à terme un "tout Net", ou pire, une espèce de zone grise.

Entendons nous bien, je n'ai rien contre Net, juste que je vois pas l'intérêt de faire deux fois, strictement la même chose

Je dois rédiger un rapport en probatoire sur ".net va t il remplacer java?" et vos tests m'interressent fortement.
J'étais très inquiet sur les différents tests (.net) pulvérisant et c'est un faible mot java. Evidement des tests en environement Windows.
Vu que .net s'éxecute en natif et que le cahier des charges des labo de MS était la priorité aux performances en délaissant le cote multi-plateforces.
Depuis des annés MS nous a menti sur leur OS sécurisé a mort alors que c'était les utilisateurs qui testaient les produits. Du coup j'ai de gros doutes sur la vérité et la transparence de leurs analyses. Vos tests me paraissent plus proche des serveurs même si linux est un petit/moyen serveur. Un grand merci ca m'encourage de voir que je n'ai pas fait un logiciel en JEE5 pour rien.
MS va se pencher sur le problème suivant: mise en place de solutions pour passer sa plateforme .net en multi-plateformes.
Que pensez-vous de cela?

La grande illusion de vitesse que l'on associe à .Net tient à ce que les applications .Net démarrent plus vite que les applications java même si java fait des progrès constants dans ce domaine. Ma théorie à deux sous est que ne pouvant rendre leur VM plus rapide (en grande masse), MS a joué, très finement d'ailleurs, sur la vitesse psychologique : si une appli se lance plus vite, c'est que la VM est plus rapide. L'utilisateur étant généralement capable de juger objectivement que cet aspect là.

Schématiquement, la lenteur de Java au démarrage est explicable par un processus autrement plus complet de vérification notamment que .Net, il n'y a pas de miracle là non plus et les prochaines plate forme Java vont le prouver je pense. L'autre raison est la complexité du JDK, autrement plus avancé que les librairies de .Net. Le "champ des possibles" avec les seules librairies de base est très large (audio, vidéo, espaces de stockages complexes, xml très avancé, SWING qui est un énorme morceau, etc..). Il faudrait un jour pour prouver cela comparer le nombre de classes disponibles du côté .Net et du côté Java.

Maintenant, Java va fortement évoluer avec son entrée dans le monde GPL. La version 7 promet d'être extrêmement intéressante (j'ai entendu parler d'évolution de langage comme les propriétés par exemple, d'une plate forme allégé pour ne charger que l'essentiel et accélérer ainsi les temps de démarrage, un nouveau look pour remplacer le vieillissant Metal de swing, etc.). L'ouverture du code de java va permettre de démultiplier les compétences (du moins je l'espère) et combler les retards Java/.Net tout en conservant les nombreuses avances. Bref, JEE7 va être intéressant sans compter que grace à sa licence, il va pouvoir enfin être intégré dans toutes les distributions en standard.

Il ne faut pas oublier pourquoi .Net est né. A l'origine Microsoft était Java, et à la suite de la grosse fâcherie de Sun, Microsoft a décidé de faire cavalier seul et de refaire la même chose, à leur sauce. Autant SUN n'est pas tout blanc dans cette histoire, autant Microsoft avec .Net choisi une fois de plus de la jouer "perso" et de s'éloigner des standards. Un peu comme ce qui est en train de se passer avec l'affrontement Mozilla/Microsoft sur l'avenir JavaScript.

Carton rouge

Hello
A force de chercher j'ai trouvé ... Microsoft a versé 200 000 dollars pour qu'on adopte son .NET a différentes sociétés. N'y aurait-il pas des socétés qui trafiquent leurs tests de perf .NET/Java dans le lot.
Bye

@chris Tu as des références ou des documents pour appuyer cela ? Cela m'intéresse vraiment.

bonjour,

J'ai eu du mal a le retrouvé ce lien.

Je me suis trompé c'est 200 millions de dollars .... une petite erreur de ma part double carton rouge du coup!

article http://www.01net.com/article/182092_a.html

bye

C'est pas ca je m'embrouille dans les articles ... mince alors.

Tu devrais installer scrapbook (extension pour firefox), depuis que j'ai cela, je ne bookmark plus, je scrapbook et du coup j'archive tout sans exception

Petite question: les tests des entrées-sorties sur fichier ont été effectués avec les NIO (FileChannel et ByteBuffer)?

@Jérôme Non, c'est un test utilisant l'API de haut niveau pour être le plus juste avec les autres langages. Il est basé sur l'écriture d'un fichier texte de N lignes et de sa relecture.

You're welcome, faudrait que fasse un coup de doxygen là dessus pour donner accès à la visualisation des sources. Elle sont dans tous les cas dispo ici : http://artisan.karma-lab.net/software/subversion/languagesComparator/tru...

Mais elle ne sont pas encore documentées.

Oui, ça serait cool , j'étais jeter un coup d'oeil sur le lien donné en début d'article, il y'avait la réponse à ma question en fait (sauf si tu as modifié aussi cette partie là).

Par contre, si tu as un peu de temps, ça m'intéresserait de savoir pour les NIO !

C'est un test que j'avais dans le pipe, mais plus pour la section "optimisation"

Si tu as des avis sur le code ne te gène pas. Notamment pourquoi les Vecteurs java sous-perform autant que cela par rapport à Mono.

Article très intéressant, merci ! Je regrette juste que vous n'ayez pas utilisé la version 1.9.1 de Mono qui est la dernière version stable.

"autant Microsoft avec .Net choisi une fois de plus de la jouer "perso" et de s'éloigner des standards. Un peu comme ce qui est en train de se passer avec l'affrontement Mozilla/Microsoft sur l'avenir JavaScript."

Je tiens à rappeler qu'à l'époque où est sortie .NET l'idée de rendre Java open-source n'existait même pas, alors que le Framework de Microsoft fut immédiatement "standardisé" par l'ECMA.

Donc entendre au sujet de Java qu'il était un "standard" à l'époque où fut lancé .NET, c'est avoir le même raisonnement qu'un Microsoft quand il nous explique que Word est un standard car il est utilisé par la majorité des utilisateurs de taitement de texte. Pire, à ce moment .NET était vraiment un standard "ouvert" (en partie seulement, soit, mais tout de même !).

Ensuite le coup du ".NET c'est une copie de Java" est certainement vrai pour ses débuts, mais il faut avoir l'honnêteté d'avouer que depuis ces jours le projet a su trouver une identité propre.

Combattons les abus de Microsoft mais ne tombons pas dans l'anti-microsoftisme primaire !

Bonjour,
Quelle version de GCC avez vous utilisez ? De tres grande disparité de "qualité" de code généré existe entre les versions.
Comme indiqué O3 est à éviter, mais il existe PLEIN d'autre paramètres pour optimiser le code.

@Jean-Baptiste Moui, mais à ma décharge c'est un vieux commentaire. Je ne sais même plus à quoi je faisais référence pour JavaScript

En préambule à ma réponse, j'avais à l'époque de son lancement pas mal de contacts avec des éléments de l'équipe .Net. A cette époque une guerre sur fond de procès faisait rage entre MS et SUN, l'un voulant intégrer à grand coup de patch ses exotismes Windowsiens dans Java, l'autre était dans une position d'intégriste de la JSR. Deux mondes qui s'affrontent entre l'ultra "laxiste" et l'ultra "orthodoxe" en quelque sorte. Le crédo à l'époque des Sunistes était que tous les hacks Microsoftiens étaient enrobable dans une librairie JNI, les Microsoftiens étaient quant à eux de fervents C++istes et tolérait sur le fond assez mal la rigueur du langage lui-même. Au final aucun point d'accord n'a été trouvé et la CLR est née dans les esprits. Le papa de Delphi a été embauché pour écrire un nouveau langage, le C# et designer l'architecture de l'ensemble. Si tu cherches bien dans le langage C#, tu trouveras des traces delphiesques assez visibles.

Donc à cette époque, je ré-itère, .Net est une copie de Java (au delta du système d'assemblies que j'envie) et je n'ai rien dis de plus que cela. Après .Net évolue sur son propre chemin et c'est très bien ainsi. Mais pour revenir à ta remarque, et de la bouche même d'ingénieurs de chez MS, .Net est né d'un désaccord entre SUN et Redmond. S'il cela n'avait pas été le cas, il "n'auraient pas été de refaire la même chose".

Maintenant pour ce qui est du Standard Java, je n'utilise pas ce terme dans le même sens que Norme. Pour moi, et effet, les fichiers de Word sont un standard, de même qu'office ou Windows, mais ils ne s'appuient sur aucune Norme. C'est même un Standard "fermé" car rien ne permet(tait) de "lire" les spécifications de ce standard.

A ce titre Java était et est toujours un standard et .Net en devient un aussi. C'est juste une question d'adoption dans l'industrie.

Maintenant, la différence est que .Net est lui normé par l'ECMA et pas Java. En revanche, même si Java na pas de Norme associée, il n'en était pas moins ouvert. La preuve en est le nombre de JVM alternative qui existe dans le monde libre. Elles n'ont pas été écrites par Reverse Engeneering, mais à partir des spécifications disponibles.

Maintenant encore, Ouvert ne veut pas dire Libre, c'est pour cela que je n'aime pas la confusion entre Libre et OpenSource. Java a toujours été OpenSource sauf pour les parties internes (celle justement qui ont été récupérées pour Iced-Tea dans le projet GNU-ClassPath).

En somme, Java était un Standard Ouvert et pas Libre à l'époque où .Net était une Norme Ouverte et Libre (à l'exception de WinForm, la gestion XML, etc.. des pailles...). Aujourd'hui Java n'est toujours pas Normé (pas à ma connaissance en tout cas) mais est un Standard Ouvert et Libre.

Comme tu le vois, je ne fais pas d'Anti-Microsoftisme primaire, je trouve juste que l'histoire a comme souvent pris un chemin ridicule qui est la conclusion logique du bordélisme de Microsoft et de psycho-rigidité de SUN. Au final, si tu zappes sur les détails, tu as deux machins qui font grosso-modo la même chose, ce qui implique une division par deux des resources disponibles.

Bon, j'ai fait un premier essai avec les NIO, sur 1000000 de lignes, j'ai un gain d'environ 3 secondes dans le pire des cas. Mais je dois sûrement affiner ma méthodologie pour les histoires de cache etc (je suis sous Windows).

Question optimisation, c'est assez sympa comme gain pour un code qui fait rigoureusement la même chose.

@ Ulhume

"Donc à cette époque, je ré-itère, .Net est une copie de Java (au delta du système d'assemblies que j'envie) et je n'ai rien dis de plus que cela. Après .Net évolue sur son propre chemin et c'est très bien ainsi."

Oui, tout à fait, nous sommes d'accord

Pour le reste, je n'ai pas grand chose à dire, je suis entièrement d'accord également. Et au passage vous m'avez appris pas mal de chose, donc merci !

@Jean-Baptiste de rien, j'espère seulement ne pas être passé pour un évangéliste, ce que je détesterais entre tous.

@Jérôme tu pourrais m'envoyer le code par mail ? Ca me ferais gagner du temps :

@Anonymous (Un nom SVP ?) J'ai rajouté les numéro de version en intro
@Jean-Baptiste Malheureusement il n'y a que la 1.2.6 de dispo sur la mandriva, j'ai pas bien le courage de compiler une custom.

Re, je suis allé un peu vite en besogne, je dois retoucher mon code !

Apparemment, pour de petits fichiers, NIO ne prend pas l'avantage sur IO. J'essaie donc de faire la version la plus optimisée possible.

Mise à jour

Ajout de GCJ dans le pool de test

@Jérôme, ok, j'attends que tu ais fini

Bravo, très sympa comme test.
Bien évidement, je suis aussi très intéressé par un test avec la VM.net de Microsoft. Ou trouver ton framework de test pour comparer Mono et la VM de M$ sur Windows ? (Framework de bench opensource?)

Un test qui peut être intéressant aussi est celui de IKVM.net (la JDK compilé en .net). Pourquoi? J'ai personnellement fait des bench de la sérialization .Net, Java et IKVM et je me suis rendu compte que IKVM sérialise plus rapidement que le framework.Net. On ne compare plus la VM ici, mais bien le framework.net vs JDK.
Pour info: j'utilisais encore la version d'IKVM avec GNUClassPath... en sachant que maintenant ça a migré sur OpenJDK.

Le problèmes de Mono avec la mémoire ne m'étonnent pas. Tout le monde peste sur des applications tel que Beagle (le "Google Desktop Search" fait en Mono) sur la consommation gourmande en mémoire et l'utilisation massive du CPU.

L'impression de mauvaise performance de Java ne vient pas, à mon avis, du chargement (ou alors un peu). Je pointerai du doigt l'interface graphique. En effet, ce qu'on voit rammer c'est l'interface, et on passe rarement du temps dans les traitements. La VM de M$ est bien sûr performante puisqu'elle repose sur WIN32 (natif). D'ailleurs, je trouve que les applications SWT répondent mieux que les applications SWING.

Ceci dit, les Winforms peuvent être très lente avec des composants complexes. C'est la que WPF déchire tout en faisant peau neuve et en utilisant massivement DirectX. Alors oui, SWING utilise maintenant un pipe DirectX, mais ce n'est pas défaut que dans la dernière Java6-update10(beta) et ce n'est sans doute pas encore la panacée. JavaFX est-il la pour sauver cet aspect? Et sous Linux, le pipe OpenGL est-il bien exploité? L'implémentation WPF de Mono va-t-elle rendre QT/GTK obsolète?

Je sais que c'est trop demandé, mais comme beaucoup d'application Linux sont en Python, pourquoi ne pas le rajouter histoire de comparer?

@Grozeille
J'ai un volet IKVM dans mes tests mais il n'est pas activé car les résultats son vraiement pas terribles. Environ 4 fois plus lent que les autres VM avec des tests qui plantent (notamment le LoadImage). J'avais plus fait cela pour voir s'il était facile d'ajouter un système à la plateforme mais sur le fond, je ne comprend pas bien l'intérêt de la manœuvre, intégration Java/.Net à la limite. Bref. J'ai l'impression qu'il y en a un qui se fait plaisir avec cette histoire et il ne s'en cache pas d'ailleurs (cf son FAQ Maintenant que le JDK performe mieux que .Net, je ne suis pas trop surpris, ils n'ont juste pas le même age et la même maturité.

Pour le framework de test, oui il est LIBRE, c'est donc mieux qu'OpenSource Je vais essayer de la packager un peu mieux mais si tu es bidouilleur cela ne devrait pas te poser de problème, y'a besoin du projet "commons", "benchmarks" et "languagesComparator". Tout est sur le subversion (http://artisan.karma-lab.net/software/subversion). Il faut checkouter languagesComparator, lancer le makefile (et le bidouiller pour le faire marcher sous Windows). Cela va générer les N exécutables de test. Les deux autres projets ne sont là que pour encadrer les tests et générer les graphiques.

Pour ce qui est de Mono et la mémoire, c'est le même problème pour Java. Tous les environnements managés impliquent une consommation accrue de cette ressource. Java n'est pas mieux, loin de là, sur ce point. Tout a un prix.

Maintenant pour Swing, je ne suis pas d'accord. Essaye IdealJ et dis moi si tu trouves que ça rame. Swing est absolument intransigeant quant il s'agit de mauvais développement. Mais une fois qu'il est correctement utilisé, il permet des trucs très sympa que SWT ne peut pas permettre. Maintenant, c'est vrai que sans connaissance particulière de Swing, SWT permet à n'importe qui de pondre une IHM qui tourne bien. Pour WPF, j'en sais rien, j'ai pas vu et si ça reste sous Windows, je suis pas près de voir. Maintenant quant à rendre Qt ou Gtk Obsolète, j'attends de voir, surtout pour Qt car Gtk est déjà obsolète depuis un certain temps

Pour finir, python est un langage de script et moi je cherchais à comparer les langages managés avec les langages natifs. Mais ceci dit, si tu rédiges un version Python des tests, je l'ajoute avec plaisir

Bonjour

Une petite update pour indiquer que nous avons publié (enfin surtout Alex les tests fait pour une grande entreprise:
http://javageek.free.fr/wiki/index.php/Java:BenchmarkLanguages/fr

Intéressant, c'est la même base de tests qu'ici (les intitulés ressemble) ? Vous avez les sources quelque part ? Les liens externes sont tous dans le vide...

En tout cas les résultats sont assez étonnant... J'avoue que l'ai peine à croire une telle différence Java/C#.

Bref, c'est sympa pas j'aimerais bien voir les sources

Tip Top l'article !
Et je suis totalement d'accord quand tu dis que c'est la lenteur du démarrage des application Java qui nous font dire que Java est lent.

Ulhume, il semble que tu aies un problème avec le terme "OpenSource" (il me semble l'avoir déjà dit dans un commentaire mais la flemme de chercher à cette heure ci ) :

Maintenant encore, Ouvert ne veut pas dire Libre, c'est pour cela que je n'aime pas la confusion entre Libre et OpenSource. Java a toujours été OpenSource sauf pour les parties internes (celle justement qui ont été récupérées pour Iced-Tea dans le projet GNU-ClassPath).

OpenSource implique, comme Libre, d'avoir les quatre Libertés. Une licence Libre est OpenSource et vice-versa. La différence est est dans l'esprit qui va avec, le terme OpenSource ayant été créé pour deux raisons : éviter le problème du double sens du mot "free" en anglais et dissocier le Libre de l'idée de la FSF, de GNU etc (et la mienne) selon laquelle la Liberté et l'éthique nécessitent des logiciels Libres (raison pour laquelle la FSF déconseille l'emploi du terme). À part ça, OpenSource=Libre, et la définition du terme (marque déposée de l'OpenSource Initiative) est basée sur les Debian Free Software Guidelines.

L'emploi que tu en fait, si j'ai bien compris, c'est à dire s'en servir pour parler d'un soft dont le code est visible par tous mais non-Libre, correspondrait plus au terme "Shared Source" inventé par... Microsoft, même si je trouve ce nom complètement débile car en fait un logiciel "Shared Source" est en fait un logiciel dont on ne peut pas librement partager le code source...

Voilà, c'était mon moment "pourrissage de blog* en chipotant sur des détails inutiles". Faut bien que je m'occupe mon blog est down .

*oui je sais c'est pas un blog ici.

Sinon sur le fait que dotNet soit normalisé par l'ECMA, en fait Microsoft ne respecte pas la norme et donc Mono non-plus car il vise la compatibilité, d'où le projet dotGNU de la FSF, classé projet prioritaire et qui a l'avantage sur Mono de ne pas inclure des éléments potentiellement dangereux d'un point de vue légal pour ceux qui n'ont pas d'accord avec MS comme Novell.

Il serait intéressant d'avoir un benchmark qui inclue Java, Mono et .Net (et pourquoi pas dotGNU ? et python, et ruby...). Allez, au boulot !

Sur-ce, bonne nuit.

Mon cher Zanko, déjà tu ne pourris rien du tout ou alors à ce niveau de qualité de commentaire j'accepte le pourrissage, au choix

Dans la phrase que tu as cité j'ai un peu confusé ouvert/opensource, désolé. Un vieux réflexe dont, en effet, tu avais été dans un ancien commentaire la cause de changement.

Ce que je voulais dire c'est qu'un code peut être ouvert=visible et n'être ni libre, ni donc opensource. L'exemple de Java est assez flagrant justement car même sous licence propriétaire, le code a toujours été ouverts, du moins en grande partie. Il y a aussi l'exemple de Qt au début. L'exemple de Darwin, au début aussi.

Au fond libre, ouvert, opensource, propriétaire, l'important c'est : quelle est la maudite licence qui va avec. Car "opensource" ou "libre", ne sont pour tout à chacun que des mots plus ou moins tendance. La licence elle, a une solidité toute juridique. Java JDK était sous SCSL, il est aujourd'hui sous licence GPL. Qt était sous licence Qt, il est aujourd'hui sous licence dual Qt/GPL (GPL pour les projets GPL, Qt pour les autres). Darwin était sous licence APSL 1.0, il est aujourd'hui sous licence ASPL 2.0.

Au final y'a ce qui est ouvert et ce qui ne l'est pas. Et dans ce qui est ouvert, il y a la licence.

Pour Mono/.Net, je suis assez d'accord. Je trouve même dramatiquement comique que le leader du projet Gnome, qui est né justement pour "lutter" contre la déviance KDE/Qt, soit aujourd'hui consacré à plein temps à introduire sur la même plateforme libre (ou opensource des briques dont la licence est plus que douteuse. Leader qui rappelons-le qui est toujours vice-président de Ximian, qui appartient aujourd'hui à Novell. Une autre manière de border les problèmes de licence de Mono ?

Pour ce qui est d'inclure .Net dans les tests, j'y ai bien pensé mais ce truc me saoule de dépendances. Faudrait que je m'arme de courage.

Tous les articles sur ce site sont mis à disposition selon les termes de la licence Creative Commons Paternité-Partage des Conditions Initiales à l'Identique 2.0 France (Amen !). Les autorisations au-delà du champ de cette licence peuvent être obtenues ici.