Вопрос по performance, ruby – Что делает Ruby медленным? [закрыто]

56

Руби медлителен в определенных вещах. Но какие его части являются наиболее проблемными?

Насколько сборщик мусора влияет на производительность? Я знаю, что у меня были случаи, когда запуск сборщика мусора занимал несколько секунд, особенно при работе с библиотеками OpenGL.

Я использовал математические математические библиотеки с Ruby, которые были особенно медленными. Есть ли проблема с тем, как ruby реализует базовую математику?

Есть ли в Ruby динамические функции, которые просто не могут быть эффективно реализованы? Если да, то как другие языки, такие как Lua и Python, решают эти проблемы?

Была ли недавняя работа, которая значительно улучшила производительность?

Я внес небольшое изменение, чтобы уменьшить аргументативный аспект вашей Q. Надеюсь, что работает для вас. Robert S.
Немного не по теме: если вы хотите использовать Ruby, но чувствуете, что его преследует его производительность, то разумнее всего сделать код критически важных компонентов с расширениями C. Конечно, с C вы можете даже перейти к ассемблерному коду, так что эти части могут легко вырвать двери из чистой реализации Java. user922475

Ваш Ответ

9   ответов
8

когда я поцарапал ствол с производительностью Ruby, и я не уверен, что с тех пор многое изменилось. Прямо сейчас это, caveat emptor - вы должны знать, чтобы не делать определенные вещи, и, честно говоря, игры / приложения реального времени были бы одним из них (поскольку вы упоминаете OpenGL).

Виновником в уничтожении интерактивной производительности является сборщик мусора - другие здесь упоминают, что в Java и других средах также есть сборщик мусора, но Ruby долженstop the world бежать. Другими словами, он должен прекратить запуск вашей программы, просмотреть все регистры и указатели памяти с нуля, отметить память, которая все еще используется, и освободить все остальное. Процесс не может быть прерван, пока это происходит, и, как вы могли заметить, это может занять сотни миллисекунд.

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

GC.disable / GC.enable around critical animation loops and maybe an opportunistic GC.start to force it to go when it can't do any harm. (because my target platform at the time was a 64MB Windows NT machine, this caused the system to run out of memory occasionally. But fundamentally it's a bad idea - unless you can pre-calculate how much memory you might need before doing this, you're risking memory exhaustion) Reduce the number of objects you create so the GC has less work to do (reduces the frequency / length of its execution) Rewrite your animation loop in C (a cop-out, but the one I went with!)

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

Другая серьезная проблема с производительностью, которую я обнаружил, - это базовые операции ввода-вывода при попытке написать TFTP-сервер на Ruby некоторое время назад (да, я выбрал все лучшие языки для своих критичных к производительности проектов, это был просто эксперимент). Абсолютно самый простой цикл для простого ответа на один UDP-пакет другим, содержащий следующий фрагмент файла, должен быть примерно в 20 раз медленнее, чем стандартная версия C. Я подозреваю, что, возможно, были сделаны некоторые улучшения, основанные на использовании низкоуровневого ввода-вывода (sysread и т. Д.), Но медлительность может заключаться лишь в том, что нет низкоуровневого байтового типа данных - каждое небольшое чтение копируется в Строка. Хотя это всего лишь предположение, я не стал продвигать этот проект намного дальше, но он не позволил мне положиться на быстрый ввод-вывод.

Основное недавнее увеличение скорости, хотя и здесь, хотя я не полностью обновлен, состоит в том, что реализация виртуальной машины была переделана для 1.9, что привело к более быстрому выполнению кода. тем не мениеЯ не думаю, что ГК изменилсяи я почти уверен, что на фронте ввода / вывода нет ничего нового. Но я не совсем в курсе новейших разработок Ruby, так что кто-то еще может захотеть сделать это здесь.

Error: User Rate Limit Exceeded Nick Retallack
4

«Написание калькулятора набора Мандельброта на языке высокого уровня похоже на попытку запустить Indy 500 в автобусе».

http://www.dekorte.com/blog/blog.cgi?do=item&id=4047

Я рекомендую изучить различные инструменты, чтобы использовать правильный инструмент для работы. Выполнение матричных преобразований может быть эффективно выполнено с использованием высокоуровневого API, который оборачивает замкнутые циклы с помощью арифметических вычислений. Смотрите пример RubyInline gem для встраивания кода C или C ++ в скрипт Ruby.

Существует также язык Io, который намного медленнее, чем Ruby, но он эффективно отображает фильмы в Pixar и превосходит необработанный C по векторной арифметике, используя ускорение SIMD.

http://iolanguage.com https://renderman.pixar.com/products/tools/it.html http://iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Primitives-Vector
3

Ruby 1.9.1 примерно в два раза быстрее PHP и немного быстрее Perl.

(Обновление: мой источникэтот (Скриншот). Я не знаю, каков его источник.)

Рубин не медленный. Старый 1.8 есть, но текущий Ruby не такой.

Error: User Rate Limit Exceeded
1

динамические языки вообще медленные. Они делают что-то во время выполнения, что статические языки делают во время компиляции.

Проверка синтаксиса, интерпретация и проверка типа Like, конвертация. это неизбежно, поэтому ruby работает медленнее, чем c / c ++ / java, поправьте меня, если я ошибаюсь.

2

потому что он был разработан для оптимизации работы программистов, а не времени выполнения программы. Медлительность является лишь признаком этого дизайнерского решения. Если вы предпочитаете выступление удовольствию, вам, вероятно, следует использовать другой язык. Руби не для всего.

4

что вы спрашиваете, "какие конкретные методы в Ruby имеют тенденцию быть медленными."

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

9

Бонусные баллы, если это «все» действительно никогда не использовал язык.

Серьезно, 1.9 намного быстрее и теперь наравне с питоном, а jruby быстрее, чем jython.

Сборщики мусора повсюду; например, в Java он есть, и он быстрее, чем C ++, при обработке динамической памяти. Рубин не очень хорошо подходит для обработки чисел; но мало языков, поэтому, если в вашей программе есть части, требующие большого объема вычислений, на любом языке, вам лучше переписать их на C (Java быстро работает с математикой из-за своих примитивных типов, но она им дорого заплатила, они явно # 1 в самых уродливых частях языка).

Что касается динамических функций: они не быстрые, но код без них на статических языках может быть еще медленнее; например, java будет использовать XML-конфигурацию вместо Ruby с использованием DSL; и это, вероятно, будет МЕДЛЕННО, так как анализ XML является дорогостоящим.

Error: User Rate Limit Exceeded Nick Retallack
Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededemptyError: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Nick Retallack
Error: User Rate Limit Exceeded
11

быстрых решений. Это зависит от того, какую проблему вы пытаетесь решить. Я напомнил об обсуждениях на старом форуме CompuServe MSBASIC в начале 90-х: когда его спросили, что было быстрее для разработки Windows, VB или C, обычный ответ был «VB, примерно на 6 месяцев».

В своей форме MRI 1.8 Ruby - относительно - медленно выполняет некоторые типы вычислительных задач. Практически любой интерпретируемый язык страдает таким образом по сравнению с большинством основных компилируемых языков.

Причин несколько: некоторые довольно легко адресуются (например, примитивная сборка мусора в 1.8), некоторые менее.

1.9 решает некоторые из проблем, хотя, вероятно, пройдет некоторое время, прежде чем он станет общедоступным. Некоторые из других реализаций, нацеленные на уже существующие среды выполнения, например, JRuby, IronRuby, MagLev, могут быть значительно быстрее.

Что касается математических характеристик, я не удивлюсь, увидев довольно медленную пропускную способность: это часть цены, которую вы платите за произвольную точность. Опять выбери свою проблему. Я решил 70+ изПроект Эйлера проблемы в Ruby практически без решения, требующего больше времени. Как быстро вам это нужно для запуска и как скоро вам это нужно?

Error: User Rate Limit Exceeded
69

Это «поздний поиск» для методов, чтобы учесть гибкость. Это немного тормозит. Он также должен помнить имена переменных для контекста, чтобы обеспечить eval, поэтому его кадры и вызовы методов медленнее. Также в настоящее время ему не хватает хорошего JIT-компилятора, хотя MRI 1.9 имеет компилятор байт-кода (что лучше), и jruby компилирует его в байт-код java, который затем (может) компилируется через JIT-компилятор HotSpot JVM, но это заканчивается скорость примерно равна 1.9.

How much does the garbage collector effect performance? I know I've had times when running the garbage collector alone took several seconds, especially when working with OpenGL libraries.

из некоторых графиков вhttp://www.igvita.com/2009/06/13/profiling-ruby-with-googles-perftools/ Я бы сказал, что это занимает около 10%, что совсем немного - вы можете уменьшить этот удар, увеличив malloc_limit в gc.c и перекомпилировав.

I've used matrix math libraries with Ruby that were particularly slow. Is there an issue with how ruby implements basic math?

Ruby 1.8 "не сделал" реализовав базовую математику, он реализовал числовые классы, и вы вызываете такие вещи, как Fixnum # + Fixnum # / один раз за вызов - что было медленно. Ruby 1.9 немного обманывает, добавляя некоторые основные математические операции.

Are there any dynamic features in Ruby that simply cannot be implemented efficiently? If so, how do other languages like Lua and Python solve these problems?

Такие вещи, как eval, сложно реализовать эффективно, хотя, я уверен, можно проделать большую работу. Рубин для Руби состоит в том, что он должен разместить для кого-тоin another thread изменение определения класса спонтанно, поэтому оно должно быть очень консервативным.

Has there been recent work that has significantly improved performance?

1,9 это как 2-кратное ускорение. Это также более экономно. JRuby постоянно пытается улучшить скорость [и, вероятно, проводит меньше времени в GC, чем KRI]. Кроме того, я мало что знаю, кроме маленьких хобби, над которыми я работаю. Отметим также, что строки 1.9 вл ютс иногда более медленными из-за удобства кодировани.

Error: User Rate Limit Exceeded Nick Retallack

Похожие вопросы