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

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

23
jruby performance ruby ruby-on-rails

6 ответов

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

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

например, согласно Компьютерные Языковые Тесты Игры:

кроме того, если ваше приложение является многопоточным, JRuby может иметь некоторые преимущества над стандартом Руби!--6-->
(a.к. a. MRI)], в зависимости от того, сколько у вас ядер.

22

последние тесты поставили JRuby во главе, затем MagLev, Rubinius, затем MRI.

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

RBS

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

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

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

22

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

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

2

есть действительно отличная статья, сделанная ребятами в programmingzen.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/

2

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

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

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

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

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

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

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

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

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

2

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

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

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

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

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

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

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

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

опять же, я не уверен, что скорость является самым важным фактором при выборе между МРТ и JRuby. Это экосистема. Раз уж вы попросили скорости, я не буду вдаваться в подробности.

2