Comparaison entre une JVM(Java) et le CLR(.NET)

Posté par  . Modéré par Benoît Sibaud.
Étiquettes : aucune
-1
22
mar.
2002
Java
Une comparaison très technique des 2 avaleurs de bytecode par l'entremise de l'implémentation d'un compilateur Pascal -> bytecode pour les 2 plate-formes.

C'est assez intéressant pour comprendre la manière dont fonctionne une JVM et un CLR.

NdM : une JVM est une machine virtuelle Java (Java Virtual Machine) et un CLR un interpréteur du langage commun .Net (Common Language Runtime). Le compilo créé est dans le domaine public.

Aller plus loin

  • # La sa.......

    Posté par  . Évalué à -10.

    "2 avaleurs de bytecode"
    Heureusement que ce ne sont pas 2 avaleuses.......


    Aller hop -1 pour la peine !

  • # Mon bytecode restera libre !

    Posté par  . Évalué à 10.

    C'est peu leger en fait comme explications sur le fonctionnement interne d'une VM.
    Et puis c'est un peu du proselytisme .NET.
    Et puis on n'y parle pas de sécurité, tu m'étonnes.
    Et puis Java a déjà du vécu, donc c'est un peu facile de comparer une techno émergente avec une techno plus ancienne. Pourquoi pas comparer un K6 avec un P4 hein ?
    Comme benchmark, heu non c'est pipo.

    Donc à lire si vous aimez .NET. Sinon vous allez être dégouté de ce FUD.

    Et puis le compilo dans le domaine public, ca veut dire quoi ça ? MSIE aussi est dans le domaine public ? Il en faudra plus que ça, et puis faire confiance à MS pour les licences, faut vraiment être un décideur pressé.

    M'en fout, tout ce que j'attend c'est une VM pour Ruby.

  • # Rectification

    Posté par  . Évalué à 10.

    Juste pour dire que le compilo est bien disponible en GPL comme ecrit en fin de page 6. La comparaison reste assez neutre. Grosso modo l'auteur nous dit que la JVM a ete ecrit pour supporter java, alors que la CLR a ete ecrit pour supporter plusieurs langages ce qui donne des instructions intermediaires differentes. S'en suit un benchmark cense montrer que le CLR est plus rapide que le java. Mais bon, on sait tous ce que veut dire les benchmarks : rien.

  • # des bons points et des mauvais

    Posté par  . Évalué à 6.

    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é.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.