ruby on rails - ¿Cuál es más rápido: MRI Ruby o JRuby?
ruby-on-rails performance (6)
En realidad, la respuesta anterior no es correcta, excepto la respuesta de Mikel. Si observaste un punto de referencia para JVM, verás que es lento, así que imagina el rendimiento de JRuby en comparación con CRuby.
Personalmente, soy colaborador de Ruby en MRI y creo que el cuadro de referencia anterior no es cierto en absoluto desde la introducción de la máquina virtual YARV VM de Ruby en RMN. Esta versión se convirtió en la más rápida y muchos de los puntos de referencia demostraron que "Vea la evaluación comparativa de Pat Shaughnessy y comentarios sobre los tres famosos intérpretes de Ruby MRI Ruby, JRuby y Rubinius ". Entonces, en mi opinión, no hay un punto de comparación debido a los siguientes puntos lógicos:
1- C es mucho más rápido que Java porque opera directamente en Hardware y produce código de máquina. Mientras que JVM produce Bytecode que se considera código intermedio.
2- JRuby contiene un paso de interpretación adicional a diferencia de MRI Ruby "Tokenization, Parsing, AST Parsing y generación de instrucciones YARV" Generación de código "y finalmente Ejecución de código" Mientras que JRuby contiene una etapa adicional.
3- Recolección de basura en MRI Ruby es mucho más rápida que la recolección de basura en JRuby, incluso mejoró cuando introdujeron algunos cambios en la técnica de recolección de basura de marca y barrido.
4- Si navegó por la mayoría de las compañías y las tecnologías utilizadas, siempre usaron MRI Ruby particularmente ruby 1.9, rara vez vi una compañía que usaba JRuby o incluso vi muchas extensiones o contribuciones a diferencia de MRI Ruby.
Finalmente, Ruby 1.8 sí es más lento porque estaban ejecutando el código en el propio AST, por lo que solían analizar el AST varias veces para ejecutar el código.
Si me equivoco en algo espero que alguien me corrija.
Instale MRI Ruby dude usando RVM o desde la fuente. Encontrarás muchas gemas y extensiones para trabajar
Si estoy usando Ruby on Rails, ¿debo instalar MRI / YARV Ruby o JRuby? ¿Cual es mas rápido?
Hay un artículo realmente genial hecho por los chicos de programaciónzen.com que compara muchos de los diferentes sabores del rubí. Se publicó en julio del año pasado, por lo que todavía es relativamente reciente;) En esta página se comparan estos:
* Ruby 1.8.7 p299
* Ruby 1.9.1 p378
* Ruby 1.9.2 RC2
* IronRuby 1.0 (Mono 2.4.4)
* JRuby 1.5.1 (Java HotSpot(TM) 64-Bit Server VM 1.6.0_20)
* MagLev (rev 23832)
* Ruby Enterprise Edition 2010.02
* Rubinius 1.0.1
Podrías encontrar lo que buscas allí.
http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/
Honestamente, depende de tu código. Instale RVM o Pik en su máquina, instale un montón de versiones diferentes de ruby e intente ejecutar su código en ellas.
Por ejemplo: una aplicación que se reinicia con frecuencia no es un gran candidato para JRuby, ya que JRuby tiene un tiempo de recuperación antes de que Hotspot pueda optimizar efectivamente su código. Del mismo modo, una aplicación que se basa en subprocesos no es un gran candidato para Ruby 1.8.7, ya que Ruby 1.8.X no puede utilizar más de 1 núcleo en su procesador y, por lo tanto, no puede ejecutar más de un subproceso a la vez.
La respuesta depende de muchas variables.
Pero en general, Ruby 1.9 es más rápido que JRuby, pero Ruby 1.8 es más lento que JRuby.
Por ejemplo, de acuerdo con el juego de puntos de referencia de lenguaje de computadora
Además, si su aplicación es multihebra, JRuby puede tener algunas ventajas sobre Ruby estándar.
(también conocido como MRI)], dependiendo de cuántos núcleos tengas.
Los últimos puntos de referencia pusieron a JRuby a la cabeza, seguido de MagLev, Rubinius y luego MRI.
Benchmarking es complicado. Ruby Benchmark Suite es lo que más se usa para evaluar a Ruby. Si elimina cualquier punto de referencia que falla en cualquier implementación, obtendrá el siguiente gráfico.
Note que usé la media geométrica. Este es un mejor indicador del rendimiento promedio, ya que normaliza los valores atípicos y las especificaciones de la máquina.
El mejor punto de referencia que puede ejecutar será específico para su aplicación. Si buscas un rendimiento general, es probable que desees utilizar hilos reales, por lo que Rubinius o JRuby son tus únicas opciones reales.
Además, cada implementación es rápida en diferentes cosas. La RM es muy rápida en el inicio, por lo que es buena para las secuencias de comandos. Para aplicaciones de ejecución más larga (como una aplicación web), Rubinius o JRuby generalmente tendrán un mejor desempeño que la MRI.
Muchos usuarios ya respondieron en cuanto a los puntos de referencia. Su pregunta es específicamente para el uso con Rails.
Me parece inusual ya que no veo claramente el objetivo de la pregunta. Hay muchos por ahí usando MRI y muchos usando JRuby y muchos otros. Prefiero la estabilidad, la seguridad y la capacidad de mantenimiento a ese respecto, no a la velocidad.
Sin embargo, hay una diferencia importante entre MRI y JRuby.
MRI utiliza una GIL. Esto significa que, aunque puede tener varios subprocesos, solo un subproceso puede estar activo a la vez. También la implementación de hilos puede diferir en diferentes versiones de Ruby. Las versiones más nuevas usan subprocesos del sistema operativo (buen paso adelante), las versiones más antiguas usan subprocesos verdes en su lugar.
No hay un paralelismo real en la resonancia magnética.
La RM es multiproceso, no es segura y no es paralela.
JRuby es multihilo, no es seguro y paralelo.
El paralelismo puede hacer una diferencia en la velocidad. Ambos no son seguros para subprocesos, por lo que tendrá que cuidar de todos modos. Si buscas velocidad y puedes explotar el paralelismo, entonces le daré a JRuby un Sí definitivo.
Nuevamente, no estoy seguro de si la velocidad es el factor más importante al decidir entre MRI y JRuby. Es el ecosistema. Ya que pediste velocidad no entraré más en esto.