Comments 50
Неужели VM сделали? )
Да, используется YARV.
Основная проблема нового руби это то, что гемов под него очень и очень мало (к слову: последние рельсы его держат.). Так что сейчас имеет смысл переползать разве что на REE.
Правда, как мне тут сказал знакомый админ с x86_64 у него плохо
UFO just landed and posted this here
«No, tcmalloc doesn’t work on 64-bit. But the copy-on-write patches still do, they just aren’t as effective without tcmalloc. So on 32-bit systems (with tcmalloc) you get about 33% memory savings, while on 64-bit systems (without tcmalloc) you get about 25% memory savings.»
blog.phusion.nl/2008/12/05/ruby-enterprise-edition-186-20081205-released-thank-you-sponsors/
blog.phusion.nl/2008/12/05/ruby-enterprise-edition-186-20081205-released-thank-you-sponsors/
UFO just landed and posted this here
Ну там не такие острые проблемы с совместимостью — просто никто не тестирует, ждут финальный релиз :).
«Среднее геометрическое»? :)
См. статью в Википедии. По поводу точности — я там привёл и просто суммарное время. Прирост, если мерить «в лом» тоже неплохой — 4,12. Признаюсь сразу: «за что взял, за то и продаю», аргументировать этот метод не могу, его привёл сам автор сравнения в тестах.
Признаюсь сразу: «за что взял, за то и продаю», аргументировать этот метод не могу, его привёл сам автор сравнения в тестах.вот-вот. Может быть и можно взять какие-то числа из первого графика и с помощью среднего геометрического получить второй, но мой невооружённый взгляд скорее говорит о том, что на втором графике показан прирост в разах относительно Ruby 1.8.7. Так что автор сих рисунков думал о чём-то отвелечённом, когда подписывал график. Буду рад если вы расскажете, при чём же там среднее геометрическое на самом деле :)
На самом деле, из текста статьи понятно, при чём там среднее геометрическое, вот только вот в вашем тексте это не отражено, и потому подпись к графику выглядит не к месту :)
А ещё есть среднее гармоническое, и не только… :)
Теперь руби выглядит значительно интереснее.
интересно, кто-нибудь сподобится портировать хотя бы часть бенчмарка на groovy 1.6-beta для сравнения по скорости ruby vs jruby vs groovy?
Прошу, только там более старая версия JRuby. Учитывая сравнение Ruby vs. JRuby, такое ощущение, что они JRuby без -J-server запускают или учитываю запуск JVM на каждом тесте.
там всё-таки другие бемчмарки, да и версии там старые
есть ещё, кстати, shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=jruby
интереснее всего было бы сравнить именно на «родных» бенчмарках. я б портировал, но я в ruby не силён :(
есть желающие помочь?
есть ещё, кстати, shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=jruby
интереснее всего было бы сравнить именно на «родных» бенчмарках. я б портировал, но я в ruby не силён :(
есть желающие помочь?
Это же насколько медленно он должен был быть реализован, чтобы его можно было бы ускорить в N раз?.. О_о
Напиши сначала интерпретатор, а потом VM — сравни, и поймёшь.
У Ruby был довольно простой интерпретатор. Новый Ruby 1.9.1 не интерпретирует и постоянно смотрит в код (дерево кода), а компилирует исходник в байт-код и потом уже выполняет. Такой подход практически всегда даёт колоссальный прирост производительности.
Пожалуй, времени и энтузиазма моего на подобный подвиг не хватит… Вы меня заинтересовали сравнением, почитал статьи. Интересно, из чисто скриптового, интерпретируемого языка — не станет ли он компилируемым, хотя бы и в байт код?..
вообще говоря, 1.9 примерно это и делает. Ruby-код сначала транслируется во внутреннее представление, а потом это внутреннее представление исполняется. Таким образом появляется возможность:
а) оптимизировать код перед исполнением.
б) кэшировать уже оттранслроанные участки кода.
а) оптимизировать код перед исполнением.
б) кэшировать уже оттранслроанные участки кода.
Уже можно с помощью JRuby получить из текстовых Ruby-исходников class-файлы с байт-кодом под Java.
UFO just landed and posted this here
А можете просвятить не-программиста?
Мы разрабатываем интернет проект на рельсах, Руби там естественно не 1.9.1, а какой-то иной, более старый. Так вот вопрос: можно ли простой переустановкой заменить старый Руби на новую версию, и будет ли от этого в итоге быстрее работать сам сайт? (извините заранее за возможно глупую постановку вопроса)
Мы разрабатываем интернет проект на рельсах, Руби там естественно не 1.9.1, а какой-то иной, более старый. Так вот вопрос: можно ли простой переустановкой заменить старый Руби на новую версию, и будет ли от этого в итоге быстрее работать сам сайт? (извините заранее за возможно глупую постановку вопроса)
В руби 1.9 есть небольшие изменения языка: надо перепроверять, что проект будет работать. Основная проблема с ним — сторонние библиотеки, они еще не все совместимы.
Без дополнительных исправлений в коде можно использовать REE (http://www.rubyenterpriseedition.com/). Есть еще стабильная верси JRuby, но сложно сказать насколько ее можно использовать для production.
Без дополнительных исправлений в коде можно использовать REE (http://www.rubyenterpriseedition.com/). Есть еще стабильная верси JRuby, но сложно сказать насколько ее можно использовать для production.
UFO just landed and posted this here
UFO just landed and posted this here
Ждем в shootout shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python&lang2=ruby
Пока руби отличает еще и пожирание памяти — в 5 — 10 раз больше пайтона. + странная работа GC, когда объектов осталось мало, а не собраный мусор в пару сотен метров висит неделями.
Пока руби отличает еще и пожирание памяти — в 5 — 10 раз больше пайтона. + странная работа GC, когда объектов осталось мало, а не собраный мусор в пару сотен метров висит неделями.
Наверное, более правильная ссылка — shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=python. Только там более старая версия Ruby 1.9.
Странно — а приведённые вами тесты по ссылке вот этого:
совершенно не показывают.
Пока руби отличает еще и пожирание памяти — в 5 — 10 раз больше пайтона.
совершенно не показывают.
Sign up to leave a comment.
Новая версия Ruby быстрее до 5 раз