ruby - Rubinus o MRI 1.9.3(YARV)?

ruby-1.9 rubinius

Question

Entonces, tengo algunas preguntas que debo hacer, navegué por Internet, pero no hubo demasiadas respuestas confiables. Principalmente publicaciones de blog que se anularían mutuamente porque ambos elogiaron cosas diferentes y tenían puntos de referencia para "probar su punto de vista" ( Nunca he visto tantos puntos de referencia contradictorios en mi vida ).

De todos modos, mis preguntas son:

• ¿Es Rubinius realmente más rápido? Me impresionó bastante esta presentación en pro de Rubinius, aparentemente honesta. Otra cosa que me confunde un poco es que mucho Rubinius está escrito en Ruby, pero de alguna manera es más rápido que C-Ruby. ¡Debe ser una muy buena implementación del lenguaje, entonces!
• ¿Funciona EventMachine con Ruinius? Por lo que sé, EventMachine se basa parcialmente en Fibras (corríjame si me equivoco) que no se implementó hasta 1.9. Sé que Rubinius eventualmente apoyará 1.9, también; No me importa esperar un poco.
• ¿Las extensiones C funcionan en Rubinius? He escrito una extensión en C que "serializa" los mensajes binarios recibidos de un flujo de TCP a Ruby Objects y viceversa (supongo que los detalles no son importantes, pero si ayuda a responder esta pregunta actualizaré la publicación). ¡Esto puede ser un montón de mensajes! Logré escribir el mismo código en Ruby (aunque tenía poco sentido después de un mes), pero resultó ser un verdadero cuello de botella en la aplicación. Entonces, tuve que usar C como una "solución" a mi problema. EDIT : Acabo de recordar, uso C para otra tarea, es un método de prueba de éxito para Arrays. Básicamente, solo verifica si un "punto" está dentro de un polígono, fue increíblemente lento en CRuby.
• Si la respuesta anterior fue un "No", ¿hay una alternativa para las extensiones C en Rubinus? Recojo que la VM está escrita en C ++, para que luego.

Algunas preguntas "extra":

• ¿C-Ruby (2.0+, YARV) se librará de GIL? ¿O al menos modificarlo para que CRuby soporte el verdadero paralelismo?
• ¿Qué es exactamente mruby ? Veo que Matz está trabajando en ello, y en cuanto a la descripción parece bastante impresionante. ¿Qué tan diferente es de CRuby (rendimiento)?

¡Me disculpo por esta tormenta de texto que te desaté! ♥

Answer 1

¿Es Rubinius realmente más rápido?

En la mayoría de los puntos de referencia, sí.

Pero los puntos de referencia son ... tontos. Las aplicaciones son lo que realmente nos importa. Entonces, lo mejor que puede hacer es comparar su aplicación y ver qué tan bien funciona. Las 2 áreas en las que Rubinius realmente brillará con la RM son el paralelismo y el uso de memoria. Rubinius no tiene GIL, por lo que puedes utilizar todos los hilos disponibles. También tiene un GC mucho más sofisticado , por lo que en general podría funcionar mejor con respecto al GC.

Hice esos puntos de referencia en octubre del ''11 para mi charla sobre MagLev en RubyConf

¿Funciona EventMachine con Rubinius?

Sí, y si hay partes que no funcionan, entonces se debe informar el problema. Dicho esto, currently las pruebas de EM no pasan ninguna implementación de Ruby.

¿Las extensiones C funcionan en Rubinius?

Sí. Mantengo el problema de compatibilidad para los C-exts , por lo que si hay uno que está probado en Travis, a Rubinius le gustaría verlo pasar contra rbx. Rubinius históricamente ha tenido un buen soporte para los api-C y C-exts, aunque sería bueno si algún día Rubinius pudiera correr a Ruby tan rápido que uno no necesitaría C-exts o C-api.

¿C-Ruby (2.0+, YARV) se librará de GIL? ¿O al menos modificarlo para que CRuby soporte el verdadero paralelismo?

No, lo más probable es que no. Jesse Storimer escribió brevemente la opinión de Matz (o la falta de ella) en los hilos de RubyConf 2012. Koichi Sasada intentó eliminar el GIL una vez y el MRI se quedó en el tanque. Evan Phoenix también lo intentó una vez, antes de crear a Rubinius, pero no tuvo buenos resultados.

¿Qué es exactamente mruby?

Un intérprete de Ruby encajable, similar a Lua. Matt Aimonetti tiene algunos artículos que podrían arrojar algo de luz para ti.

Answer 2

No me gusta demasiado Ruby, pero puedo responder la primera pregunta.

¿Es Rubinius realmente más rápido?

He visto diferentes puntos de referencia diciendo cosas diferentes. Sin embargo, el hecho de que Rubinius esté parcialmente escrito en Ruby no significa que sea más lento. Pensé lo mismo acerca de PyPy, que es Python en Python. Después de algunas investigaciones y las clases correctas en la universidad, supe por qué.

• Que yo sepa, ambos están escritos en un subconjunto de su lenguaje que debería ser mucho más simple. Un intérprete (p. Ej., C) puede optimizarse mucho más fácilmente para un subconjunto de este tipo que todo el lenguaje.
• Escribir el intérprete de Ruby / Python en su propio idioma permite mucha más flexibilidad y un prototipado más rápido de los nuevos algoritmos de interpretación. El punto central de la existencia de Ruby y Python es, entre otros, que los algoritmos se pueden implementar mucho más rápido que en, por ejemplo, C o incluso ensamblador. Un algoritmo más rápido supera la pequeña sobrecarga de un intérprete la mayor parte del tiempo.

Por cierto escribir un intérprete para un idioma en el mismo idioma también es una práctica académica común para mostrar qué tan poderoso es el idioma. En una clase hemos escrito Lisp en Lisp en Lisp.