Рубинус или МРТ 1.9.3 (ЯРВ)?

Итак, у меня есть несколько вопросов, которые я должен задать, я просматривал Интернет, но надежных ответов было не так уж много. В основном это посты в блогах, которые исключали друг друга, потому что они хвалили разные вещи и имели контрольные показатели для «подтверждения своей точки зрения» (я никогда в жизни не видел столько противоречащих контрольных показателей).

В любом случае, мои вопросы:

Несколько "бонусных" вопросов:

Прошу прощения за этот текстовый шторм, который я обрушил на вас! ♥


person omninonsense    schedule 03.11.2012    source источник
comment
Хороший вопрос. я бы ответил, если я новый ответ!   -  person Linuxios    schedule 03.11.2012
comment
Это действительно должно быть несколько вопросов. Вы также не показали никаких собственных исследований по ним.   -  person millimoose    schedule 03.11.2012
comment
Я имею в виду, что ответ на ваш вопрос о расширениях находится прямо на домашней странице Rubinius.   -  person millimoose    schedule 03.11.2012
comment
Что касается избавления от GIL, судя по обсуждению Python, ответ, вероятно, не очень вероятен. Интерпретатор Python поддерживает очень сложные внутренние структуры данных, попытки синхронизировать доступ к ним на мелкозернистом уровне привели к неприемлемому снижению производительности. Не будет преувеличением предположить, что с Ruby ситуация такая же.   -  person millimoose    schedule 03.11.2012
comment
@millimoose 1. Все вопросы тесно связаны. Зачем засорять ТАК? Это также облегчает поиск ответов для тех, кто находится в положении, подобном моему. 2. Все исследования в основном состоят из очень самоуверенных постов в блогах, в которых утверждается, что x — это круто, а y — отстой, и из очевидно предвзятых статей о той или иной реализации. 3. Все, что говорится в этой ссылке, это то, что они хотят быть совместимыми с C API, и до некоторой степени так и есть. Я лично не считаю это достаточной информацией или доказательством. 4. Спасибо за полезный комментарий по поводу моего вопроса, связанного с GIL.   -  person omninonsense    schedule 03.11.2012
comment
@starship: 1. Зачем ТАК захламлять? Потому что сфокусированные вопросы удобного размера легче искать в Google и на них легче писать ответы. 2. Под исследованием я имел в виду установить его и попробовать нужные вам расширения самостоятельно. Сообщения в блогах предвзяты, потому что между ними так много различий, что исчерпывающая объективная оценка становится неразрешимой задачей. Определить, хорошо ли это для ваших целей, нельзя, если вы знаете, каковы ваши требования к реализации.   -  person millimoose    schedule 03.11.2012
comment
@starship 3. Вы отредактировали свой пост, упомянув, что расширения C — это написанные вами. Как вы ожидаете, что кто-то еще скажет вам, работает ли расширение, которое они не могут установить и протестировать? Тем не менее, я считаю, что одной из целей разработки Rubinius является ускорение работы кода Ruby с хрустом чисел. Возможно, это сделает вашу реализацию последнего кода на Ruby достаточно быстрой. (Опять же, чтобы узнать это, нужно провести тест и сравнить.)   -  person millimoose    schedule 03.11.2012
comment
Насколько я понимаю, Rubinius компилирует ruby ​​в байт-код, затем использует виртуальную машину JIT, и что компиляция в байт-код выполняется в ruby, но сама виртуальная машина написана на C++, поэтому при выполнении вы получаете преимущество скорости C++, но язык высокого уровня используется для выполнения более сложной задачи разбора и компиляции исходного кода.   -  person Thayne    schedule 17.01.2014


Ответы (2)


Действительно ли Рубиний быстрее?

В большинстве тестов да. тесты RBS с ошибками

Эталонные показатели RBS без ошибок

Но бенчмарки... тупые. Приложения — это то, о чем мы действительно заботимся. Так что лучше всего протестировать ваше приложение и посмотреть, насколько хорошо оно работает. Две области, в которых Rubinius действительно будет блистать по сравнению с МРТ, — это параллелизм и использование памяти. У Rubinius нет GIL, поэтому вы можете использовать все доступные потоки. Он также имеет гораздо более сложный сборщик мусора, так что в целом он может работать лучше по отношению к GC.

Я сделал эти тесты еще в октябре 2011 года для моего выступления о MagLev на RubyConf

Работает ли EventMachine с Rubinius?

Да, и если есть части, которые не работают, то следует сообщить о проблеме. При этом в настоящее время тесты EM не проходят никакую реализацию Ruby.

Работают ли расширения C в Rubinius?

да. Я занимаюсь проблемой совместимости для C-exts, поэтому, если у вас есть протестирован на Трэвисе, Рубиниус хотел бы, чтобы он прошел против rbx. Исторически у Rubinius была хорошая поддержка C-api и C-exts, хотя было бы неплохо, если бы когда-нибудь Rubinius смог запустить Ruby настолько быстро, что C-exts или C-api не понадобились бы.

Избавится ли C-Ruby (2.0+, YARV) от GIL? Или, по крайней мере, изменить его, чтобы CRuby поддерживал настоящий параллелизм?

Нет, скорее всего нет. Джесси Стоример сделал краткий обзор мнения Маца (или его отсутствия) в тредах с RubyConf 2012. Коичи Сасада однажды попытался удалить GIL, и производительность МРТ просто упала. Эван Феникс тоже пытался один раз, до того, как создал Рубиния, но не добился хороших результатов.

Что такое мруби?

Встраиваемый интерпретатор Ruby, похожий на Lua. У Мэтта Аймонетти есть несколько статей, которые могут пролить на вас некоторый свет.

person jc00ke    schedule 03.02.2013
comment
О, этот ответ гениален! :D Большое спасибо! - person omninonsense; 04.02.2013

Я не слишком увлекаюсь Ruby, но, возможно, смогу ответить на первый вопрос.

Действительно ли Рубиний быстрее?

Я видел, как разные тесты говорят о разных вещах. Однако тот факт, что Rubinius частично написан на Ruby, не означает, что он медленнее. То же самое я думал о PyPy, который является Python в Python. После некоторых исследований и правильных занятий в колледже я понял, почему.

  • Насколько я знаю, оба написаны на подмножестве своего языка, который должен быть намного проще. Интерпретатор (например, C) может быть оптимизирован для такого подмножества гораздо проще, чем для всего языка.
  • Написание интерпретатора Ruby/Python на собственном языке обеспечивает большую гибкость и более быстрое создание прототипов новых алгоритмов интерпретации. Весь смысл существования Ruby и Python, среди прочего, в том, что алгоритмы могут быть реализованы намного быстрее, чем, например, в. Си или даже ассемблер. Более быстрый алгоритм часто перевешивает небольшие накладные расходы интерпретатора.

Кстати. написание интерпретатора для языка на том же языке также является обычной академической практикой, чтобы показать, насколько могущественным является язык. В одном классе мы написали Лисп на Лиспе на Лиспе.

person Karsten    schedule 06.11.2012
comment
Я не могу сказать, что это полностью отвечает на мой вопрос, но поскольку он единственный и отвечает на часть вопроса, я отмечу его как принятый. Спасибо! - person omninonsense; 09.11.2012
comment
Ну, сложно сразу ответить на все ваши вопросы :). Ответ на ваш вопрос о mruby можно найти на Github: Что такое mruby? mruby — это облегченная реализация языка Ruby, соответствующая (частично) стандарту ISO. mruby можно связать и встроить в ваше приложение. Таким образом, кажется, что его основное использование будет заключаться в улучшении приложений с помощью некоторых сценариев Ruby, таких как Lua. Думайте об этом как о расширениях C наоборот. Вместо использования библиотек C в Ruby вы можете использовать Ruby в своей программе на C. Это только предположение. - person Karsten; 09.11.2012