Что быстрее: МРТ Рубин или JRuby?

Question

Если я использую Ruby on Rails, я должен установить MRI / YARV Ruby или JRuby? Что быстрее?

Answer 1

Последние тесты ставят JRuby в лидеры, затем идут MagLev, Rubinius, затем MRI.

Бенчмаркинг сложно. Ruby Benchmark Suite - это то, что чаще всего используется для тестирования Ruby. Если вы удалите все тесты, которые не пройдут в любой реализации, вы получите следующий график.

Обратите внимание, я использовал среднее геометрическое. Это лучший показатель средней производительности, поскольку он нормализует выбросы и характеристики машины.

Лучший тест, который вы можете выполнить, будет зависеть от вашего приложения. Если вам нужна общая производительность, вы, вероятно, захотите использовать реальные потоки, поэтому Rubinius или JRuby - ваш единственный реальный выбор.

Кроме того, каждая реализация работает быстро в разных вещах. MRI очень быстро запускается, так что это хорошо для сценариев. Для более продолжительных приложений (например, веб-приложений) Rubinius или JRuby обычно работают лучше, чем MRI.

Answer 2

Ответ зависит от многих переменных.

Но в целом Ruby 1.9 работает быстрее, чем JRuby, а Ruby 1.8 медленнее, чем JRuby.

например. в соответствии с игрой Benchmarks Computer Language :

• Рубин 1,9 против JRuby
• Рубин 1,8 против JRuby

Кроме того, если ваше приложение является многопоточным, JRuby может иметь некоторые преимущества перед стандартным Ruby
(a.k.a. MRI)], в зависимости от того, сколько у вас ядер.

Answer 3

Многие пользователи уже ответили относительно тестов. Ваш вопрос специально для использования с Rails.

Я нахожу это необычным, поскольку не вижу чётко цели вопроса. Многие используют МРТ, многие используют JRuby и многие другие. Я бы пошел за стабильность, безопасность и ремонтопригодность в этом отношении, а не за скорость.

Однако между МРТ и JRuby есть важное различие.

МРТ использует GIL. Это означает, что, хотя у вас может быть несколько потоков, одновременно может быть активен только один поток. Также реализация потоков может отличаться в разных версиях Ruby. В более новых версиях используются потоки ОС (хороший шаг вперед), в старых версиях вместо этого используются зеленые потоки.

В МРТ нет реального параллелизма.

МРТ является многопоточным, небезопасным и не параллельным.

JRuby является многопоточным, не поточнобезопасным и параллельным.

Параллелизм может изменить скорость. Оба не являются потокобезопасными, поэтому вам все равно придется позаботиться об этом. Если вы ищете скорость и можете использовать параллелизм, то я бы дал JRuby определенное Да.

Опять же, я не уверен, является ли скорость наиболее важным фактором при выборе между MRI и JRuby. Это экосистема. Поскольку ты просил скорости, я не буду вдаваться в подробности.

Answer 4

На самом деле ответ выше не верен, за исключением ответа Микеля. Если вы наблюдали какой-либо тест для JVM, вы обнаружите, что он медленный, поэтому представьте производительность JRuby по сравнению с CRuby.

Лично я являюсь участником MRI Ruby, и я думаю, что приведенная выше таблица эталонных тестов вообще не соответствует действительности с момента появления виртуальной машины YARV для MRI Ruby, эта версия стала самой быстрой, и множество тестов подтвердили это. Сравнительный тест и комментарии Шонесси о трех известных интерпретаторах Ruby: MRI Ruby, JRuby и Rubinius ". Так что на мой взгляд нет смысла сравнивать из-за следующих логических моментов: -

1 - C намного быстрее, чем Java, потому что он работает непосредственно на аппаратном обеспечении и производит машинный код. В то время как JVM выдает Байт-код, который считается промежуточным кодом.

2- JRuby содержит дополнительный шаг интерпретации, в отличие от MRI Ruby «Tokenization, Parsing, AST Parsing и генерация инструкций YARV« Генерация кода »и, наконец, выполнение кода», в то время как JRuby содержит дополнительный этап.

3 - Сборка мусора в MRI Ruby намного быстрее, чем сборка мусора в JRuby, даже лучше, когда они внесли некоторые изменения в технику сбора меток и уборки мусора.

4 - Если вы просматривали большинство компаний и используемых технологий, они всегда использовали MRI Ruby, особенно ruby ​​1.9, я редко видел компанию, использующую JRuby, или даже видел множество расширений или дополнений к ней в отличие от MRI Ruby.

Наконец, Ruby 1.8, да, это медленнее, потому что они выполняли код на самом AST, поэтому они много раз анализировали AST, чтобы выполнить код.

Если я в чем-то ошибаюсь, надеюсь, кто-нибудь меня поправит.

Установите MRI Ruby Dude, используя RVM или из источника. Вы найдете множество драгоценных камней и расширений для работы с

Answer 5

Ребята на сайтеzenzen.com сделали отличную статью, в которой сравниваются различные варианты ruby. Был опубликован в июле прошлого года, так что все еще достаточно недавно;) Там страница сравнивает эти:

* 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

Может быть, там можно найти то, что вы ищете

http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/

Answer 6

Честно говоря, это зависит от вашего кода. Установите RVM или Pik на свой компьютер, установите несколько разных версий ruby ​​и попробуйте запустить в них свой код.

Например: приложение, которое часто перезапускается, не является подходящим кандидатом на JRuby, так как у JRuby есть некоторое время для разгона, прежде чем Hotspot сможет эффективно оптимизировать ваш код. Аналогично, приложение, которое опирается на потоки, не является хорошим кандидатом для Ruby 1.8.7, поскольку Ruby 1.8.X не может использовать более одного ядра на вашем процессоре и, следовательно, не может выполняться более чем в одном потоке за раз.