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

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

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

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

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

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

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

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

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

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

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

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

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

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

пруфов не было => трепло

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

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

Ты просто слепой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ok.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AMQP или MQTT

http://en.wikipedia.org/wiki/RabbitMQ
http://emqtt.io/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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