От одного потока к тысячам: мир параллельных вычислений

[metnerium]

Модель акторов действительно не является "новой". Это скорее "проверенная временем" абстракция, которая сейчас получает более широкое признание и применение за пределами своей изначальной ниши.

[metnerium]

Изначальная ниша - это телеком-оборудование Ericsson, где требовалась отказоустойчивость 99.9999% времени работы и горячие обновления прямо в проде. Сейчас актороподобные системы везде - от Akka и Orleans до веб-фронтендов на React (компоненты - почти акторы), Go с его горутинами+каналами, Elixir/Phoenix для веб-приложений. Даже и WhatsApp ~2 миллиона соединений на сервер гоняют через Erlang. Discord, Bet365, Riot Games - все юзают акторы для масштабирования.
Теория акторов Хьюитта была описана еще в 1973-м, а индустрия через 40 лет начала массово понимать, что это решает проблемы масштабирования лучше, чем шаред-мемори многопоточность.

[nin-jin]

В реакте от компонентов только название. Акторами они, конечно же, не являются. Работать параллельно они не могут в принципе.

[lws0954]

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

Эта история наглядно иллюстрирует, почему мы живем в эпоху параллельных вычислений. Больше нельзя было рассчитывать, что программы автоматически будут работать быстрее на новом оборудовании — наступила эра, когда разработчикам приходится явно программировать с учетом множества одновременно работающих вычислительных элементов

Эта «история» к параллелизму имеет мало отношения. До того, как до Генсингера что-то дошло, параллелизм (если его можно так назвать) уже существовал. Во-первых, «эра параллелизма» в форме потоков была уже открыта и даже поддерживалась той же Intel на аппаратном уровне (спросите ИИ, он это вам распишет в деталях). Во-вторых, параллелизм нужен не для ускорения работы программ (это и есть самый галимый штамп), а для решения проблем сложности программирования. Кстати, в заключении именно об этом сказано все правильно. Параллельное программирование – это прежде всего иное мышление.

Термины "конкурентность" и "параллелизм" часто используются как синонимы, но это фундаментальная ошибка. Роб Пайк, один из создателей языка Go, предложил образное объяснение: "Конкурентность — это работа с множеством вещей одновременно. Параллелизм — это делание множества вещей одновременно".

Фундаментальная ошибка «конкурентность» и «параллелизм» - это рассматривать эти понятия в контексте понятия параллельного программирования. По большому счету это просто некие структурные подходы к формированию вычислительных процессов. Параллельное программирование – про другое. Оно про реализацию модели параллельных вычислений. Ее поисками активно занимались в 80-х годах прошлого века, но потом это дело забросили. Тупо победило бабло. Остановились на потоках и на том пока успокоились.

Ну, а если говорить про «тонкости многопоточного программирования»… То об этом достаточно много и в деталях рассказано в рамках технологии параллельного автоматного программирования. Особенно на примере того же «счетчика» ;)

К сожалению, тема моделей параллельных вычислений вообще выпала из рассмотрения автором. 

 Хотя полностью автоматическое распараллеливание произвольных программ остается сложной задачей, 

Проблема автоматического распараллеливания имеет не такое уж сложное решение (в рамках алгебры параллельных процессов).  В этом смысле она давно не «остается сложной задачей». Это еще один штамп. Правда, для этого надо эту алгебру иметь. Но это опять про модель вычислений.

[unreal_undead2]

Тупо победило бабло. Остановились на потоках и на том пока успокоились.

В реально массовом параллелизме рулит MPI, там всё таки процессы с явным обменом данными.

[lws0954]

Если потокам прикрутить обмен сообщениями/данными, то это будет фактически тот же MPI. Особенно если смоделировать время на взаимодействие между узлами.. В этом смысле модель MPI - фактически те же потоки, но с определенными ограничениями.

[unreal_undead2]

Так весь смысл в этих ограничениях - нет разделяемой памяти и проблем с доступом к одним и тем же данным из разных потоков.

[azTotMD]

Причем каждый запуск может давать разные результаты! Эта недетерминированность — одна из главных проблем при разработке параллельных программ.

А по-моему, это круто! Сегодня семь, завтра - пять. Как цена акций на бирже. Этим надо пользоваться и наслаждаться.

[lws0954]

Это для кого как. Особенно счастливы будут владельцы подобного "многопоточного калькулятора"...