Параллелизм 2

Да, заголовок поста на этот раз скучный :-). Это продолжение темы, начатой в "Надо всё переписать", составленное в большей части по комментариям.

Пользуясь случаем хочу сказать большое спасибо комментаторам! Написали много полезного и интересного, статья была бы неполной без этого.

Терминология

Как многие отметили, термины, которые я использовал, не отличаются однозначностью. Попробую подробно объяснить, что я имел в виду. Я не настаиваю на своём прочтении этих терминов, они в принципе ещё совсем не устоялись.

Самое общее понятие — это параллелизм. Оно означает любое параллельное исполнение кода. Причём как "честное" — на нескольких процессорах/ядрах, так и имитируемое программно на одном процессоре. Способов его организовывать может быть несколько. Мой общий посыл относительно параллелизма как такового состоит всего-навсего в том, что теперь мы от него никуда не денемся.

Один из способов делать параллелизм — это детерминированный параллелизм (не знаю более короткого термина). Я совсем не касался его в прошлый раз, и поэтому сошлюсь на хорошо объясняющий пост "Parallelism /= Concurrency", из которого я понял, что речь идёт о случаях, когда у вас есть функция типа f(x, y), где x и y друг от друга не зависят, вследствие чего вы можете считать аргументы параллельно, и тогда значение f будет посчитано быстрее. Штука в том, что в императивном языке невозможно предсказать независимость x и y только на основании их аргументов, потому что каждый из этих процессов может менять состояние мира, в котором работает, и это может влиять на результат другого процесса. Зато в функциональных языках, где мир вокруг внезапно не меняется, эту параллелизацию, по идее, возможно делать автоматически.

Весь остальной — недетерминированный — параллелизм принято называть словом concurrency, которому я вменяемого перевода на русский язык не знаю. Недетерминированность concurrent-процессов происходит от того, что они обмениваются данными в непредсказумые моменты времени. Это могут быть разделяемые даные в общей памяти и может быть передача сообщений с данными между процессами. Причём как именно организованы эти процессы, не уточняется: unix-процессы, треды, процессы виртуальной машины, сервисы ядра и т.д.

В связи с этим стоит сказать про не очень удачное слово тред, под которым часто понимаются две разные вещи:

• Треды операционной системы или виртуальной машины, как просто способ реализации разных параллельных задач, без уточнения того, как именно их используется программа. Например: "агенты в Clojure исполняются в отдельных тредах JVM".
• Широко распространённая модель программирования с использованием разделяемой памяти и локов для разграничения доступа к ней. Например: "когда тредов больше тысячи, всё загибается".

Я очень стараюсь использовать слово "тред" только в первом смысле. Второе пусть называется "шаренные данные и локи".

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

Однако часто "асинхронность" неявно жёстко привязывают конкретно к асинхронному вводу-выводу, когда асинхронность вызова обеспечивается тем, что долгую и тупую часть операции по перекладке байтов на себя берёт отдельный сервис ядра. Чтобы отличать это понятие от "асинхронности вообще", я буду пользоваться тремином неблокирующий IO.

Посыл

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

Вообще, ключевое слово там — не "асинхронно", а "придётся" :-).

Разные виды concurrency

Ещё одна важная вещь, которую я хочу подчеркнуть ещё раз, это то, что я считаю concurrent-программирование на императивных языках с разделяемой памятью и локами неработающей моделью для высокопараллельного будущего. И откровенно говоря, она и в настоящем уже достаточно проблем вызывает.

Именно поэтому мне интересны языки, которые реализуют concurrency по-другому.

Передача сообщений

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

Ещё примерно тот же подход с передачей сообщений используется в Go, если я правильно читаю их доку по concurrency. Для физической реализации параллельных процессов используются треды ОС. Причём кажется, что тред создаётся под каждую goroutine, никакого готового пула под них нет. Что не очень хорошо.

Разделяемая транзакционная память

В Clojure же всё наоборот. Там данные лежат в общей памяти, но никогда не изменяются. Вместо этого новая версия данных строится над старой, и шарит с ней все неизменённые куски. Раз данные не изменяются, доступаться к ним можно вообще без использования локов. А конфликты при записи новых данных решаются реализованной в языке software transactional memory, которая прозрачна для программиста и гарантирует корректность (хоть и недетерминированную) новых версий данных. Это очень хорошо видно в примере с эмулятором муравьёв, в видео, на которое я уже ссылался. Там в районе времени 83:45.

Главный плюс — это очень быстро и это наверное самый эффективный существующий способ занять все доступные ядра процессора. Кроме того, все асинхронные операции там выполняются пулом тредов, который не даёт создаваемым программистом задачам неконтроллируемо драться за процессор.

Главный минус — это работает только на одной машине. Соответственно, если вам нужно масштабировать систему на Clojure на несколько машин, это будут отдельные системы на Clojure, которые уже будут обмениваться данными не средствами языка, а так, как вы напишете.

"Архаичный" Erlang

Хорошо, я был не прав с этим словом — не пнул меня только ленивый :-). Вернее было бы сказать, что его синтаксис для меня слишком витиеват. Для питониста такое разнообразие знаков препинания (точек, точек с запятой, стрелочек и прочих дефисов) выглядит диковатым. Я точно знаю, что программировать можно без этого :-). Добавьте сюда ещё приписывание к имени функции числа аргументов при декларации их экспорта. Да и саму необходимость явно декларировать экспорт.

Откровенно говоря, я все эти вещи назвал "архаичными", потому что мне кажется очевидным, что в последнее время языки движутся в другую сторону: меньше церемоний, меньше синтаксиса как такового, меньше обязательных декларации чего бы то ни было. То есть по шкале выразительности языка от, скажем, Си до Питона, Erlang, придуманный в конце 80-х, таки кажется мне архаичным.

Впрочем, я не претендую хоть на какую-то объективность тут. Больше того, очень хорошо понимаю, что моё ворчание про Erlang из той же области, что ворчания не-лисперов про скобки, не-паскалистов про индексирование массивов с единицы, не-питонистов про отступы пробелами. Каждому — своё :-).

Неэффективность веб-модели

Ещё одна вещь, про которую я забыл. Я хочу не согласиться с Тимом Бреем, который считает, что на вебе проблемы с недостаточной параллелизацией обработки в целом решены. Да, у нас почти нет проблем с доступом к общим данным, и мы действительно обычно занимаем все доступные CPU, но только делаем это не особенно эффективно. Например мы плодим процессы/треды по количеству клиентов, которых пока что на обозримое будущее сильно больше, чем процессоров. А это значит, что процессы будут драться за ресурсы и мешать друг другу.

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

Существующих библиотечных подходов типа питоньих eventlet и Twisted для этого не хватает. На них можно делать очень ээфективную асинхронность на неблокирующих IO-вызовах. Но к сожалению, кроме ввода-вывода существуют и другие вычислительные задачи.

Ну вот... Кажется, всё должно стать яснее.