Ruby VM параллелизм и параллелизм - PullRequest
1 голос
/ 09 ноября 2011

У меня есть общий вопрос о Ruby VM (Ruby Interpreter). Как это работает с мультипроцессорами? Что касается параллелизма и параллелизма в Ruby, допустим, что у меня 4 процессора. Будет ли виртуальная машина автоматически назначать задачи процессорам через ядро? С масштабированием, допустим, что мой процесс ruby ​​требует много ресурсов процессора; что будет, если я добавлю новый процессор? Ответственна ли ОС за назначение задач процессорам, или каждая виртуальная машина будет работать на одном процессоре? Как лучше всего масштабировать мое приложение ruby? Я старался как можно больше отделить свои процессы и использовать очереди amqp. Есть еще идеи?

Было бы здорово, если бы вы могли присылать мне ссылки для более подробного объяснения.

Спасибо заранее.

1 Ответ

6 голосов
/ 09 ноября 2011

Ruby Threading

Сам язык Ruby поддерживает параллельное выполнение через модель потоков;однако реализация диктует, будут ли использованы дополнительные аппаратные ресурсы.Интерпретатор «золотого стандарта» (MRI Ruby) использует модель «зеленого потока» в версии 1.8;Потоки выполняются в интерпретаторе и используют только один системный поток для выполнения.Однако другие (например, JRuby) используют виртуальную машину Java для создания реальных потоков системного уровня для выполнения.MRI Ruby 1.9 добавляет дополнительные возможности потоков, но (на самом деле) он все еще ограничен только переключением контекстов потоков, когда поток останавливается при событии ввода-вывода.

Advanced Threading

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

Рефакторинг

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

Пример

Однажды я работал над Ruby on Railsприложение с массивной функцией хэширования при загрузке данных.Первоначальная реализация была полностью написана на Ruby и заняла ~ 80-е годы.Переписав код в ANSI C и используя более конкретное распределение памяти, время выполнения сократилось до секунды (даже без использования потоков).Следующим узким местом было вставка огромного количества данных обратно в MySQL, который в конечном итоге также переместился из кода Ruby в многопоточный C-код.Я специально пошел по этому пути, поскольку интерпретатор Ruby MRI легко связывается с C-кодом.В конечном итоге Ruby подготавливает среду для кода C, вызывает его как метод экземпляра Ruby для класса с параметрами, отображает хеш-код одним потоком кода C и, наконец, завершает рабочую очередь OpenMP .модель генерации и выполнения вставок в MySQL.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...