Есть ли преимущество в запуске JRuby, если вы не знаете Java?

Question

Я слышал замечательные вещи о JRuby, и я знаю, что вы можете запустить его, не зная Java. Мои навыки разработки сильны, Java просто не один из инструментов, которые я знаю. Это массивный инструмент с множеством сопутствующих инструментов, таких как Maven / Ant / JUnit и т. Д.

Стоит ли переносить мои текущие Rails-приложения на JRuby только по соображениям производительности? Возможно, если я возьму немного базовой Java вместе с ней, могут быть такие дополнительные преимущества, которые неочевидны, например, лучшие инструменты отладки / оптимизации производительности?

Хотелось бы получить совет по этому вопросу.

Answer 1

Я думаю, вы в значительной степени прибили это.

JRuby - это просто еще один механизм выполнения Ruby, такой же, как MRI, YARV, IronRuby, Rubinius, MacRuby, MagLev, SmallRuby, Ruby.NET, XRuby, RubyGoLightly, tinyrb, HotRuby, BlueRuby, Red Sun и все остальные.

Основные отличия:

• переносимость: например, YARV официально поддерживается только в 32-битной Linux x86. Он не поддерживается в OSX или Windows или 64-битной Linux. Рубиниус работает только в Unix, а не в Windows. JRuby OTOH работает везде : рабочие столы, серверы, телефоны, App Engine, вы называете это. Он работает на виртуальных машинах Oracle JDK, OpenJDK, IBM J9, Apple SoyLatte, RedHat IcedTea и Oracle JRockit (и, возможно, еще нескольких, о которых я забыл), а также на виртуальной машине Dalvik. Он работает на Windows, Linux, OSX, Solaris, нескольких BSD, других проприетарных и открытых Unices, OpenVMS и нескольких ОС мэйнфреймов, Android и Google App Engine. Фактически, в Windows JRuby проходит больше тестов RubySpec, чем сам "Ruby" (то есть MRI или YARV)!

• расширяемость: программы на Ruby, работающие на JRuby, могут использовать любую произвольную библиотеку Java. Через JRuby-FFI они также могут использовать любую произвольную C-библиотеку. А благодаря новой поддержке расширений C в JRuby 1.6 они могут даже использовать большое подмножество расширений MRI и YARV C, например, Mongrel. (И обратите внимание, что библиотеки «Java» или «C» на самом деле не означают написанные на этих языках, они означают только API Java или C. Они могут быть написаны на Scala, Clojure, C ++ или Haskell.)

• инструмент: всякий раз, когда кто-то пишет новый инструмент для YARV или MRI (например, memprof), оказывается, что 5 лет назад у JRuby уже был инструмент, который делает то же самое, только лучше. В экосистеме Java есть некоторые из лучших инструментов для «понимания поведения во время выполнения» (это термин, который я только что придумал, под которым я имею в виду гораздо больше, чем просто профилирование, я имею в виду инструменты для глубокого понимания того, что именно ваша программа делает во время выполнения, каковы его характеристики производительности, где существуют узкие места, куда идет память, и, что наиболее важно, почему все это происходит) и визуализация, доступная на рынке, и в значительной степени все это работает с JRuby, по крайней мере, в некоторой степени.

• развертывание: при условии, что в вашей целевой системе уже установлена ​​JVM, развертывание приложения JRuby (и я говорю не только о Rails, я также имею в виду настольные, мобильные и другие виды серверов) буквально просто копирует один JAR (или WAR) и двойной щелчок.

• производительность: у JRuby гораздо больше накладных расходов при запуске. Взамен вы получаете намного более высокую пропускную способность. На практике это означает, что развертывание приложения Rails на JRuby является хорошей идеей, так же как и выполнение ваших интеграционных тестов, но для модульных тестов и сценариев разработчика лучше использовать MRI, YARV или Rubinius. Обратите внимание, что многие разработчики Rails просто разрабатывают и тестируют модули на MRI, тестируют интеграцию и разворачивают на JRuby. Нет необходимости выбирать один механизм исполнения для всего.

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

• платформ (это в некоторой степени связано с переносимостью): есть несколько удивительных платформ Java, например, Azul JCA с 768 гигабайтами оперативной памяти и 864 ядрами процессора, специально разработанными для безопасных для памяти, безопасных указателей, сборщиков мусора, объектно-ориентированных языков. Android. Google App Engine. Все они работают на JRuby.

Answer 2

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

Вам следует попробовать Rails.threadsafe! опция с одиночной средой исполнения JRuby (например, гем Trinidad с опцией --threadsafe).Мы слышали несколько историй, в которых он дает вам отличную производительность и низкое использование памяти, одновременно используя несколько процессорных ядер в одном процессе.

Answer 3

У Jruby есть преимущества, если вы используете Windows. Он поддерживает 64 бита, и вы можете использовать множество проприетарных баз данных со стандартными драйверами JDBC.

Answer 4

JRuby - одна из немногих реализаций, которая использует собственные потоки. Так что, если вы хотите сделать несколько многопоточности, пойти на это.

Что касается хостинга, вы должны поместить свое приложение в своего рода java-контейнер, который, на мой взгляд, гораздо менее прост, чем использование чего-то вроде пассажирского (для приложений Rack)

Я использую JRuby для приложения, когда мы общаемся через JMS, и оно работает нормально, но если бы я не использовал какую-либо Java, я бы, конечно, придерживался CRuby. Моя самая большая претензия в том, что при тестировании запуск тестов с JRuby длится вечно, так как вам приходится раскручивать виртуальную машину каждый раз, когда вы их запускаете. Это значительно усложняет TDD, так как это существенно влияет на время тестирования.

Answer 5

Последние выпуски значительно быстрее, чем Ruby, но также используют значительно больше памяти. Если это ваша единственная причина использования JRuby, я бы не стал беспокоиться, если бы у вас не было необходимости в конкретной производительности, которую он решает, просто потому, что, хотя он довольно популярен, он менее стандартен для хостинга и меньше людей его использует по сравнению со стандартным Рубин. При этом существует множество других причин для использования JRuby, таких как необходимость взаимодействия с существующим кодом Java и необходимость развертывания в средах, где Java была «благословлена» операционным отделом, а Ruby нет.