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

Речь идет о том, что Erlang+C — это реальная альтернатива C++.

а по производительности будет идти ноздря в ноздрю с С++.


Пруфлинк на сравнения или обычное трепло.


Я привел пруф про производительность. То что вы докопались до кода используемого на одном конкретном хосте - ваши проблемы.

В нем есть синтаксические ошибки. Причем, судя по тому, что ошибка в декларации метода класса у вас повторяется несколько раз, вы C++ не видели очень давно.

Я просто не могу править свои посты, считайте тот код псевдокодом. Суть проблемы думаю ясна.

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

Я привел пруф про производительность.

Так и с производительностью не срослось.

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

Ничего подобного. Речь сразу шла о том, какого качества C-шный код будут писать Erlang-еры, которым придется разгонять свой софт C-шными вставками. Вы продемонстрировали: код будет так себе, т.е. в определенных условиях будет работать, а вот шаг вправо, шаг влево и все, приплыздец.

Я просто не могу править свои посты, считайте тот код псевдокодом. Суть проблемы думаю ясна.

Во-первых, не ясна. Попытаясь приплести спецификации исключений, которые уже задеприкейтили, вы привели ошибочный код. Если разработчик продекларировал, что наружу идет KokoException, а внутри своего метода не сделал try/catch с конвертацией любых возможных наследников std::exception в KokoException, то он совершил ошибку. И за эту ошибку он, скорее всего, расплатится std::terminate.

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

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

Так и с производительностью не срослось.

Те 2 мс? Вы серьезно? Я написал откуда они взялись (засчет интерпретации анонимной функции). Вызов NIF'a стоит микросекунды. Или этого много?

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

Те 2 мс? Вы серьезно?

Если вызов нужно делать хотя бы 1000 раз, то разница составит 2s. В определенных задачах это не просто много, а непозволительно много.

Кроме того, если разработка ведется на C++, человеку не придется парится, есть ли интерпретация анонимной функции или нет. Тогда как в Erlang придется.

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

оооо, то есть кукарекалка НЕ ЗНАЕТ, что ЛЮБОЕ исключение можно поймать. Это раз. Два - это то, что либы обычно кидают исключения - наследники от std::exception. А три — если либа кидает какое-то свое исключение, то обычно об этом пишется отдельно. Но даже, если не написано, то можно 1: поймать его 2: вытащить инфу о нем. То есть кукарекалка обосрался аж 5 раз в одном посте. А теперь иди и сделай вдоль.

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

Идиот, суть того примера в том что эксепшен тот невозможно поймать даже catch-all (catch ( ... )) конструкцией. Дуй в свой курятник и не позорься.

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

Кроме того, если разработка ведется на C++, человеку не придется парится, есть ли интерпретация анонимной функции или нет. Тогда как в Erlang придется.

Ты меня не понял - интерпретация анонимной функции была из-за того что она введена в REPL. если скомпилить timer:tc( fun () -> .... end) то эти 2 мс превратятся в десяток мкс.

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

Тогда я не понял, что этот пример должен был показать? Зачем были времена работы приведены? Или этот пример показывает, что Erlang может вызвать C-шные функции, которые внутри себя дергают сторонние C-шные библиотеки?

Так в C++ это делать еще проще, и дешевле. Там даже и на десяток мкс не наберется.

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

Тогда я не понял, что этот пример должен был показать?

Суть примера в том, что некто с комплексом неполноценности влез в тему про С++ и начал говорить о том, что он тоже что-то значит, что он знает что такое ерланг, и что все вокруг, несомненно, ниже его. Типичный такой выскочка, которого в школе били все, даже девочки. Или все еще бьют. Какой смысл вообще ему что-то доказывать?

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

Какой смысл вообще ему что-то доказывать?

А я и не ему :) И не доказываю. Просто хочу, чтобы у постороннего читателя, который задолбался в C++ реализовывать сложные многопоточные приложения на рукописных thread-safe message queues и ручном управлении нитями, не сложилось ощущение, что он возьмет Erlang и все просто так станет зашибись. Тов.cyanide_regime это дело наглядно подтверждает.

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

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

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

Можго поймать, а можно и не поймать.

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

Ну возмёт твой со5 какой нибудь эди с кои8 на перевес. Что, получится безбажно? Ты просто на личность перешел, потому что аргументы закончились. Напиши мне ещё про маллок лучше.

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

Неправильно. Очевидно он привёл код исключительно для бенчмаркинга производительности. Серёзно, товарищ, это ж детский сад.

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

Товарищ, если бы я показал тебе код портов, которые я пишу, ты бы вообще уписался наверное.

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

Скажи, анон. А ты этого товарища во всех его темах преследуешь? Я вот читаю старые его темы, там тоже анон какой-то (ты ли?) доказывает ему что он бесполезняком занимается и тыкает в явные опечатки и оговорки. Ты к нему личную неприязнь испытываешь? кушать не можешь?

Мне просто для анамнеза интересно.

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

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

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

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

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

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

Очевидно он привёл код исключительно для бенчмаркинга производительности.

Т.е. человек взял собственный код, замерял его производительность, ни с чем больше ее не сравнил и просто представил получившиеся у него результаты однократного замера? При этом еще и с последующими оговорками, что второму результату доверять нельзя, т.к. там интерпретация, а не компиляция, а на самом-то деле оно гораздо быстрее...

Это и есть бенчмарк, который должен был показать, что производительную систему можно написать на Erlang-е с C-шными вставками?

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

Тогда я не понял, что этот пример должен был показать?

Этот пример показывает, что там где нужна производительность С, можно заюзать NIF с пенальти в несколько десятков микросекунд. Я облажался только с тем что вбил запуск бенчмарка в REPLe. Завтра буду на работе могу сделать поновой.

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

Суть примера в том, что некто с комплексом неполноценности влез в тему про С++ и начал говорить о том, что он тоже что-то значит, что он знает что такое ерланг, и что все вокруг, несомненно, ниже его. Типичный такой выскочка, которого в школе били все, даже девочки. Или все еще бьют. Какой смысл вообще ему что-то доказывать?

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

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

Этот пример показывает, что там где нужна производительность С, можно заюзать NIF с пенальти в несколько десятков микросекунд.

Ok.

Тогда такой вопрос. А у вас лично был опыт написания NIF-ок, которые устраняют узкие места (т.к. то, что вы показали — это лишь обертка над ALSA)?

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

Сударь, идите лесом. тут как минимум 3 анона. Это раз. Я тебе только 2 раза написал и оба раза о том, что у тебя комплексы. То что ты там кого-то макнул - это твои эротические фантазии, потому что даже тот пример - суть не относящийся к теме.

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

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

В твоем примере на С++ есть не только синтаксические ошибки(что допустимо) и использование deprecated-средств(что простительно), но и логические ошибки. Зачем ты его привел?

Почитал тему. Ты не прав=)

С акторами приходится сталкиваться, в основном, в Scala через Akka. На C++ акторы не использовал, хотя на крестах пишу больше всего. Но не понимаю, почему бы их там не заюзать? Почему это сразу нужно бросать подходящий инструмент(ведь C++ был выбран не зря?) и использовать Erlang(почему, кстати, его, а не Akka на Java/Scala?), да еще и в связки с Си, что ничем хорошим не обернется, т.к. падение кода на Си может быть серьезнее в этом случае, поскольку инфраструктура и люди к таким падениям будут готовы меньше, чем в случае изначального проекта на С или С++. Тем более, что NIF'ы выглядят не слишком читаемо(опять же, по сравнению с нормальным проектом на C или С++).

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

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

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

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

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

Сударь, идите лесом

Раз нечего по делу сказать, то не генерируй шум и удались.

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

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

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

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

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

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

Проще сказать что приделывал на С:

* Поддержку LZMA2 * Подсчет контрольных сумм * Работу со строками (на основе binaries) * В С-ноду ушел сервак работающий на протоколе, который юзает protobuf(то что есть для Эрланга было тормозным почему-то). * Работа с текстовыми протоколами

Справедливости ради стоит отметить что полностью перешло на Эрланг:

* NoSQL DB на основе tokyocabinet + protobuf + asio. На ее место встала ETS-based DB, умеющая все тоже самое (хитрые тригеры, многопоточный доступ и изменение записей, частичная выгрузка на диск и тд.), а работающая значительно быстрее. Объем кода уменьшился раза в 3 даже с учетом С++-интерфейса с оберткой над erl_interface * Вся сетевая работа (за редкими исключениями) * Мониторинг узлов

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

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

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

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

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

почему, кстати, его, а не Akka на Java/Scala?

Мы же говорим о производительности </trollmode> =)

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

Вилами по воде писано. Так уж сложилась ситуация, что Эрлангист не знающий С или С++ - нонсенс пока что, а все потому что иногда без этого просто никак.

Тем более, что NIF'ы выглядят не слишком читаемо(опять же, по сравнению с нормальным проектом на C или С++).

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

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

* NoSQL DB на основе tokyocabinet + protobuf + asio.

А это что, какая-то собственная СУБД была?

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

Ага, правда она не умела в резервное копирование и журнал, но оно там и не было нужно.

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

Ну вы там у себя и навелосипедили, однако...

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

Довольно жесткие требования к структуре и фичам БД: графоподобная структура, тригеры по изменению полей записи, скорость чтения и записи полей объекта не более 1 мс (на спец стенде). Готового решения мы не нашли, а допиливание того что есть оказалось неэффективным.

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

Готового решения мы не нашли, а допиливание того что есть оказалось неэффективным.

Просто интересно, а сколько параллельно работающих с БД клиентов нужно было поддерживать?

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 ()
Ответ на: комментарий от eao197

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

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

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

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

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

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

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

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

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

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

Так вы что пытаетесь сказать: что SO5 не нужен? Или что C++ не нужен?

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

читай выше. я тебя уже раз пятьсот спросил, ты не можешь ответить на мой ответ ©

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

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

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

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

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

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

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

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

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