[prog.c++11] Предварительный качественный итог сравнения производительности SO-5 и CAF

Николай Шмаков проделал большую работу по сравнению производительности SObjectizer (v.5.5.14.1) и C++ Actor Framework (v.0.14.4). Пока тесты проведены на 3-х бенчмарках, взятых из CAF-а, и одного бенчмарка из SO-5. Cо временем, надеюсь, еще пара бенчмарков из SO-5 будет добавлена. Предварительные же результаты оказались занимательными.

SO-5 очень сильно проигрывает CAF-у на операциях создания и удаления акторов/агентов. Очень сильно -- это где-то раз в пять. Впрочем, объясняется это тем, что регистрация агентов в SO-5 всегда была дорогой операцией, т.к. регистрируется не агент, а кооперация, у кооперации должно быть уникальное имя, регистрация кооперации должна быть транзакционной операцией, агенты кооперации должны выполнить ряд действий до начала своей работы и часть этих действий должна быть синхронизирована... В общем, разрыв здесь и ожидаем и объясним. Причем, с нашей точки зрения, ничего катастрофического в дорогой процедуре регистрации нет, т.к. наш опыт показывает, что большое количество агентов -- это не столько решение, сколько сама по себе проблема. По факту же, если вам жизненно необходимо создавать и уничтожать акторов сотнями тысяч в секунду, то для вас CAF будет лучшим выбором, чем SO-5.

А вот что для нас самих оказалось очень удивительно, так это отсутствие отставания SO-5 от CAF в скорости обмена сообщениями между акторами/агентами. Казалось бы, данная процедура в SO-5 имеет кучу накладных расходов (механизм подписок, поиск обработчиков в состояниях агента и т.д.)... Но на практике мы либо идем вровень с CAF-ом, либо заметно его опережаем, либо опережаем ну очень уж сильно (скажем, в таком тривиальном кейсе, как ping-pong). Так что в плане производительности механизма доставки сообщений ситуация прямо противоположна: если вам нужно перекачивать максимум сообщений в секунду, то SO-5 будет лучшим выбором, чем CAF (в том числе и за счет большого набора диспетчеров в SO-5, что позволяет распределять агентов по рабочим нитям более гибко).

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

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

PS. Кстати на счет понятности прикладного кода. Наверняка это мои личные заморочки, но CAF-овские акторы легко воспринимаются пока они очень простые (т.е. уровня "получил сообщение, отослал сообщение"). Но стоит логике агента чуток усложниться, как разбираться с логикой его поведения становится сложнее. В SO-5 с этим обратная ситуация: понять работу простого агента бывает сложнее, чем более навороченного агента.