Посмотрела
доклад Коичи Сасада про ракторы.
Не так много нового про сами ракторы, зато дал хороший "рефрешер" о проблемах параллелизма :
Чем отличается параллельное выполнение от конкурентного?
- одновременное выполнение vs переключение между несколькими задачами
GVL/GIL в Ruby:
- ограничивает одновременное выполнение потоков, за счёт этого избавляет от многих проблем параллелизма
- иногда параллельное выполнение возможно, если один из потоков выполняет I/O операцию
Что за ракторы и зачем они?
- Руби-акторы
- появились в Ruby 3.0 (2020)
- для параллельного выполнения кода
- у каждого рактора есть свой GVL: потоки внутри одного рактора будут работать в основном конкурентно, а не параллельно.
А вот потоки внутри разных ракторов могут выполняться параллельно.
Почему нельзя просто взять и выполнять Руби-потоки параллельно?
(с точки зрения разработчиков языка)
- у потоков, запущенных в рамках одного процесса, общее пространство памяти, нужно следить за shared mutable objects, а это сложно
- в руби много shared mutable стейта + основные структуры типа строк и массивов не потокобезопасные
Есть мнение из 1995 года, что нужно вообще запретить параллельное выполнение потоков, т.к слишком сложно следить "вручную" (смотрите картинку :)
Какие есть варианты избавиться от сложности?
- запретить мутабельные объекты (elixir/erlang)
- отслеживать с помощью типов (Rust)
- ограничить mutations (clojure)
- отслеживать мутации и лочить внешними средствами (clang, helgrid/valgrind)
- запретить шарить объекты, форкать процессы (shell, druby)
- отделить shareable и не shareable объекты - Ракторы!
Что относительно нового:
- M:N планировщик тредов, появился в Ruby 3.3.0
M руби-тредов теперь "мапятся" на N тредов ОС, (N = количество ядер, M > N)
Описание в трекере По умолчанию M:N планировщик в главном ракторе выключен, тогда всё работает, как обычно: 1 рубишный поток соответствует одному потоку ОС.
В ракторах всё так же много проблем:
- мало поддерживающих их библиотек
- вообще мало что можно запустить, но вот на простых расчётах типа фибоначчи можно проверить
- есть особенности с производительностью, иногда код работает ещё медленнее, чем без ракторов
Интересно, дойдёт ли когда-нибудь до production-ready 🤔
Но надо понимать, что мы всегда в ракторе - посмотрите Ractor.current.
Можно глянуть планы и обширный список проблем с ракторами в
трекере
#ruby@anna_codes