Rubinius 1.0 est sorti

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
19
15
mai
2010
Ruby
Rubinius est une implémentation du langage de programmation Ruby, dont le code est placé sous licence BSD. Rubinius permet d'exécuter du code Ruby, mais vise également les objectifs suivants :
  • Rubinius est Threadsafe ;
  • Son code est propre, lisible, facile à comprendre et à étendre ;
  • Il est fiable et solide (avec l'aide de Valgrind) ;
  • Et surtout, il apporte les dernières avancées de la recherche sur les machines virtuelles, les ramasses-miettes et les compilateurs à Ruby.
Le développement de Rubinius a commencé en novembre 2006 et, aujourd'hui, une étape importante a été franchie : la sortie de la version 1.0. Celle-ci marque la compatibilité avec Ruby 1.8.7, y compris Ruby on Rails (aussi bien la version 2.3 et que la version 3), Rspec, Rubygems, les bibliothèques Ruby et même une grande partie des extensions codées en C.

D'un point de vue plus technique, Rubinius est écrit majoritairement en Ruby, et pour les parties où ce n'est pas (encore) possible en C++. Il fonctionne avec une machine virtuelle dont le bytecode est transformé en code machine à l'exécution grâce à LLVM et utilise un garbage collector générationnel, précis et compactant. Et pour ceux qui seraient d'humeur taquine, je ne résiste pas à l'envie de mettre un petit lien vers un benchmark. Vous pouvez voir que Rubinius est l'implémentation Ruby la plus rapide, ou du moins, l'était en janvier quand le benchmark a été fait.

Si vous êtes convaincus, vous pouvez installer Rubinius soit en suivant les instructions officielles, soit en utilisant Ruby Version Manager. Je recommande d'utiliser la seconde solution, car RVM vous permet d'installer plusieurs implémentations de Ruby sur la même machine, d'installer des gems pour chacun d'eux et de passer d'une implémentation à l'autre sans problème. Le projet Rubinius mérite également d'être mis en avant pour son modèle particulièrement ouvert. Evan Phoenix, qui est à l'origine du projet, a non seulement mis en place les outils utiles à un projet Libre (mailing-list, canal IRC, suivi des bugs, guide du contributeur, etc.), mais a également su attirer de nombreux contributeurs (pas loin de 150 d'après github). En particulier, une règle essentielle a été mise en place : toute personne qui soumet un patch se voit accorder le droit de commiter sur le projet dès que le patch est accepté.

Un autre aspect de cette ouverture est la création de RubySpec. RubySpec consiste en l'écriture de spécifications complètes et exécutables du langage de programmation Ruby. Ces spécifications, majoritairement écrites par l'équipe de Rubinius, sont maintenant utilisées par toutes les principales implémentations de Ruby : la version officielle de Ruby (parfois nommée MatzRuby), YARV (la branche 1.9 de Ruby), JRuby, IronRuby et MacRuby.

Aller plus loin

  • # Question de béotien

    Posté par  . Évalué à 10.

    YARV et Rubinius semble partager l'objectif d'être une implantation performante de Ruby via une VM « native » (à l'inverse de JRuby), mais YARV est le futur Ruby « officiel », béni par Matz. Un rapprochement des deux serait-il possible en théorie, ou quelque-chose m'échappe dans les buts fondamentaux des deux projets ?

    • [^] # Re: Question de béotien

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

      Ruby 1.9, anciennement YARV, a pour objectif premier les performances, et a fait des concessions sur d'autres points pour y arriver (casser la compatibilité avec Ruby 1.8 par exemple). Rubinius cherche également à devenir une implémentation performante de Ruby, mais a également d'autres buts : un maximum de code doit être écrit en Ruby, par exemple.

      D'un point de vue technique, Ruby 1.9 est écrit majoritairement en C, avec quelques classes de la bibliothèque standard en Ruby. Rubinius est écrit en Ruby, et là où ce n'est pas possible d'utiliser du Ruby, en C++. Les 2 VM ont également des bytecodes différents.

      En pratique, cela veut dire qu'il est peu probable que les 2 projets échangent beaucoup de code, mais les développeurs partagent les idées et retours d'expérience.

      • [^] # Re: Question de béotien

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

        Rubinius c'est donc l'équivalent Ruby de PyPy non ?

        • [^] # Re: Question de béotien

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

          > Rubinius c'est donc l'équivalent Ruby de PyPy non ?

          Je ne connais pas très bien PyPy, mais ça m'en a tout l'air.

          D'ailleurs, des rubyistes pensent que Rubinius est l'avenir de Ruby, et je viens de tomber sur un billet qui dit que PyPy est le futur de Python : http://alexgaynor.net/2010/may/15/pypy-future-python/

          • [^] # Re: Question de béotien

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

            L'utilisation de LLVM permet-t-il à Rubinius de compiler du code Ruby comme Clang le fait ?
            Parce que la distribution des scripts Ruby est une vraie misère (surtout dans l'univers Windows)...

            • [^] # Re: Question de béotien

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

              > L'utilisation de LLVM permet-t-il à Rubinius de compiler du code Ruby comme Clang le fait ?

              Pas à ma connaissance, mais peut être qu'en creusant un peu, c'est possible.

              > Parce que la distribution des scripts Ruby est une vraie misère (surtout dans l'univers Windows)...

              Il existait un programme qui permettait de créer un exécutable windows à partir du code Ruby et qui embarquait l'interpréteur Ruby et les dépendances. Du coup, ça faisait un .exe que l'on pouvait lancer sur n'importe quel windows sans avoir rien à installer auparavant. Je ne me rappelle plus du nom de ce programme, et je ne saurais pas dire s'il est encore maintenu (la dernière fois que je l'ai croisé, ça doit remonter à 3 ou 4 ans).

              • [^] # Re: Question de béotien

                Posté par  . Évalué à 2.

                MacRuby basé sur LLVM permet de sortir des binaires, mais il n'est pas encore porté sur d'autre OS que OSX (mais en principe rien ne l'empêche).

        • [^] # Re: Question de béotien

          Posté par  . Évalué à 3.

          D'après la dépêche, il y a une grosse différence avec PyPy :

          Le projet Rubinius mérite également d'être mis en avant pour son modèle particulièrement ouvert. [...] a également su attirer de nombreux contributeurs (pas loin de 150 d'après github).

          PyPy est plutôt fermé : s'il est facile d'avoir un accès commit (on me l'a filé alors que je n'avais rien demandé), les discussions de développement ont quasi toutes lieu en privé, le bug tracker n'est presque pas utilisé, la documentation est pauvre et le code très peu commenté (bref, incompréhensible).

  • # Plus performant, peut-être

    Posté par  . Évalué à 7.

    J'étais super enthousiaste, puis j'ai vu la consommation en mémoire vive.

    Déjà que redmine prends 250mio de ram sur mon serveur avec le ruby classique, et que dans le benchmark, rubinius peut consommer 4 fois plus de mémoire, je me demande ce que ça va donner.

    Envoyé depuis mon lapin.

    • [^] # Re: Plus performant, peut-être

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

      Je me pose la même question, et je crois que la seule manière de le savoir va être d'essayer.

      Ceci dit, je pense que Rubinius peut très bien s'en sortir sur de vraies applications. Par exemple, quand Redmine consomme 250Mo, une grande partie est simplement "perdue" par le garbage collector à cause de la fragmentation de la mémoire.

    • [^] # Re: Plus performant, peut-être

      Posté par  . Évalué à 1.

      En moyenne Rubinius est le plus rapide. Mais si on regarde dans le détail, il y a des types de cas où il le sera moins.

      Si dans une utilisation normale ces cas où ses performances sont mauvaises se rencontrent plus souvent que les cas où ses performances sont bonnes, nous ne nous retrouverons pas forcément avec le plus rapide. Il faut faire attention quand on utilise une agrégation de données à ne pas les interpréter trop rapidement.

      Sinon, je partage mes craintes sur l'utilisation de la Ram.

  • # ruby enterprise edition

    Posté par  . Évalué à 1.

    Y'a-t-il quelqu'un qui a pu comparer Rubinius avec Ruby Enterprise Edition ?

    Pour ma part, après avoir longtemps utilisé mongrel sur mon serveur, je suis passé à phusion passenger et ruby enterprise edition. Du coup l'utilisation RAM a énormément baissé. Je peux à présent gérer plusieurs dizaines de projets RoR sur le même serveur sans trop de soucis.

    Côté performance, je ne me suis pas vraiment penché sur le problème, mais ca me semble très correct. Le truc vraiment intéressant de R.E.E et phusion passenger c'est qu'une fois la VM lancée, une deuxieme instance RoR prend très peu de place supplémentaires.

Suivre le flux des commentaires

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