
Комментарии 12
активно развиваются новые абстракции:
[…]
• Акторы: независимые объекты, взаимодействующие через передачу сообщений
39 лет — это так себе «новая» абстракция (см. эрланг).
Еще мне показалось странным не упомянуть самый надежный механизм синхронизации — а именно, иммутабельные данные (см. эрланг).
Модель акторов действительно не является "новой". Это скорее "проверенная временем" абстракция, которая сейчас получает более широкое признание и применение за пределами своей изначальной ниши.
Какой ниши? WhatsApp вроде тоже не вчера написали.
Изначальная ниша - это телеком-оборудование Ericsson, где требовалась отказоустойчивость 99.9999% времени работы и горячие обновления прямо в проде. Сейчас актороподобные системы везде - от Akka и Orleans до веб-фронтендов на React (компоненты - почти акторы), Go с его горутинами+каналами, Elixir/Phoenix для веб-приложений. Даже и WhatsApp ~2 миллиона соединений на сервер гоняют через Erlang. Discord, Bet365, Riot Games - все юзают акторы для масштабирования.
Теория акторов Хьюитта была описана еще в 1973-м, а индустрия через 40 лет начала массово понимать, что это решает проблемы масштабирования лучше, чем шаред-мемори многопоточность.
Каналы в го — это мютексы на стероидах. Компоненты реакта — даже страшно предположить, в какой параллельной реальности они акторы. Финикс — это прекрасно, но как раз там акторная модель используется поскольку-постольку. Эликсир сам по себе выполняется ровно в той же BEAM-машине, что и эрланг. Как и Gleam, как и LFE от Вирдинга.
Akka… ну, найс трай, чё. Отказоустойчивость им все равно скопировать из эрланга не удалось. Да и индустрия не особо стремится переходить на Akka, слишком уж инородно она смотрится в Java.
А еще три четверти роутеров в мире обслуживаются эрлангом, брокеры всякие, и так далее. Я всего лишь намекал, что акторная модель была живее всех живых все эти годы, просто мало кому в современном мире это требуется: ну прилег сайтик на минутку — ну и ладно.
И да, эрланг — это 9 девяток, а не 6. Nine nines.
В реакте от компонентов только название. Акторами они, конечно же, не являются. Работать параллельно они не могут в принципе.
Хорошая и добротная статья, написанная простым и понятным языком, однако содержащая, к сожалению, определенные штампы. Достаточно наглядно отражает современное состояние параллельных вычислений.
Эта история наглядно иллюстрирует, почему мы живем в эпоху параллельных вычислений. Больше нельзя было рассчитывать, что программы автоматически будут работать быстрее на новом оборудовании — наступила эра, когда разработчикам приходится явно программировать с учетом множества одновременно работающих вычислительных элементов
Эта «история» к параллелизму имеет мало отношения. До того, как до Генсингера что-то дошло, параллелизм (если его можно так назвать) уже существовал. Во-первых, «эра параллелизма» в форме потоков была уже открыта и даже поддерживалась той же Intel на аппаратном уровне (спросите ИИ, он это вам распишет в деталях). Во-вторых, параллелизм нужен не для ускорения работы программ (это и есть самый галимый штамп), а для решения проблем сложности программирования. Кстати, в заключении именно об этом сказано все правильно. Параллельное программирование – это прежде всего иное мышление.
Термины "конкурентность" и "параллелизм" часто используются как синонимы, но это фундаментальная ошибка. Роб Пайк, один из создателей языка Go, предложил образное объяснение: "Конкурентность — это работа с множеством вещей одновременно. Параллелизм — это делание множества вещей одновременно".
Фундаментальная ошибка «конкурентность» и «параллелизм» - это рассматривать эти понятия в контексте понятия параллельного программирования. По большому счету это просто некие структурные подходы к формированию вычислительных процессов. Параллельное программирование – про другое. Оно про реализацию модели параллельных вычислений. Ее поисками активно занимались в 80-х годах прошлого века, но потом это дело забросили. Тупо победило бабло. Остановились на потоках и на том пока успокоились.
Ну, а если говорить про «тонкости многопоточного программирования»… То об этом достаточно много и в деталях рассказано в рамках технологии параллельного автоматного программирования. Особенно на примере того же «счетчика» ;)
К сожалению, тема моделей параллельных вычислений вообще выпала из рассмотрения автором.
Хотя полностью автоматическое распараллеливание произвольных программ остается сложной задачей,
Проблема автоматического распараллеливания имеет не такое уж сложное решение (в рамках алгебры параллельных процессов). В этом смысле она давно не «остается сложной задачей». Это еще один штамп. Правда, для этого надо эту алгебру иметь. Но это опять про модель вычислений.
Тупо победило бабло. Остановились на потоках и на том пока успокоились.
В реально массовом параллелизме рулит MPI, там всё таки процессы с явным обменом данными.
Если потокам прикрутить обмен сообщениями/данными, то это будет фактически тот же MPI. Особенно если смоделировать время на взаимодействие между узлами.. В этом смысле модель MPI - фактически те же потоки, но с определенными ограничениями.
Причем каждый запуск может давать разные результаты! Эта недетерминированность — одна из главных проблем при разработке параллельных программ.
А по-моему, это круто! Сегодня семь, завтра - пять. Как цена акций на бирже. Этим надо пользоваться и наслаждаться.
От одного потока к тысячам: мир параллельных вычислений