JRuby 1.7.0

Posté par  (site web personnel, Mastodon) . Édité par Davy Defaud, Nÿco, El Titi et Bruno Michel. Modéré par Nÿco. Licence CC By‑SA.
Étiquettes :
11
25
oct.
2012
Ruby

Après un an et demi, l’équipe de JRuby vient de mettre à disposition la version 1.7.0 de son implémentation de l’interpréteur Ruby écrit en Java. La grande fonctionnalité de cette version est la compatibilité avec Ruby 1.9. En effet, l’interpréteur se comportera comme un Ruby 1.9.3 par défaut. Il y a encore des bouts de Ruby 1.9 qui ne sont pas — encore — pris en charge comme le Ripper, l’analyseur de code. Cependant, l’équipe considère que cette version est capable de faire tourner des applications en production.

Logo de JRuby

Le travail ne s’est pas fait que là. L’équipe JRuby annonce des améliorations dans tous les sous‐systèmes et notamment dans la parallélisation des traitements. L’autre point saillant de cette version est la prise en charge de la fonctionnalité invokedynamic incluse dans la JVM depuis la version 7 de Java (mais désactivée par défaut jusqu’à l’arrivée de Java 8). JRuby vous explique comment l’activer.

JRuby est disponible en téléchargement sous forme de binaires pour Java, d’exécutables pour Mac OS X et Windows, de gems Ruby et, bien sûr, de fichiers sources. Vous pouvez également cloner le dépôt Git !

NdM : Merci à Nÿco et Le Cancre Las pour leur participation à la rédaction.

Rappels sur JRuby

JRuby est une implémentation libre (sous triple licence CPL, GPL et LGPL) en Java du langage de programmation Ruby. Son étroite intégration avec Java permet d’embarquer l’interpréteur Ruby directement dans une application Java, avec des liens bidirectionnels possibles entre les deux langages, à la manière de Jython (Python en Java). La prise en charge de Ruby on Rails est de la partie !

Parmi les autres nouveautés

On retrouve :

  • tous les problèmes d’encodages liés à la 1.9 sont résolus ;
  • l’instruction Kernel#exec réalise désormais un appel natif sur toutes les plates‐formes ;
  • améliorations et corrections relatives à l’intégration Java ;
  • les fonctions natives sont mieux prises en charge sur Solaris, Linux pour ARM, etc. ;
  • mise à jour vers les bibliothèques standard de Ruby 1.9.3p286 ;
  • mises à jour de Rubygems 1.8.24 et Rake 0.9.2.2 ;
  • enfin, notez l’abandon de Java 5. Java 6 est un pré‐requis pour embarquer JRuby.

Feuille de route

L’équipe prévoit désormais de sortir des versions mineures de la branche 1.7.x toutes les 2 à 3 semaines, afin de corriger les problèmes rencontrés et de finaliser la prise en charge des parties manquantes des bibliothèques de la version 1.9 de Ruby.

Aller plus loin

  • # Les performances ?

    Posté par  . Évalué à 4.

    Ça va vite, il y a de jolis dessins à montrer ? En comparant à la version précédente mais aussi à l'implémentation officielle de Ruby ?

    • [^] # Re: Les performances ?

      Posté par  . Évalué à -5.

      Java troll inside?

    • [^] # Re: Les performances ?

      Posté par  . Évalué à 2. Dernière modification le 25 octobre 2012 à 18:03.

      Oui, je suis particulièrement curieux a propos des gains de performance d' invokedynamic

      Tiens voici un petit graphique ici (a partir de la diapo 18):
      https://docs.google.com/presentation/d/1-hA1tAF1ADdCzsIAEQCcVxl2YIieb4Xopm21Slx3XFE/edit?pli=1#slide=id.g860ad29_0_0

      Résultat: Java 7 avec invokedynamic souvent 1.5x plus rapide que Java 7 sans invokedynamic

      • [^] # Re: Les performances ?

        Posté par  . Évalué à 3.

        Et une explication du fonctionnement de invokedynamic ici:
        http://blog.headius.com/2011/08/jruby-and-java-7-what-to-expect.html

      • [^] # Re: Les performances ?

        Posté par  . Évalué à 4.

        J'ai laché le suivi du JDK depuis un an donc il se peut que je dise des choses qui ne sont plus vrai (fix dans une mineur).

        Dans les JDK7 l'utilisation d'invokedynamic desactive pas mal d'optimisation de Hotspot. Il était prévu d'adresser ces problèmes dans le JDK8. Il est donc a prévoir une deuxième grosse ameilloration des perfs quand Ruby sera capable d'utiliser pleinement Hotspot. J'ai pas réussi à trouvé un résumé de l'état d'Hotspot sur ce sujet. Si quelqu'un a des infos…

        D'autres bonnes choses devraient arriver avec le JDK8 pour les langages dynamiques commme la suppression de l'horrible pergem space.

    • [^] # Re: Les performances ?

      Posté par  . Évalué à 2.

      Le shootout est passé à JRuby 1.7
      Ça permet des comparaisons (et en 32), sur pas mal de micro-benchmarks entre cette version et l'officielle.

      Sur ces tests, qui ne reflètent évidemment pas la réalité pour un programme donné :

      • JRuby serait en moyenne environ 1.5 plus rapide, bien que cela dépende vraiment des tests
      • la consommation mémoire va de 2 à 127 fois plus que l'implémentation officielle. En moyenne plus de 50 fois.
      • [^] # Re: Les performances ?

        Posté par  (site web personnel) . Évalué à -1.

        Bah déjà que l'implémentation officielle consomme beaucoup de mémoire :-)

        • [^] # Re: Les performances ?

          Posté par  . Évalué à 5.

          Attention tout ce qui repose sur la JVM est assez biaisé niveau consommation mémoire puisque par design elle va utiliser sa heap size en maximum sans rien garbage collecter avant. Très grossièrement c'est comme si free(3) ne faisait rien tant qu'un certain seuil n'était pas atteind.

          Donc sur tout les bench de ce type la mesure est assez inutile. Après ce comportement est ou n'est pas problématique selon les cas d'usage.

  • # Utilité ?

    Posté par  . Évalué à 6.

    Bonjour

    N'y voyez pas un troll, juste une question naïve : ça sert à quoi d'implementer Ruby en Java ?

    • [^] # Re: Utilité ?

      Posté par  . Évalué à 4.

      En gros les gens espèrent récupérer les bonnes propriétés des machines virtuelles Java optimisées à mort : compilation JIT optimisée à mort, et runtime qui supporte bien le parallélisme multi-thread (alors que les implémentations maisons reposent souvent sur un Big Interpreter Lock et ne peuvent donc faire que du parallélisme multi-process). Tant mieux si tu as en plus accès aux librairies Java (mais en pratique les interfaces sont tellement différentes que ça n'est pas si commode), aux outils qui travaillent directement sur le bytecode (test de sécurité ou de bugs, instrumentation etc.).

      C'est partiellement liés aux raisons que les gens de Google ont utilisé quand ils ont écrit Gerrit, une implémentation d'un logiciel de revue de code basée sur un backend Git: au lieu de prendre l'implémentation Git officielle en C, ils utilisent une ré-implémentation de Git en java, JGit, parce qu'ils préfèrent administrer des trucs qui tournent sur la JVM.

      • [^] # Re: Utilité ?

        Posté par  . Évalué à 2.

        Ruby 1.9 est passé (pour la VM) de MRI à YARV, ce qui a permis d'avoir des kernel threads, qui semblent correspondre à de "vrais" threads (plutôt que les green threads des versions <= 1.8) selon wikipedia, et a apporté pas mal d'améliorations des performances.

        La VM de Ruby 2.0 devrait aussi apporter une amélioration des perfs : http://www.h-online.com/open/news/item/Ruby-2-0-feature-freeze-heads-for-February-release-1736526.html

        Du coup, l'intérêt de JRuby sera nettement moindre quand Ruby 2.0 sera largement adopté (oui ce n'est même pas sûr d'arriver un jour, mais bon), non ?

        Aussi, en quoi Ruby (et les autres) sont "implémentés avec les pieds" exactement ? Je suis curieux. :)

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Utilité ?

          Posté par  . Évalué à 3.

          Il n'empêche que l'implémentation de YARV fait qu'à un instant donné un seul thread Ruby peut s'exécuter, il y a un "Big Interpreter Lock" comme je l'ai dit dans mon message (l'intérêt d'avoir plusieurs threads dans ce cas est d'utiliser l'outillage de l'OS, de faire tourner des threads C en parallèle avec des threads Ruby (ce qui encourage les gens à coder de plus grosses parties de leur programme en C), ou encore de donner le contrôle à un autre thread si tu bloques sur une grosse entrée/sortie (mais il faut explicitement coder la relâche du verrou global)). Au contraire la JVM permet de faire tourner du bytecode vraiment en parallèle sur plusieurs cœurs, donc si tu écris tes programmes pour (il faut éviter les data races) tu pourrais avoir des gains en performance.

          Je n'ai pas suivi la 2.0 mais il faudrait partir d'une source un peu plus intéressante qu'une demi-phrase sur "un bytecode plus optimisé" dans un article grand public.

    • [^] # Re: Utilité ?

      Posté par  . Évalué à 5. Dernière modification le 26 octobre 2012 à 17:04.

      Dans la vraie vie ça ne marche pas toujours aussi bien : la JVM a été pensée pour Java et la viser depuis un autre langage peut poser problème si ta sémantique est vraiment différente. Typiquement tu ne vas pas pouvoir réutiliser le modèle objet (mais invoke_dynamic est censé aider pour ça), ou alors ton langage utilise beaucoup les appels terminaux qui ne sont pas optimisés en Java pour des raisons moisies, ou tu utilises des exceptions qui se traînent le ventre par terre sur la JVM ou sur la machine virtuelle .NET.

      Même pour les langages dynamiques implémentés avec les pieds comme Python, PHP ou Ruby, les gens pensaient avoir de gros gains en utilisant un runtime "state of the art" comme Java ou un JIT existant comme LLVM, et en fait c'est loin d'être aussi simple, la perte de contrôle sur la représentation des données ou certains points d'optimisation fait que c'est finalement assez dur de faire franchement beaucoup mieux en peu d'efforts; et même quand tu y arrives, tu découvres que les utilisateurs ont codé les bouts performance-critiques en C en passant par une FFI toute moche reposant sur des détails internes de l'implémentation précédente, et t'es mort. C'est pour ça que les projets style Rubinius, JRuby, Pypy et compagnie ont la vie dure.

    • [^] # Re: Utilité ?

      Posté par  . Évalué à 2.

      Ah oui, et zut aux gens qui ont "inutilé" ton post à 0 alors que la question est légitime et que la dépêche ou les liens qu'elle fournit ne lui apporte pas vraiment de réponse claire.

      • [^] # Re: Utilité ?

        Posté par  . Évalué à 3.

        Même si je n'approuve pas, je pense que l'inutilage était dû au fait que la question revient à chaque nouvelle sur JRuby/Jython (même si c'est rarement aussi bien expliqué que ton post).

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

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