LINUX.ORG.RU

Обновился инструмент для работы с агентами в C++: SObjectizer 5.5.5

 , , ,


1

2

SObjectizer — это небольшой фреймворк для упрощения разработки многопоточных приложений на C++. SObjectizer позволяет создавать объекты-агенты, которые взаимодействуют друг с другом только посредством асинхронных сообщений. Сам SObjectizer берет на себя задачи диспетчеризации сообщений и предоставление агентам рабочего контекста для обработки получаемых сообщений.

Проект живет на SourceForge, распространяется под трехпунктной BSD-лицензией.

Версию 5.5.5 можно взять либо из секции Files на SF, либо из Svn-репозитория, либо из зеркала на GitHub.

Если говорить кратко, то в версии 5.5.5 появилось следующее:

  • вспомогательные шаблонные методы introduce_coop и introduce_child_coop, упрощающие создание и регистрацию коопераций;
  • возможность использования туплов в качестве типов сообщений;
  • фильтры для сообщений, которые позволяют анализировать содержимое сообщений и отбрасывать те из них, которые не интересны агенту получателю;
  • несколько новых примеров.

Так же подготовлены две новые части серии презентаций “Dive into SObjectizer-5.5”, более подробно рассказывающие о состояниях агентов и кооперациях агентов (все имеющиеся презентации собраны здесь).

Если интересны подробности, то сюда.

Отдельная благодарность Алексею Сырникову, как за помощь в подготовке этого релиза, так и за поддержку зеркала SObjectizer на GitHub-е.

★★★★★
Ответ на: комментарий от eao197

Что то слабо получаеться. Ты про ассинхронные вызовы в акторах так ничего внятного и не ответил, кроме как создать ещё один тредпул и дурацкое «а зачем вы делаете блокиреющие вызовы в акторе?». И про малок на две страницы это вообще финиш. Это называется из пальца высасывать, да.

anonymous
()
Ответ на: комментарий от anonymous

Ты про ассинхронные вызовы в акторах так ничего внятного и не ответил, кроме как создать ещё один тредпул и дурацкое «а зачем вы делаете блокиреющие вызовы в акторе?»

А кто про это спрашивал?

С блокирующими вызовами ситуация такая: в SO5 нет средств для выполнения асинхронного I/O. В этом нет большого смысла, т.к. уже есть куча инструментов (вроде asio/libevent/libuv/ace) которые это делают и делают хорошо. Надстраивать над ними еще что-то акторное... Ну может в этом кто-то и видит смысл, но я лично так не думаю.

Остается ситуация, когда нужно использовать либо сторонние библиотеки, выставляющие наружу синхронный API, либо когда агенты сами должны выполнять длительные операции (типа перемножения матриц). Как раз для этого в SO5 и существует куча разных диспетчеров. Агент, который вынужден общаться с чужой синхронной библиотекой просто привязывается к подходящему диспетчеру (например, к диспетчеру с активными агентами). После чего агент будет работать на своей собственной нити. Заблокируется эта нить синхронным вызовом — ну и фиг с ней, есть шедулер ОС, который знает, кому можно отдать процессорное время.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Ты про ассинхронные вызовы в акторах так ничего внятного и не ответил, кроме как создать ещё один тредпул и дурацкое «а зачем вы делаете блокиреющие вызовы в акторе?».

Насколько я понимаю, асинхронные вызовы можно запилить через библиотеки(asio, например). Зачем это пихать в библиотеку акторов?

А блокирующие вызовы можно сделать с интерфейсом асинхронных через отдельный тредпул(как тут кто-то уже говорил) и тот же asio. И да, я и в NIF'е могу сделать такой вызов.

forCe
()
Ответ на: комментарий от forCe

Вот обьясни мне. Если есть азио и либивент,как вы сами пишете, зачем здесь акторы вообще? Если смысл в производительности, зачем ещё одна абстракция?

Нифы и дравера нужно юзать когда много данных передавать надо. Если данных кот наплакал, то порт то что надо. А с портом клал я на эти малоки и прочий гемор.

Если мало порта, ничто не запрещает и ноду на с запилить.

Често, этот тред похож на спор в песочнице. Сидят такие чуваки из песка строят башенки. Одни говорит: смотрите чуваки, я придумал вставлять каркас из палочек, надёжнее получаеться! Тут подходят со стороны и говорят: парень возми цемент или бетон. А все такие: ты чё? Какой бетон? Какой цемент! У нас песочница, иди в другой тред. А внятно, зачем строить из песка объяснить никто не может. Единственный ответ который я вижу: шоб было.

anonymous
()
Ответ на: комментарий от anonymous

Если есть азио и либивент,как вы сами пишете, зачем здесь акторы вообще?

Ну попробуйте на asio и libevent, например, сделать обработку потока сообщений из AMQP или MQTT. Под обработкой понимается не чтение сокета и (де)сериализация данных. А прикладная обработка сообщение, которое пришло и требует каких-то действий.

Или, например, расскажите, как вы будете на asio реализовывать приложения вроде Lightroom, где требуется разнесение вычислительных задач на разные потоки.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Ну, это несерьезно. Был упомянут Lightroom, а кто-то делает десктопный графический софт на Эрланге? Покажите красавцев!

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от anonymous

Вы пробовали работать с тем же RabbitMQ из того же C++ не под онтопиком? К сожалению, клиент там хоть и существует, но практически неюзабелен. В общем-то, на плюсах нет толковых AMQP-клиентов.

anonymous
()
Ответ на: комментарий от anonymous

ответа, зачем строить башенки из песка так и нету.

Сударь, вы поняли, что я писал? Если не поняли, то еще раз:

Ну попробуйте на asio и libevent, например, сделать обработку потока сообщений из AMQP или MQTT. Под обработкой понимается не чтение сокета и (де)сериализация данных. А прикладная обработка сообщение, которое пришло и требует каких-то действий.

Допустим, что из MQTT пришло сообщение с текущей температурой от очередного датчика. Один получатель должен записать это значение в архив, второй получать — отобразить на графике в GUI, третий — проанализировать текущее значение и, если оно вышло за какие-то рамки, инициировать некоторые действия.

Или, допустим, по AMQP прилетело сообщение с запросом на проверку рисковости платежной операции. Получив такое сообщение нужно выдать запросы в несколько дополнительных систем, собрать ответы и сформировать результирующее сообщение, которое опять уйдет в AMQP.

Расскажите, хотя бы на пальцах, как вы такую логику будете с помощью ASIO или libevent-а реализовывать?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Из широко известных Wing3D.

Но суть примера с Lightroom была в другом. Анонимус утверждал, что если есть asio/libevent и пр. инструменты, реализующие event-loop, то акторы уже не нужны.

Что явно не так, поскольку кроме низкоуровневых задач ввода-вывода, есть еще и другие задачи. В некоторых из них модель акторов вполне себя хорошо чувствует. Например, при распределении работы в приложениях, вроде Lightroom, по разным рабочим контекстам.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

есть еще и другие задачи. В некоторых

в которых спп нужен как строителям песочные башенки, да.

anonymous
()
Ответ на: комментарий от anonymous

да нахрен мне твои либивенты с азиями в этой задаче, если есть эрланг?

А нахрена в этой теме вы со своим Erlang-ом?

Здесь обсуждается инструмент для работы с акторами в C++. Кому такой инструмент не нужен (например, вам с вашим Erlang-ом), тот может спокойно пофлудить в других темах.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Обновился инструмент для работы с агентами в C++: SObjectizer 5.5.5 (комментарий)

Често, этот тред похож на спор в песочнице. Сидят такие чуваки из песка строят башенки. Одни говорит: смотрите чуваки, я придумал вставлять каркас из палочек, надёжнее получаеться! Тут подходят со стороны и говорят: парень возми цемент или бетон. А все такие: ты чё? Какой бетон? Какой цемент! У нас песочница, иди в другой тред. А внятно, зачем строить из песка объяснить никто не может. Единственный ответ который я вижу: шоб было.

anonymous
()
Ответ на: комментарий от anonymous

Читайте выше, вам уже все объяснили.

И да, подрочить на Erlang вы можете не только здесь, но и в любом другом треде.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

да нахрен мне твои либивенты с азиями в этой задаче, если есть эрланг?

Я вот одного понять не могу. Кто вас заставляет брать С++? Пишите на эрланге, раз требования и ресурсы позволяют. В чем проблема-то?

anonymous
()
Ответ на: комментарий от eao197

нихрена ты не объяснил. пойми, эрланг это и есть библиотека акторов, написана на с, отлажена десятилетиями и не имеет детских проблем, которые есть у со5. т.е. ты пишешь велосипед на с++11 (который не в каждой приличной конторе примут), на котором писать сложнее, чем на эрланге, не выиграв от этого ничего. даже хвалёной крестовой производительности, что тебе наглядно продемонстрировали.

anonymous
()
Ответ на: комментарий от anonymous

пойми, эрланг это и есть библиотека акторов, написана на с

Боюсь, вы что-то путаете. Прежде всего Erlang — это динамически-типизированный язык программирования, со сборкой мусора и собственной VM. А уже эта VM написана на C (как и еще куча других VM).

Далее, Erlang — это OTP, без которой Erlang мало кому нужен. А OTP — это куча библиотек, написанных, как это не странно, на Erlang-е. В чем не трудно убедиться, если заглянуть в исходники. Вот, например, в составе OTP-17.5:

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Erlang                        4305         284987         370027        1666320
XML                            990          32674           2288         368294
C                              540          45662          40499         293743
Bourne Shell                    96           9998           9994          85829
C/C++ Header                   288           8082          12054          53362
C++                             15            372            479          41583
make                           345           7963          11705          18089
XSD                             35            337            223          14209
Java                            97           2769           7535          10569

При этом Erlang, как язык, не имеет каких-либо нормальных инструментов для разработки абстракций. Там из структурированных типов данных всего-то list, record и, с недавних пор, map.

А производительность Erlang-ового кода такова, что вещи вроде подсчета контрольных сумм, нужно писать на C в виде NIF-ов.

детских проблем, которые есть у со5

Ануткать, с этого места поподробнее.

ты пишешь велосипед на с++11 (который не в каждой приличной конторе примут),

Это в каких приличных конторах не используют c++11 для новых проектов? И в каких приличных конторах не будут использовать c++11 (а затем и 14, и 17) в будущем?

на котором писать сложнее, чем на эрланге

Откуда дровишки?

даже хвалёной крестовой производительности, что тебе наглядно продемонстрировали.

Где, сударь? Вы бредите и у вас галюники.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Это в каких приличных конторах не используют c++11 для новых проектов?

fcoo.dk :( для венды тут 2008 студия со всеми вытекающими. Тут в этом плане консерваторы. Есть куча серверов на 2000ой еще винде. И да. Мы тут такие - нифига не исключение.

anonymous
()
Ответ на: комментарий от anonymous

Мы тут такие - нифига не исключение

Ну так это же не может длится вечно. В конце-концов поддержка на уровне 2008-й студии или какого-нибудь GCC 4.0 будет обходиться все дороже и дороже.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Прежде всего Erlang

прежде всего это была метафора, дубина.

А производительность Erlang-ового кода такова, что вещи вроде подсчета контрольных сумм, нужно писать на C в виде NIF-ов.

а ты его в со5 итерируя стл лист подсчитываешь, да. или акторами? смешной ты.

с этого места поподробнее.

вытесняющая многозадачность акторов.

Это в каких приличных конторах не используют c++11 для новых проектов?

не позорься. ты похож на школьника сейчас.

Откуда дровишки?

спеки спп - 1300 стр. спеки эрланга - 300 стр. конечно спп проще выучить, да.

Где, сударь?

в караганде. выше тебе уже разжевали.

anonymous
()
Ответ на: комментарий от eao197

Ну так это же не может длится вечно.

а тебя и спрашивать никто не будет. в моей конторе есть проект на ку3. думаешь его кто-то будет портировать на ку4 или 5?

anonymous
()
Ответ на: комментарий от anonymous

спеки спп - 1300 стр. спеки эрланга - 300 стр. конечно спп проще выучить, да.

Разве разговор был о выучить? Мне казалось был разговор об использовании. Берём специалистов на C++ и специалистов на erlang. С чего вы взяли, что проект, требующий в случае erlang'а много NIF, будет делать проще, чем на C++ с какой-то библиотекой факторов?

anonymous
()
Ответ на: комментарий от anonymous

Разве разговор был о выучить? Мне казалось был разговор об использовании. Берём специалистов на C++ и специалистов на erlang. С чего вы взяли, что проект, требующий в случае erlang'а много NIF, будет делать проще, чем на C++ с какой-то библиотекой факторов?

Если нужно очень много NIF'ов то, очевидно, лучше сразу С-ноду поднимать.

cyanide_regime
()
Ответ на: комментарий от anonymous

а ты его в со5 итерируя стл лист подсчитываешь, да. или акторами?

На so5 для подсчета контрольных сумм будет использоваться тот же самый C++, что и для остального проекта. В отличии от Erlang, где придется другой язык задействовать. Да еще и надеяться, что вставки на C в Erlang-е не начнут глючить, при изменении условий или переносе на другую платформу.

вытесняющая многозадачность акторов.

Еще раз для анонимных тимлидов: в C++ не нужно реализовывать шедулинг в библиотеке. В C++ используются родные потоки ОС и управляет этим шедулер ОС.

SO5 дает разработчику разнести своих агентов по рабочим потокам так, чтобы не страдать от того, что какой-то агент надолго уйдет в синхронный вызов OCCI/ODBC или чего-то подобного.

Собственно, здесь есть встречный вопрос: где именно окажется вытесняющая многозадачность Erlang-овского шедулера, если Erlang-овый процесс дернет NIF-ку (ведь без NIF-ки нет производительности в Erlang-е, как вы сами подтверждаете), а NIF-ка уйдет в OCCI/ODBC?

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

Это что, максимально доступный для вас уровень аргументации?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

в моей конторе есть проект на ку3. думаешь его кто-то будет портировать на ку4 или 5?

Ну и кто для вас саппортит qt3? Во сколько это обходится?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

NIF-ку (ведь без NIF-ки нет производительности в Erlang-е, как вы сами подтверждаете), а NIF-ка уйдет в OCCI/ODBC?

Такое делают драйвером, а не NIF'кой. NIF не должен надолго «залипать» - об этом сказано в документации. Хотя порой приходится городить NIF'ы со своей активностью, что в принципе не по фэншую.

cyanide_regime
()
Ответ на: комментарий от cyanide_regime

Такое делают драйвером, а не NIF'кой. NIF не должен надолго «залипать» - об этом сказано в документации.

Поскольку я, все-таки, не Erlang-ер, то для меня нет большой разницы между NIF, драйвером, портом и нодой.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Поскольку я, все-таки, не Erlang-ер, то для меня нет большой разницы между NIF, драйвером, портом и нодой.

Native Implemented Function - в идеале - зависят только от своих аргументов, быстрые и не создают никаких активностей (вроде тредов и проч.)

Драйвер - штука, которая может иметь свою scheduler-friendly активность.

Порт - по сути программа, общающаяся с erlang-нодой через stdin/stdout.

Нода - полноценный узел, написанный на целиком на С.

cyanide_regime
()
Ответ на: комментарий от cyanide_regime

Это все понятно. Вопрос, опять же, возвращается к своему началу: если для производительности придется значительную часть кода писать на C (в виде NIF-ов, драйверов, портов и нод), то какого качества будет этот код и не окажется ли это все гораздо дороже в разработке/сопровождении, чем написание всей системы сразу на С++?

При этом вообще в стороне остается вопрос актуальности притягивания Erlang-а в том или ином случае. Например, если разрабатывается GUI-приложение масштаба GIMP-а, Photoshop-а или Lightroom-а. Насколько оправданным будет использование Erlang-а в приложении, где требуется и GUI, и высокая загрузка CPU, и выполнение I/O, но практически не нужна сеть и распределенность?

Или, например, если уже есть унаследованная кодовая база из сотен тысяч, если не миллионов строк C++ного кода. Что будет проще: частями переводить этот legacy на обновленную версию C++ с обновлением версий фреймворков (тот же Qt3 на Qt5, Boost.Lambda на C++11 lambda и т.д.) или писать рядом новую версию на Erlang, задействуя куски старого кода в NIF-ах/драйверах/портах? Ну и если переписывание legacy на новом языке все-таки выгодно, то почему должен рассматриваться именно Erlang, а не Java/Scala+Akka? Или Haskell+CloudHaskell? Или что-то еще?

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

если для производительности придется значительную часть кода писать на C (в виде NIF-ов, драйверов, портов и нод), то какого качества будет этот код и не окажется ли это все гораздо дороже в разработке/сопровождении, чем написание всей системы сразу на С++?

Вилами по воде писано. Не каждой задаче нужна производительность, и не для каждой задачи придется писать часть на С с нуля - под Erlang уже есть куча готовых портов известных библиотек (NIF, драйвера и проч). Для некоторых вещей производительных мы вообще ни строчки не писали на С - брали готовые опенсорсные компоненты или наши, написанные ранее. Но соглашусь, что если стоит задача выжать максимум производительности от приложения и трахота с интеграцией требуемого функционала в Erlang кажется неоправданной - пишем на С\С++\итд

При этом вообще в стороне остается вопрос актуальности притягивания Erlang-а в том или ином случае. Например, если разрабатывается GUI-приложение

Например, если разрабатывается GUI-приложение

GUI-приложение

Erlang

Ну ты понял. У нас хоть и есть wx, но удовольствие это сомнительное.

Или, например, если уже есть унаследованная кодовая база из сотен тысяч, если не миллионов строк C++ного кода. Что будет проще: частями переводить этот legacy на обновленную версию C++ с обновлением версий фреймворков (тот же Qt3 на Qt5, Boost.Lambda на C++11 lambda и т.д.) или писать рядом новую версию на Erlang, задействуя куски старого кода в NIF-ах/драйверах/портах?

Разве тут может быть готовый ответ? Зависит от состояния кодовой базы, вестимо. Может имеет смысл переписывать с нуля. А может и просто допиливать напильником, ведь все и так работает.

Ну и если переписывание legacy на новом языке все-таки выгодно, то почему должен рассматриваться именно Erlang, а не Java/Scala+Akka? Или Haskell+CloudHaskell? Или что-то еще?

NIF, драйвер, порт. Вот три магических слова. Если переписывать legacy с С\С++ то именно возможность легкой интеграции Erlang'a с этими языками решает. Но это на мой взгляд.

cyanide_regime
()
Ответ на: комментарий от cyanide_regime

Здорово, если в команде есть опытный хаскелист, но если его нет?

Здорово, если в команде есть опытный Erlang-ист...
Здорово, если в команде есть опытный C-шник...
Здорово, если в команде есть опытный...

Если у вас есть опытная команда C++ников, выбор Erlang-а, на котором никто не программировал, не будет хорошим решением, даже не смотря на уверения LOR-овских экспертов.

Ровно как и наоборот.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Еще раз для анонимных тимлидов: в C++ не нужно реализовывать шедулинг в библиотеке. В C++ используются родные потоки ОС и управляет этим шедулер ОС.

Насколько потоки ОС «тяжелее» эрланговских? Например по памяти.

migesok
()
Ответ на: комментарий от eao197

Если у вас есть опытная команда C++ников, выбор Erlang-а, на котором никто не программировал, не будет хорошим решением, даже не смотря на уверения LOR-овских экспертов.

Если выбирать между простым как топор Erlang'ом и Haskell'ом (будем считать что опытные программисты на С++ ни тот, ни другой не знают), то думаю, скорость обучения языку, развитость платформы и легкость интеграции с С\С++ явно указывает на первый.

cyanide_regime
()
Ответ на: комментарий от cyanide_regime

Разве тут может быть готовый ответ? Зависит от состояния кодовой базы, вестимо. Может имеет смысл переписывать с нуля. А может и просто допиливать напильником, ведь все и так работает.

Ну так в это все и упирается. Есть глобальный выбор — остаемся на C++ или идем куда-то еще?

Если остаемся, то возникает следующий выбор — нужно ли решать проблемы многопоточности в C++ном коде через mutex/semaphores и самодельные thread-safe message queue или же можно применить модель акторов и взять готовый инструмент для этого? А может пойти еще каким-то другим путем?

Если есть смысл пробовать модель акторов, то какой инструмент взять: написать свой или взять какой-то готовый?

Если брать какой-то готовый, то какой именно?

На всех этих уровнях нет какого-то одного универсального ответа, все будут определять конкретные условия. И если так случится, что при поиске ответов на вышеозначенные вопросы кто-то подойдет к последнему пункту, то окажется, что выбор невелик. Из живых OpenSource реализаций есть разве что CAF и SO5.

Как раз на эту тему и хотелось бы поговорить в анонсе инструмента для упрощения разработки на C++.

А не о том, что в абстрактных задачах, граничных условий которых никто не знает, Erlang/C будет круче, чем C++/SObjectizer.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от cyanide_regime

Если выбирать между простым как топор Erlang'ом и Haskell'ом

Между простым как топор C и мегасложным C++ очень многие разработчики выбирают таки C++. Поскольку сложность изучения компенсируется увеличением скорости и надежности разработки.

Аналогично и между Erlang и Haskell. Лишь одна сторона этого спора: динамика vs статика приведет к бесконечным разборкам.

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

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

eao197 ★★★★★
() автор топика
Ответ на: комментарий от migesok

Насколько потоки ОС «тяжелее» эрланговских? Например по памяти.

Полагаю, что значительно. Там, где в Erlang-е без оглядки создается 10K процессов, в C++ нужно сильно подумать, чтобы решиться на такое.

Тем не менее, создать 100 или 500 потоков в нативном приложении можно без проблем, причем, если большая часть из них будет занята ожиданием на синхронных вызовах, то это не будет заметно сказываться на отзывчивости приложения.

Если же синхронных вызовов мало, а стоит задача, например, по-максимуму утилизировать ядра CPU, то смысла создавать множество тяжелых потоков ОС вообще нет.

Собственно, здесь можно уже начинать тему о том, почему программирование на акторах в C++ будет значительно отличаться от такового в Erlang-е.

eao197 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.