пятница, 5 февраля 2016 г.

[prog.c++] Чуток подробнее про сравнение производительности SObjectizer-5.5 и CAF

Продолжение старой темы о том, что мы проводим сравнение производительности SObjectizer-5.5 и CAF. Можно сказать, что портирование бенчмарков закончено и результаты получены. Теперь их нужно представить в удобочитаемом и наглядном виде. Чем и занимаемся. Есть надежда, что опубликуем их на следующей неделе в блоге проекта. Пока подтверждается то, о чем мы говорили ранее: на операциях создания/уничтожения акторов мы значительно, в разы проигрываем CAF, но на операциях обмена сообщениями обычно быстрее, местами ощутимо быстрее.

На обмене сообшениями мы медленнее только в одном вырожденном случае, когда запускается тест agent_ring на thread_pool-диспетчере. По сути это однопоточный бенчмарк, наиболее эффективно он работает, когда все акторы привязаны к одной нити. Но в случае работы на пуле потоков наша схема диспетчеризации проигрывает work-stealing схеме CAF-а.

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

SO-5 вариант, агентов всего 8, зато большое количество сообщений для каждого агента:

coops: 2, agents in coop: 4, msg per agent: 10000000 (at start: 1), total msgs: 80000016

dispatcher: thread_pool

*** demands_at_once: 200
*** threads in pool: default (4)
*** FIFO: individual
total time msec: 6494

Этот же бенчмарк для CAF:

coops: 2, agents in coop: 4, msg per agent: 10000000 (at start: 1), total msgs: 80000016

*** demands_at_once: 200
*** threads in pool: 4
total time msec: 16257

Этот же бенчмарк для CAF, но в более щадящем режиме (стартовое сообщение актору отсылается сразу после его создания, а не после того, как все акторы будут созданы)

coops: 2, agents in coop: 4, msg per agent: 10000000 (at start: 1), total msgs: 80000016

*** demands_at_once: 200
*** threads in pool: 4
total time msec: 15813

Если изменить условия и увеличить количество агентов до 80000, но уменьшить количество сообщений для каждого агента, то получаем для SO-5:

coops: 20000, agents in coop: 4, msg per agent: 1000 (at start: 1), total msgs: 80160000

dispatcher: thread_pool

*** demands_at_once: 200
*** threads in pool: default (4)
*** FIFO: individual
total time msec: 7463

Та же версия для CAF-а:

coops: 20000, agents in coop: 4, msg per agent: 1000 (at start: 1), total msgs: 80160000

*** demands_at_once: 200
*** threads in pool: 4
total time msec: 21262

Этот же бенчмарк для CAF, но в более щадящем режиме (стартовое сообщение актору отсылается сразу после его создания, а не после того, как все акторы будут созданы):

coops: 20000, agents in coop: 4, msg per agent: 1000 (at start: 1), total msgs: 80160000

*** demands_at_once: 200
*** threads in pool: 4
total time msec: 16245

Каждый бенчмарк прогонялся 3 раза, лучший и худший результат отбрасывались (хотя разбежка очень небольшая была). Core i7 2.4GHz, 8Gib RAM, Win10 64bit, GCC 5.3.0 64bit, SO-5.5.15.1, CAF-0.14.4.

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

Короче говоря, если вам нужен быстрый обмен сообщениями между акторами/агентами, то в CAF не ходи, в SO-5 ходи, однако ;)

Отправить комментарий