Потому что задачи разные. И пока еще никому не удалось придумать универсальный язык, который был бы хорош для всех задач.
Поэтому когда кто-то говорит, что C++ недостаточно выразителен, хотелось бы посмотреть на альтернативы в тех же областях, где для C++ пока еще есть место.
Я вам страшное скажу — у языков программирования есть свои области применения, вне которых от языка мало пользы. Задача программиста, как инженера, еще и в том, чтобы подобрать подходящий инструмент для своей задачи. Так что применять C++ для простых скриптов так же дико, как и Python для СУБД уровня MongoDB или ClickHouse.
Интересно было бы сравнить выразительность C++ с чем-то другим, что может использоваться в тех же нишах. Тут хорошо выглядит разве что Rust, который, сюрпрайз, разрабатывался с учетом недостатков C++.
Нужно иметь какой-то баланс между проведением вычислений и передачей данных.
При использовании CSP-каналов и короутин здесь неоткуда ожидать больших накладных расходов, чем при использовании акторов.
Но мне кажется, что протокол, когда обработчик говорит, сколько сообщений он может принять и не умереть (плюс возможно что делать с другими сообщениями) вполне имеет право на жизнь почти везде.
Имеет. Но, во-первых, как один из набора возможных. Во-вторых, с ним тоже не все так просто, примеры чего можно найти даже по приведенной вами ссылке. Так что изначальный тезис о том, что backpressure для асинхронных агентов — это не так просто, как хотелось бы, на мой взгляд, пока сохраняет свою актуальность.
Я так понимаю, что речь лишь про то, что можно делать посредством стандартной библиотеки C++? То, что под конкретную задачу можно сделать удобную библиотеку на C++ в принципе не считается?
Штуки, про которые я рассказывал реализованы вместе с буферизацией на асинхронных границах http://doc.akka.io/docs/akka/2.4.14/scala/stream/stream-rate.html
Похоже, что задачи, возлагаемые на Akka Streams, в мире C++ решаются с помощью Data Flow and Dependency Graphs из Threading Building Blocks. Это вообще отдельная ниша со своими особенностями. Решения для нее можно строить на базе Модели Акторов (например, акторами могут быть отдельные вычислительные узлы графа, так же акторами могут быть координаторы, которые решают, какому вычислительному узлу выделить время на рабочей нити в пуле). Можно строить на базе CSP и короутин. Это может быть даже проще и удобнее: связи между узлами представляются в виде CSP-каналов, вычислительные узлы графа — в виде короутин. Когда короутина-поставщик пытается записать очередной элемент данных в заполненный канал, то она просто приостанавливается. Когда короутина-потребитель пытается прочитать очередную порцию данных из пустого канала, она так же просто приостанавливается. Тем самым получается относительно несложное отображение большого количества короутин на небольшое количество рабочих потоков.
В любом случае, Akka Streams производит впечатление штуки, которая может быть построена на базе акторов, но не наоборот. Соответственно, механизмы backpressure, которые хорошо подходят к Akka Streams не обязательно должны хорошо работать в случае с просто акторами в задачах, не похожих на задачи из области data flow programming.
Преимущество в том, что мы передаем сообщения вместе с их длиной (как в UDP), но имеем надежную передачу (как в TCP)
Не очень понял вашу мысль. Сообщение при передаче по TCP точно так же должно предваряться длиной. Ну или придется искать в потоке данных специальные разделители (как это сделано в HTTP), что совсем неудобно при передаче BLOB-ов.
Я на следил пристально за развитием Akka и ее инфраструктуры, но мне казалось, что Akka Streams появились именно потому, что просто на акторах делать обработку потоков данных неудобно. И для упрощения этой задачи сделали прослойку поверх акторов.
Мне кажется, что обработка потоков однотипных данных гораздо лучше ложиться на модель CSP, чем на Модель Акторов. И хотя, как говорят, одна из них спокойно выражается через другую, дополнительные усилия в реализации CSP посредством акторов дает о себе знать при обработке потоков данных.
Вы часто упоминаете сложности организации back-pressure в модели акторов, но не вдавались в подробности, в чём эти сложности заключаются.
Я попытался объяснить, с чем приходится сталкиваться в общем случае. Понятно, что бывают частные случаи, в которых реализация back-pressure более очевидно (как, например, в ограниченном контексте с Reactive Streams). Вообще, вот здесь я специально подчеркивал, что хороший механизм защиты от перегрузки должен быть заточен под конкретную задачу.
Akka Streams например поверх протокола ReactiveStreams реализует много чего. И отбрасывание лишних сообщений, и группировку, и непосылание новых запросов.
А можно ссылочку попросить, дабы не перелопачивать всю документацию по Akka Streams?
Ну вот как раз про backpressure информация что-то с ходу не обнаруживатся. В описании изменений для JDK9 вообще вот что сказано:
The Flow API does not provide any APIs to signal or deal with back pressure as such, but there could be various strategies one could implement by oneself to deal with back pressure.
Т.е. стандартного API для этого нет, нужно делать что-то по месту бедствия.
Об этом же говорят и авторы reactive manifesto (раздел Basic Semantics):
How elements are transmitted, their representation during transfer, or how back-pressure is signaled is not part of this specification.
Из описания API для Reactive Streams следует, что основная идея в периодическом запросе N новых сообщений Subscriber-ом после того, как он разобрался со своей текущей нагрузкой. Для каких-то задач это вполне себе нормально. И может быть без особых усилий реализовано поверх асинхронного общения акторов.
В каких-то задачах это вряд ли возможно. Например, у нас может быть датчик температуры воздуха, который опрашивается раз в секунду. Этот датчик должен отдавать информацию во внешним мир именно с таким темпом. Если на информацию от датчика подписано 10 получателей, то датчик не должен озадачиваться тем, что один из 10 получателей сейчас не готов принять текущее значение.
Один из главных факторов — это то, что доставка сообщения до получателя не является мгновенной операцией. Т.е. перегруженный агент A отсылает агенту B сообщение о том, что A перегружен. Но пройдет какое-то время, в течении которого агент B будет отсылать сообщения агенту A. За это время агент A может быть загружен «по самое не хочу». Опять же, сообщение о том, что агент А освободился и готов принимать данные вновь, придет к B не сразу. В течении этого времени агент B будет простаивать, т.е. мы будет терять время.
Кроме того, далеко не всегда есть жесткая связь 1:1 между отправителем и получателем. Т.е. может быть получатель A, которому отсылают сообщения агенты B1, B2, B3 и т.д. И все с разным темпом, и все в своем собственном порядке. Так что если перегрузка A возникает при сообщении от B2, то это не значит, что блокировать нужно именно B2.
Кроме того, агент A может отсылать сообщения самому себе (такое регулярно используется). Не будет же A блокировать самого себя :)
Кроме того, есть еще отложенные и периодические сообщения, которые летят от таймера. Таймер вообще нельзя блокировать, т.к. он обслуживает толпу агентов.
Кроме того, далеко не факт, что очередь, заполненная на 80% будет разгребаться дольше, чем очередь, заполненная на 20%. Тут зависит от того, что за сообщения стоят в очереди и сколько стоит обработка каждого из них. Есть сообщения, обработка которых стоит очень дешево, есть сообщения, на обработке которых агент может тратить минуты в буквальном смысле.
Кроме того, далеко не факт, что агенту будет принадлежать собственная очередь. Это от фреймворка зависит. У нас в SObjectizer сообщения идут не в очередь агента, а в очередь диспетчера, на котором работают агенты. Для каких-то диспетчеров у каждого агента будет своя очередь, а для каких-то — будет общая очередь, разделяемая с другими агентами. Кроме того, это все unbound-очереди, так что процент их наполнения не подсчитать. AFAIK, в CAF и в Akka у каждого актора своя очередь.
Так что, по хорошему, для того, чтобы понять, насколько загружен актор, нужно понимать сколько «тяжелых» сообщений уже стоят в его очереди. Но даже при этом, когда агенты взаимодействуют в режиме 1:N или N:1, или M:N, не понятно кого именно приостанавливать.
PS. Понятно, что в каких-то конкретных случаях можно сделать какое-то частное решение, которое будет прекрасно работать на конкретной задаче. Но если смотреть с точки зрения реализации универсального фреймворка, все не так тривиально, как хотелось бы.
а, значит, разработчиками уже выработаны какие-то оптимальные решения. Или, всё же, не совсем?
Не знаю, что творится в этой теме с точки зрения computer science. На практике же есть несколько широко известных реализаций: Erlang и Akka. Erlang — это отдельный язык и виртуальная машина (т.е. настоящая платформа). Akka — это просто фреймворк для JVM (для Java и Scala). Кроме них существуют и другие реализации для разных языков и платформ (например, Elixir для Erlang VM, Quasar для Java, Orleans для .NET, Celluloid для Ruby и т.д.) Для C++ полный разброд и шатание (немного подробнее здесь). Впрочем, для C++ это нормально, т.к. C++ применяется для совершенно разных задач.
По поводу распределенности «из коробки». Начал было писать комментарий. Но он настолько быстро стал расти в размерах, что уже начал напоминать отдельную статью. Видимо, именно статьей я его и сделаю. А здесь дам ссылку. Думаю, что обсуждать вопросы, связанные с IPC будет проще в комментариях к отдельной статье.
Вы хотите Rust-овские try! и ? в C++? В C++17 у вас будет возможность написать так (при должной реализации типа result<R,E>):
Поэтому когда кто-то говорит, что C++ недостаточно выразителен, хотелось бы посмотреть на альтернативы в тех же областях, где для C++ пока еще есть место.
Или речь идет только про однострочники в студенческих лабораторных?
Я вам страшное скажу — у языков программирования есть свои области применения, вне которых от языка мало пользы. Задача программиста, как инженера, еще и в том, чтобы подобрать подходящий инструмент для своей задачи. Так что применять C++ для простых скриптов так же дико, как и Python для СУБД уровня MongoDB или ClickHouse.
Интересно было бы сравнить выразительность C++ с чем-то другим, что может использоваться в тех же нишах. Тут хорошо выглядит разве что Rust, который, сюрпрайз, разрабатывался с учетом недостатков C++.
Имеет. Но, во-первых, как один из набора возможных. Во-вторых, с ним тоже не все так просто, примеры чего можно найти даже по приведенной вами ссылке. Так что изначальный тезис о том, что backpressure для асинхронных агентов — это не так просто, как хотелось бы, на мой взгляд, пока сохраняет свою актуальность.
В любом случае, Akka Streams производит впечатление штуки, которая может быть построена на базе акторов, но не наоборот. Соответственно, механизмы backpressure, которые хорошо подходят к Akka Streams не обязательно должны хорошо работать в случае с просто акторами в задачах, не похожих на задачи из области data flow programming.
Я попытался объяснить, с чем приходится сталкиваться в общем случае. Понятно, что бывают частные случаи, в которых реализация back-pressure более очевидно (как, например, в ограниченном контексте с Reactive Streams). Вообще, вот здесь я специально подчеркивал, что хороший механизм защиты от перегрузки должен быть заточен под конкретную задачу.
А можно ссылочку попросить, дабы не перелопачивать всю документацию по Akka Streams?
Т.е. стандартного API для этого нет, нужно делать что-то по месту бедствия.
Об этом же говорят и авторы reactive manifesto (раздел Basic Semantics):
Из описания API для Reactive Streams следует, что основная идея в периодическом запросе N новых сообщений Subscriber-ом после того, как он разобрался со своей текущей нагрузкой. Для каких-то задач это вполне себе нормально. И может быть без особых усилий реализовано поверх асинхронного общения акторов.
В каких-то задачах это вряд ли возможно. Например, у нас может быть датчик температуры воздуха, который опрашивается раз в секунду. Этот датчик должен отдавать информацию во внешним мир именно с таким темпом. Если на информацию от датчика подписано 10 получателей, то датчик не должен озадачиваться тем, что один из 10 получателей сейчас не готов принять текущее значение.
Кроме того, далеко не всегда есть жесткая связь 1:1 между отправителем и получателем. Т.е. может быть получатель A, которому отсылают сообщения агенты B1, B2, B3 и т.д. И все с разным темпом, и все в своем собственном порядке. Так что если перегрузка A возникает при сообщении от B2, то это не значит, что блокировать нужно именно B2.
Кроме того, агент A может отсылать сообщения самому себе (такое регулярно используется). Не будет же A блокировать самого себя :)
Кроме того, есть еще отложенные и периодические сообщения, которые летят от таймера. Таймер вообще нельзя блокировать, т.к. он обслуживает толпу агентов.
Кроме того, далеко не факт, что очередь, заполненная на 80% будет разгребаться дольше, чем очередь, заполненная на 20%. Тут зависит от того, что за сообщения стоят в очереди и сколько стоит обработка каждого из них. Есть сообщения, обработка которых стоит очень дешево, есть сообщения, на обработке которых агент может тратить минуты в буквальном смысле.
Кроме того, далеко не факт, что агенту будет принадлежать собственная очередь. Это от фреймворка зависит. У нас в SObjectizer сообщения идут не в очередь агента, а в очередь диспетчера, на котором работают агенты. Для каких-то диспетчеров у каждого агента будет своя очередь, а для каких-то — будет общая очередь, разделяемая с другими агентами. Кроме того, это все unbound-очереди, так что процент их наполнения не подсчитать. AFAIK, в CAF и в Akka у каждого актора своя очередь.
Так что, по хорошему, для того, чтобы понять, насколько загружен актор, нужно понимать сколько «тяжелых» сообщений уже стоят в его очереди. Но даже при этом, когда агенты взаимодействуют в режиме 1:N или N:1, или M:N, не понятно кого именно приостанавливать.
PS. Понятно, что в каких-то конкретных случаях можно сделать какое-то частное решение, которое будет прекрасно работать на конкретной задаче. Но если смотреть с точки зрения реализации универсального фреймворка, все не так тривиально, как хотелось бы.
Не знаю, что творится в этой теме с точки зрения computer science. На практике же есть несколько широко известных реализаций: Erlang и Akka. Erlang — это отдельный язык и виртуальная машина (т.е. настоящая платформа). Akka — это просто фреймворк для JVM (для Java и Scala). Кроме них существуют и другие реализации для разных языков и платформ (например, Elixir для Erlang VM, Quasar для Java, Orleans для .NET, Celluloid для Ruby и т.д.) Для C++ полный разброд и шатание (немного подробнее здесь). Впрочем, для C++ это нормально, т.к. C++ применяется для совершенно разных задач.