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

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

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

Неужели Rubinius действительно быстрее? Я был очень впечатлен этой, по-видимому, честной про-Rubinius-презентацией. Еще кое-что меня немного смущает, что много Rubinius написано в Ruby, но почему-то это быстрее, чем C-Ruby? Это должно быть довольно чертовски хорошая реализация языка, тогда!
Работает ли EventMachine с Ruinius? Насколько я знаю, EventMachine частично полагается на Fibers (исправьте меня, если я ошибаюсь), которые не были реализованы до 1.9. Я знаю, что Рубиний в конце концов поддержит 1,9; Я не против немного ждать.
Расширяются ли расширения C в Rubinius? Я написал расширение C, которое "сериализует" двоичные сообщения, полученные из потока TCP, в объекты Ruby и наоборот (я полагаю, что детали не важны, но если это поможет ответить на этот вопрос, я буду обновлять сообщение). Это может быть много сообщений! Мне удалось написать тот же код в Ruby (хотя после месяца он не имел никакого смысла), но он оказался настоящей бутылочной шейкой в приложении. Поэтому мне пришлось использовать C как "решение" для моей проблемы. EDIT: я только что вспомнил, я использую C для выполнения другой задачи, это метод тестовых тестов для массивов. В основном это просто проверяет, находится ли "точка" внутри многоугольника, это было невероятно медленным в CRuby.
Если предыдущий ответ был "Нет", есть ли альтернатива для C-расширений в Rubinus? Я собираю VM, написанную на С++, так что тогда.

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

Будет ли C-Ruby (2.0+, YARV) избавляться от GIL? Или, по крайней мере, изменить его так, чтобы CRuby поддерживал true parallelism?
Что такое mruby? Я вижу, что matz работает над этим, и, насколько это возможно, это выглядит довольно удивительным, Насколько отличается от CRuby (по производительности)?

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

Ответ 1

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

В большинстве тестов да.

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

Я сделал эти тесты еще в октябре '11 для мой разговор о MagLev на RubyConf

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

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

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

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

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

Нет, скорее всего, нет. Джесси Стоример имеет краткое изложение мнения Matz (или его отсутствия) по темам из RubyConf 2012. Koichi Sasada пытался удалить GIL один раз и MRI perf просто танк. Эван Феникс также пытался однажды, прежде чем он создал Рубиния, но не имел хороших результатов.

Что такое mruby?

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

Ответ 2

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

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

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

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

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