Ruby когда-либо будет *быстро*? [закрытый]

Maglev - это реализация на Ruby, основанная на существующем ядре Smalltalk, ориентированном на высшие уровни масштабирования и использования.

Он разработан, чтобы быть «значительно быстрее» существующих реализаций Ruby. Если вам интересно, вы можете посмотреть доклад одного из Maglev Architects .

Точно так же, как разные реализации Javascript работают быстрее или медленнее в разных браузерах, стоит отметить, что сам Ruby работает почти в два раза быстрее в Linux и Windows.

Нет, по двум причинам:

1. Даже если класс реализует интерфейс, он не делает его автоматически подсчитанным по ссылкам. Только если вы действительно используете его для реализации этого интерфейса, подсчет ссылок будет иметь какой-либо эффект.
2. Как уже было сказано другими: подсчет ссылок в интерфейсах приведет к немедленному освобождению экземпляра класса, когда счетчик ссылок достигнет 0. Это неявный вызов метода Free в этой точке кода. Это не удастся, например, если два объекта ссылаются друг на друга. Настоящая сборка мусора освобождает объекты не тогда, когда они выходят за пределы области видимости, а когда требуется память, поэтому не будет никакого влияния на производительность каждый раз, когда счетчик ссылок достигнет 0, поскольку объект просто продолжит существовать. Вдобавок хороший сборщик мусора обнаружит изолированные циклические ссылки (например,

Что ж, определенно есть что улучшить. Вот список тестов времени для моделирования N-тела (сложный математический алгоритм): http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=all

Ruby 1.9 занимает 34 минуты, тогда как один из более быстрых языков, дружественных к веб-серверам (C #), занимает всего 37 секунд. Итак, C # более чем в 50 раз быстрее для этой конкретной задачи. Можно было бы возразить, что это не тот тип задач, для которого в любом случае будет использоваться Ruby. Но все же остается вопрос масштабируемости.

Чтобы Ruby стал НАМНОГО быстрее, его действительно нужно каким-то образом скомпилировать. Это может происходить точно в срок, как в движке V8 Javascript. Или это может быть больше похоже на ASP.NET, которое поддерживает «кешированные» компиляции за кулисами. Другими словами, . NET может компилироваться «на лету», но при этом вы заметите, что на это требуется время. Но выигрыш в том, что его не нужно повторно компилировать, пока код не изменится, и, как показывает вышеприведенный тест, окончательный скомпилированный код выполняется очень быстро. Поэтому я думаю, что Ruby (или его вариант) в этом отношении лучше скопировать технику .NET.

Да, Ruby может стать быстрее - по крайней мере, до такой степени, что это больше не проблема.

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

Почему? Если он медленнее, чем что-либо сопоставимое, то есть способ сделать это быстрее, поэтому это возможно. И с той динамикой, которую имеет Ruby, она, вероятно, БУДЕТ быстрее.

Да, Ruby станет значительно быстрее.

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

MacRuby , Maglev или Rubinius могут быть первыми на рынке с такой скоростью, но реализация C будет вероятно, тоже попадет туда.

Следует отметить, что Дж. Руби одержим скоростью и имеет несколько «рубиновых» прототипы языки , которые позволяют разработчикам обменивать определенные функции для повышения производительности.

Честно говоря, главное, что сдерживает Ruby, - это то, что для многих, многих целей он уже достаточно быстр. Если вы хотите решить задачу о n телах , вам, вероятно, следует поискать в другом месте. Но если вы хотите создать удобное и удобное в обслуживании веб-приложение, Ruby поможет вам быстрее приступить к работе и с отличной ремонтопригодностью. И ваши венчурные капиталисты будут настолько впечатлены, что дадут вам достаточно денег для масштабирования. В этот момент вы можете переписать свои узкие точки на встроенный C или Java.

Если вы хотите создать удобное и удобное в обслуживании веб-приложение, Ruby поможет вам быстрее приступить к работе и с отличной ремонтопригодностью. И ваши венчурные капиталисты будут настолько впечатлены, что дадут вам достаточно денег для масштабирования. В этот момент вы можете переписать свои узкие точки на встроенный C или Java.

Если вы хотите создать удобное и удобное в обслуживании веб-приложение, Ruby поможет вам быстрее приступить к работе и с отличной ремонтопригодностью. И ваши венчурные капиталисты будут настолько впечатлены, что дадут вам достаточно денег для масштабирования. В этот момент вы можете переписать свои узкие точки на встроенный C или Java.

Ruby становится быстрее

В то время как jRuby часто затирается в простых тестах, с включенной опциональной оптимизацией он начинает выглядеть хорошо.

Официальным интерпретатором Ruby теперь является YARV, хотя большинство людей еще не испытали этого, потому что они все еще используют 1.8.

JRuby имеет компилятор jrubyc, который может создавать файлы jvm .class из рубиновые файлы. Я никогда не использовал его, только бегло просмотрел, поэтому я не знаю, какая часть Ruby поддерживается для компиляции байт-кода. Если он скомпилирован до байт-кода, то jvm следует оптимизировать так же, как и любой другой байт-код.