[comp.prog] Вот как был использован SObjectizer

Сегодня наткнулся в Интернете на статью “Архитектура высокопроизводительной системы многоагентного моделирования”, в которой рассказывается о фреймворке для моделирования под названием ASF. В реализации этого фреймворка использован SObjectizer. А один из авторов статьи, Олег Набиуллин, если я правильно помню, когда-то нашел проблему в so_sysconf_2 (которая, к сожалению, не может быть исправлена в рамках so_sysconf_2, но которую мы устраним в so_sysconf_3).

Статья интересная, проект ребята сделали серьезный. Поэтому приятно было увидеть, как SObjectizer нашел свое применение вне компании Интервэйл.

Интересны и выводы, которые были сделаны в статье. В частности, обсуждение проблем, с которыми столкнулись разработчики ASF. Позволю себе упомянуть часть из них в контексте SObjectizer-5.

Асинхронность. Пока SObjectizer-5 видится мне исключительно как фреймворк для реализации асинхронного взаимодействия. Так что подобная проблема (для некоторых задач это действительно будет проблемой) сохранится. Хотя… Если задействовать возможности C++0x, то может получиться, что в качестве реакций на события можно будет назначать лямбда-функции. Что может упростить некоторые операции. Скажем, агент A отсылает сообщение-запрос агенту B, а агент B должен отослать что-то агенту A в ответ, и этот ответ должен быть каким-то образом обработан (например, сгенерировано сообщение агенту C). В SObjectizer-4 особо ничего уже не придумаешь. Но в SObjectizer-5 можно будет реакцию на ответ от B оформить в виде лямбды, что сократит объем прикладного кода и уменьшит его сложность.

Ненадежность соединения. В статье в качестве возможной альтернативы SObjectizer для реализации ASF упоминался MSMQ. И такие его достоинства, как способность работы в offline и гарантированная доставка. Ничего этого в SObjectizer нет, поэтому при реализации ASF разработчикам приходилось бороться с разрывами соединений и потерями сообщений. В SObjectizer-5 хочется вообще отделить транспортный слой от ядра SObjectizer. Это может позволить сделать иерархию транспортных средств с разными характеристиками. На нижнем уровне будут лежать коммуникационные агенты, аналогичные существующим в SObjectizer-4. А над ними могут быть реализованы средства, характерные для систем обмена сообщениями (TIBCO Rendezvous, MSMQ, JMS) – транзакционность, гарантированная доставка, механизмы publish/subscribe и пр. Что может существенно упростить разработку аналогичных ASF приложений.

Производительность. Разработчики ASF провели сравнение скорости проведения тестового вычислительного эксперимента HeatBugs с аналогичными реализациями в Swarm (Java) и RePast (.NET). ASF-решение оказалось в 1.3 раза медленнее Swarm, и в два раза быстрее RePast. Это значит, что производительность SObjectizer нужно поднимать. Статья была опубликована, как я понимаю, весной 2008, поэтому у разработчиков еще не было возможности попробовать шестую бета версию SObjectizer 4.4.0 (в которой производительность была еще чуть-чуть поднята). Но все равно, хотелось бы получить в SObjectizer-5 производительность на порядок большую, чем в SObjectizer-4.