La comparaison se résume à la comparaison des bytecodes (langage élémentaire d'une VM), un peu du modèle mémoire et des conventions d'appels de méthodes. Sur les deux derniers points, vaut mieux avoir lu les documents de références de chez SUN ou M$ car sinon on comprend pas trés bien. En plus, le document se limite trop a une description sans décrire les forces et faiblesses de chaque approches pour une JIT.
Par contre, les points sur la difficulté de migrer CLR vers l'embarqué semblent pertinents et correspondent bien à ce que je connais des deux jeux de bytecodes aujourd'hui. Il est clair que M$ à fait un jeu de bytecode qui semble laisser plus de liberté pour optimiser le code compilé à la volé. Maintenant reste à savoir si des JIT capables d'en tirer profit seront au rendez-vous. Perso, j'en doute pour le moment. Il faudra plusieurs années pour que les JIT de M$ commencent à exploiter de façon efficace les libertés du CLR.
Ironie, le document se conclu par la proposition de faire une moulinette qui transforme le CLR en un bytecode (qui reste à inventer) qui soit plus adapté à l'embarqué. En pousant un peu le raisonnement, je pense que le bytecode java serait un bon candidat pour faire tourner les applications basés sur CLR moyennant l'interdiction des quelques particularités trop versatiles du CLR. A creuser. Mais ca me fait sourir qu'une solution comme celle-ci pourrait exister un jour.
Oublier les résultats du benchmark. c'est n'importe quoi. Ils sont partis d'un langage qui n'est pas trés bien adapté à aucune des deux VMs. Toutefois .NET s'en tire un peu mieux grâce à la prise en compte dans le design de langages différents. De plus la jeunesse du compilateur pour ce langage n'inspire pas vraiment confiance dans l'objectivité des résultats.
Une comparaison plus honnête aurait été de prendre Java pour la JVM et C# pour .NET, de partir des mêmes algorithmes et de faire les implémentations correctement pour avoir une idée des capacités.
Mais, même ainsi je doute que la qualité des résultats soit pertinente.
Pour conclure, je dirais que l'auteur n'est trop pro-.NET ni pro-java mais que sa méthodologie manque beaucoup de maturité.
# des bons points et des mauvais
Posté par Schwarzy . En réponse à la dépêche Comparaison entre une JVM(Java) et le CLR(.NET). Évalué à 6.
Par contre, les points sur la difficulté de migrer CLR vers l'embarqué semblent pertinents et correspondent bien à ce que je connais des deux jeux de bytecodes aujourd'hui. Il est clair que M$ à fait un jeu de bytecode qui semble laisser plus de liberté pour optimiser le code compilé à la volé. Maintenant reste à savoir si des JIT capables d'en tirer profit seront au rendez-vous. Perso, j'en doute pour le moment. Il faudra plusieurs années pour que les JIT de M$ commencent à exploiter de façon efficace les libertés du CLR.
Ironie, le document se conclu par la proposition de faire une moulinette qui transforme le CLR en un bytecode (qui reste à inventer) qui soit plus adapté à l'embarqué. En pousant un peu le raisonnement, je pense que le bytecode java serait un bon candidat pour faire tourner les applications basés sur CLR moyennant l'interdiction des quelques particularités trop versatiles du CLR. A creuser. Mais ca me fait sourir qu'une solution comme celle-ci pourrait exister un jour.
Oublier les résultats du benchmark. c'est n'importe quoi. Ils sont partis d'un langage qui n'est pas trés bien adapté à aucune des deux VMs. Toutefois .NET s'en tire un peu mieux grâce à la prise en compte dans le design de langages différents. De plus la jeunesse du compilateur pour ce langage n'inspire pas vraiment confiance dans l'objectivité des résultats.
Une comparaison plus honnête aurait été de prendre Java pour la JVM et C# pour .NET, de partir des mêmes algorithmes et de faire les implémentations correctement pour avoir une idée des capacités.
Mais, même ainsi je doute que la qualité des résultats soit pertinente.
Pour conclure, je dirais que l'auteur n'est trop pro-.NET ni pro-java mais que sa méthodologie manque beaucoup de maturité.