В.Л. Макаров, А.Р. Бахтизин

Российский экономический
университет имени Г.В. Плеханова Федеральное государственное

(РЭУ имени Г.В. Плеханова) бюджетное учреждение науки
Центральный экономико-
математический институт РАН
Научная Школа
«Пространственные факторы экономики инноваций»
В.Л. Макаров, А.Р. Бахтизин
«Опыт применения суперкомпьютерных технологий

в общественных науках»
СОДЕРЖАНИЕ
Введение........................................................................................................................3
1. Опыт зарубежных ученых и практиков.............................................................4
1.1. Известные примеры запусков агент-ориентированных моделей на
суперкомпьютерах......................................................................................................4
1.2. Среда проектирования агент-ориентированных моделей для
высокопроизводительных вычислений — RepastHPC...........................................9
2. Использование графических процессоров для запуска агент-
ориентированных моделей......................................................................................15
2.1. Возможности графических процессоров........................................................15
2.2. Графические процессоры и агентные модели................................................18
3. Адаптация агент-ориентированныхмоделей для суперкомпьютера: наш
подход...........................................................................................................................23
3.1. Проблема масштабирования............................................................................23
3.2. Специализация и низкоуровневая оптимизация............................................24
3.3. Выбор системы поддержки моделирования...................................................24
3.4. Исходная агент-ориентированная модель......................................................27
3.5. Конвертация модели в суперкомпьютерную программу..............................29
3.6. Трансляция модели...........................................................................................29
3.7. Импортирование входных данных..................................................................31
3.8. Генерация классов и преобразование кода функций.....................................31
3.9. Генерация внешних объектов..........................................................................37
3.10. Генерация классов, генерация кода заголовочного и source-файлов.........37
3.11. Генерация симуляции.....................................................................................39
3.12. Дополнительные параметры..........................................................................40
3.13. Сборка готового проекта................................................................................41
3.14. Код агента........................................................................................................41
3.15. Статистика и визуализация временных срезов............................................43
3.16. Доступные для расчетов суперкомпьютеры.................................................43
3.17. Результаты........................................................................................................44
3.18. Заключение......................................................................................................45
4. Выводы....................................................................................................................48
Литература..................................................................................................................50
3.Адаптация агент-ориентированных моделей для суперкомпьютера: наш подход
Введение
Работа содержит краткий экскурс по вопросам применения
суперкомпьютерных технологий в общественных науках, и в первую очередь, в
части технической реализации крупномасштабных агент-ориентированных
моделей (АОМ). Суть данного инструмента в том, что благодаря увеличению
мощности компьютеров стало возможным описывать поведение многих
отдельных фрагментов сложной системы. В результате мечта многих
мыслителей научиться объяснять макроявление на основе поведения его
составных частей стала воплощаться в реальность. Например, физики, умеющие
описывать поведение элементарных частиц, создали компьютерную имитацию
действий большого ансамбля таких частиц и стали изучать его поведение в
компьютере, а не в жизни. Таким образом появилось понятие искусственной
реальности.
В свою очередь, компьютерное моделирование — широчайшая,
интереснейшая и интенсивно развивающаяся область исследований,
востребованная сегодня практически во всех сферах человеческой деятельности.
Агент-ориентированный подход к моделированию универсален и удобен для
прикладников в силу своей наглядности, но при этом предъявляет высокие
требования к вычислительным ресурсам. Очевидно, что для прямого
моделирования достаточно длительных социальных процессов в масштабах
страны и планеты в целом нужны весьма значительные вычислительные
мощности.
Суперкомпьютеры позволяют на несколько порядков увеличить число
агентов и других количественных характеристик (узлов сети, размеров
территории) в моделях, первоначально разработанных для использования в
обычных настольных компьютерах. Поэтому суперкомпьютерное
моделирование является логичным и крайне желательным шагом для тех
упрощенных моделей, которые уже прошли успешную практическую апробацию
на обычных компьютерах. Увы, специфика архитектуры современных
компьютеров вовсе не гарантирует, что программное обеспечениекомпьютерной
модели немедленно заработает и на суперкомпьютере. Требуется как минимум
распараллеливание счетного ядра, а зачастую и его глубокая оптимизация,
поскольку в ином случае применение дорогостоящего суперкомпьютерного
счета, скорее всего, себя неоправдает.
В этойработемы рассмотрим опыт зарубежных ученых и практиков по
запуску АОМ на суперкомпьютерах, а также на примере АОМ, разработанной в
ЦЭМИ РАН,проанализируем этапы и методы эффективного отображения
счетного ядра мультиагентной системы на архитектуру современного
суперкомпьютера.
3
1.Опыт зарубежных ученых и практиков

1.1.Известные примеры запусковагент-ориентированных моделей на
суперкомпьютерах
В сентябре 2006г. стартовал проект по разработке крупномасштабной
АОМ европейской экономики — EURACE, т.е. EuropeACE(Agent-
basedComputationalEconomics), с очень большим количеством автономных
агентов, взаимодействующих в рамках социально-экономической системы
[Deissenberg, SandervanderHoog, Herbert, 2008]. В проект вовлечены экономисты
и программисты из восьми научно-исследовательских центров Италии, Франции,
Германии, Великобритании и Турции, а также консультант из Колумбийского
университета США — нобелевский лауреат Джозеф Стиглиц.
Чтобы преодолеть ограничения широко распространенных моделей,
рассматривающих агрегированные агенты, а также предполагающих их
рациональное поведение и состояние равновесия, в основу исследования была
положенаметодологияACE(AgentBasedComputationalEconomics, агент-
ориентированная экономика).
Для модели используется географическая информационная система,
охватывающая широкий перечень объектов — предприятия, магазины, школы,
транспортные сети и т.д.
Как отмечают разработчики, практически все существующие АОМ
рассматривают либо отдельную отрасль, либо относительно небольшой
географический район и, соответственно, небольшую популяцию агентов, а
вEURACE представлен весь Европейский союз, так что по масштабам и
сложности эта модель является уникальной, а ее численное разрешение требует
использования суперкомпьютеров, а также специального программного
обеспечения.
Для наполнения модели статистической информацией использовались
данные (в виде геоинформационных карт) статистической службы Европейского
союза уровня NUTS-21, представляющие сведения о 268 регионах 27 стран.
В модели три типа агентов: домашние хозяйства (около 10 7), предприятия
(около 105) и банки (около 102). Все они имеют географическую привязку, а
также связаны друг с другом посредством социальных сетей, деловых
отношений и т.д.
EURACE реализована с помощью гибкой масштабируемой среды для
моделирования агентных моделей —FLAME (FlexibleLarge-
scaleAgentModelingEnvironment), разработанной Симоном Коакли и Майклом
Холкомбом2 первоначально для моделирования роста клеток, выращиваемых в
1
NUTS (фр. Nomenclaturedesunitésterritorialesstatistiques) — Номенклатура территориальных
единиц для целей статистики,представляющая собой стандарт территориального деления
стран для статистических целей, разработанный Европейским союзом и охватывающий
входящие в него страны. Существуют NUTS-единицы трех уровней, при этом второй уровень
(NUTS-2) соответствует административным округам в Германии, графствам в
Великобритании и т.д.
2
Более подробно см. www.flame.ac.uk
4
различных условиях.Используемый в FLAME подход основан на так
называемых X-машинах, напоминающих конечные автоматы, но отличающихся
от них тем, что у каждой X-машины есть набор данных (своего рода память), а
также тем, что переходы между состояниями являются функциями не только
состояния, но и набора данных памяти.
Итак, каждый агент в системе FLAME представлен X-машиной, причем
предусмотрено общение между агентами посредством передачи сообщений. При
работе в параллельном режиме на суперкомпьютере обмен сообщениями между
агентами требует больших вычислительных затрат, в связи с чем агенты
изначально были распределены по процессорам в соответствии с их
географическим положением. Тем самым разработчики программы
минимизировали вычислительную нагрузку, исходя из предположения, что в
основном общение между агентами происходит в рамках небольшой социальной
группы, локализованной в определенной местности. Таким образом, весь
модельный ландшафт был поделен на небольшие территории и распределен
между узлами суперкомпьютера.
С помощью разработанной модели был проведен ряд экспериментов с
целью исследования рынка труда. Не рассматривая детально полученные
числовые результаты, отметим, что, по мнению авторов, основной вывод
исследования заключается в том, что макропоказатели двух регионов со
схожими условиями (ресурсы, развитие экономики и т. д.) в течение
продолжительного периода (10 лет и более) могут значительно разойтись за счет
первоначальной неоднородности агентов.Более подробную информацию можно
найти на веб-странице проекта: www.eurace.org.
ВАОМEpiSims, разработанной исследователями из Института
биоинформатики Вирджинии (VirginiaBioinformaticsInstitute), рассматриваются
как перемещения агентов, так и их контакты в рамках среды, максимально
приближенной к реальности и содержащей дороги, здания и прочие
инфраструктурные объекты [Roberts, Simoni, Eubank, 2007]. Для построения
модели потребовался большой массив данных, включающий информацию о
здоровье отдельных людей, их возрасте, доходе, этнической принадлежности и
т.д.
Исходная цель исследования заключалась в построении для запуска на
суперкомпьютере АОМ большой размерности, с помощью которой можно будет
изучать распространение болезней в обществе. Однаковпоследствиив процессе
работы также решалась задача по созданию специализированного программного
обеспечения ABM++, которое позволяет осуществлять разработку АОМ на
языке C++, а также содержит функции, облегчающие распределение
исполняемого программного кода на узлах кластеров суперкомпьютера. Помимо
этого, ABM++ предоставляет возможность динамического перераспределения
потоков вычислений, а также синхронизации происходящих событий.
ABM++, первая версия которого появилась в 2009 г., представляет собой
результат модернизацииинструмента, разработанного в 1990–2005 гг. в Лос-
5
Аламосской национальной лаборатории в процессе построения
крупномасштабныхАОМ (EpiSims, TRANSIMS, MobiCom).
Межпроцессорные связи между вычислительными узлами в АОМ часто
требуют синхронизации происходящих в модели событий. ABM++ позволяет
разрабатывать модели, отвечающие этому требованию. К примеру, в социальных
моделях агенты часто перемещаются между различными точками пространства
(работа, дом и т.д.), а на программном уровне этому соответствует смена узла
кластера, и здесь важно, чтобы модельное время принимающего узла было
синхронизировано со временем узла, который агент только что покинул.
Также в ABM++ реализована библиотека MPIToolbox, которая соединяет
интерфейс C++ API (ApplicationProgrammingInterface) и MessagePassingInterface
(MPI) суперкомпьютера и ускоряет передачуданных между узлами кластеров.
ABM++ создавалось в UbuntuLinux — операционной системе с
компиляторами gcc/g++. В качестве интегрированной среды разработки
рекомендуется пакет Eclipseс плагином для поддержки C и C++, а также с
плагином PTP (ParallelToolsPlatform), обеспечивающим разработку и
интеграцию приложений для параллельных компьютерных архитектур. Eclipse
поддерживает интеграцию с TAU (TuningandAnalysisUtilities) PerformanceSystem
— инструментом для разностороннего анализа и отладки программ для
параллельных вычислений, что также упрощает разработку агентных моделей.
Специалисты другой исследовательской группы из того же Института
биоинформатики Вирджинии создали инструмент для изучения особенностей
распространения инфекционных заболеваний внутри различных групп населения
—EpiFast, к достоинствам которого можно отнести масштабируемость и
высокую скорость исполнения. К примеру, имитация социальной активности
жителей Большого Лос-Анджелеса (агломерации с населением свыше 17 млн
человек) с 900 млн связей между людьми на кластере с 96 двухъядерными
процессорами POWER5 заняла менее пяти минут. Такая достаточно высокая
производительность обеспечивается предложенным авторами оригинальным
механизмом распараллеливания [Bisset, Chen, Feng, Kumar, Marathe, 2009].
Как правило, для реализации моделирования социума на группе
процессоров используют несколько естественных способов. К примеру, один из
них базируется на представлении социума в виде набора неструктурированных
связей между индивидуумами. При распараллеливании эти связи равномерно
распределяются на группы, количество которых соответствует числу
процессоров. Минус такого подхода заключается в сложности отслеживания
статуса отдельного человека, т.е. если, к примеру, i-й индивидуум инфицирован,
то информация об этом должна быть синхронизирована во всех группах, так как
мы не знаем, в каких из них содержатся связи данного человека. Необходимость
такой синхронизации влечет за собой большую вычислительную нагрузку.
Другой подход основан на разделении людей — агентов модели в соответствии с
их географическим местоположением. Однако в этом случае, поскольку
население обычно расселено неравномерно, распределение вычислительной
6
нагрузки требует применения достаточно сложных алгоритмов для ее
выравнивания, что также создает дополнительную вычислительную нагрузку.
Предлагаемый авторами метод заключается в равномерном распределении
агентов с соответствующими им односторонними исходящими связями по
группам, количество которых равно числу процессоров.Вычислительный
алгоритм основан на взаимодействии ведущих (master) и ведомых (slave)
процессоров, организованном следующим образом: ведущий процессор «знает»,
какой из процессоров обслуживает конкретного агента, а каждый из ведомых
процессоров «знает» только обслуживаемых (локальных) агентов. В процессе
вычислений ведомые процессоры посылают ведущим процессорам запросы
относительно связей с нелокальными агентами. Ведущие процессоры не
осуществляют никаких расчетов, кроме поиска нелокального агента для каждой
внешней связи, и пересылают запросы соответствующим процессорам.
По мнению разработчиков, предложенныйими алгоритм позволяет
проводить эффективные и высокоскоростные симуляции систем с очень
большим числом агентов.
Классические модели распространения эпидемий преимущественно
основывались на использовании дифференциальных уравнений, однако такой
инструментарий затрудняет учет связей между отдельными агентами и их
многочисленных индивидуальных особенностей.АОМ позволяют преодолеть
указанные недостатки.В 1996 г. Джошуа Эпштейн и Роберт Акстелл
опубликовали описание одной из первых АОМ, в которой рассматривается
процесс распространения эпидемий [Epstein, Axtell, 1996]. Агенты модели,
отличающиеся друг от друга восприимчивостью к заболеванию, которая зависит
от состояния иммунной системы, распределены на определенной территории.
При этом в данной модели агенты, число которых всего несколько тысяч,
реализуют достаточно примитивное поведение.
В дальнейшем под руководством Джошуа Эпштейна и Джона Паркера в
Центре социальной и экономической динамики Брукингского института
(CenteronSocialandEconomicDynamicsatBrookings) была построена одна из самых
больших АОМ, включающая все население США, т. е. порядка 300 млн агентов
[Parker, 2007]. Данная модель имеет ряд преимуществ. Во-первых, она позволяет
предсказать последствия распространения заболеваний различного типа. Во-
вторых, она ориентирована на поддержку двух сред для вычислений: одна среда
состоит из кластеров с установленной 64-битной версией Linux, а другая — из
серверов с четырехъядерными процессорами и установленной системой
Windows (в этой связи в качестве языка программирования был выбран Java,
хотя разработчики и не уточняют, какую именно реализацию Java они
использовали). В-третьих, модель способна поддерживать численность агентов
от нескольких сотен миллионов до 6 млрд.
Способ распределения агентов между аппаратными ресурсами состоит из
двух фаз: сначала агенты распределяются по компьютерам, задействованным в
работе, а затем по потокам на каждом из компьютеров. В процессе работы
модели каждый поток может остановиться (в заранее обусловленное время) для
7
передачи сообщений другим потокам. Все подготовленные к отправке
сообщения до определенного момента хранятся в пуле сообщений, а затем
одновременно отправляются.Также в реализации модели есть две
вспомогательные утилиты: первая управляет потоками на отдельном
компьютере, а вторая следит за тем, чтобы все сообщения между потоками были
выполнены до момента возобновления вычислительного процесса.
При распределении агентов по аппаратным ресурсам следует учитывать
два обстоятельства: 1) производительность узла напрямую зависит от количества
инфицированных агентов; 2) контакты, предполагающие передачу сообщений
между потоками, требуют гораздо больше вычислительных затрат, чем
контакты, ограничивающиеся локальной информацией. Исходя из этого,
возможны различные распределения агентов. С одной стороны, можно поделить
все рассматриваемое географическое пространство на равные части, количество
которых должно соответствовать числу узлов, а затем определить для каждого
узла какой-либо географический регион. Такое распределение
позволяетсбалансировать вычислительную нагрузку между узлами. С другой
стороны, можно закрепить определенную территорию, представляющую собой
единую административную единицу, за конкретным узлом — в этом случае
вычислительную нагрузку удастся сократить за счет снижения числа контактов,
предполагающих передачу сообщений между потоками. Если первый способ
влечет за собой увеличение вычислительной нагрузки за счет ресурсоемких
контактов, то второй в ряде случаев чреват значительным дисбалансом между
аппаратными ресурсами. К примеру, вспышка какого-либо заболевания в одном
из регионов загрузит один из вычислительных узлов, в то время как некоторые
другие будут простаивать.
Рассматриваемая модель (USNationalModel) включает 300 млн агентов,
перемещающихся по карте страны в соответствии с матрицей корреспонденций
размерностью 4000×4000, специфицированной с помощью гравитационной
модели. На USNationalModel был проведен вычислительный эксперимент,
имитирующий 300-дневный процесс распространения болезни, которая
характеризуется 96-часовым периодом инкубации и 48-часовым периодом
заражения. В исследовании, в частности, было установлено, что
распространение заболевания идет на спад, после того как 65% зараженных
выздоровели и приобрели иммунитет. Эту модель неоднократно использовали
специалисты Университета Джонса Хопкинса (JohnsHopkinsUniversity), а также
Департамента национальной безопасности США для исследований,
посвященных стратегии быстрого реагированиянаразличного рода эпидемии
[Epstein, 2009].
В 2009 г.была созданавторая версияUSNationalModel, включающая 6,5
млрд агентов, спецификация действий которых проводилась с учетом
имеющихся статистических данных. С ее помощью имитировались последствия
распространения вируса гриппа A(H1N1/09) в масштабах всей планеты.
Ранее подобная модель была разработана в Лос-Аламосской национальной
лаборатории (США), и результаты работы с ней были представлены в широкой
8
печати 10 апреля 2006 г. [Ambrosiano, 2006].Для технической реализации модели
был использован один из мощнейших по тем временам суперкомпьютеров с
именем Pink, состоящий из 1024 узлов, с двумя процессорами с частотой 2.4 ГГц
и 2 ГБ памяти на каждом.С помощью этой крупномасштабной модели,
включающей 281 млн агентов, были рассмотрены сценарии распространения
различных вирусов, в том числе и H5N1, с учетом тех или иных оперативных
вмешательств: вакцинации, закрытия школ и введения карантина на некоторых
территориях.
Естественно, для подобных задач можно использовать не только
суперкомпьютеры, но и более дешевые решения. Показателен пример ученых
Университета Ньюкасла из Австралии (TheUniversityofNewcastle, Australia),
построивших кластер, включающий 11 узлов — отдельных персональных
компьютеров, объединенных в сеть с пропускной способностью до 100 Мбит/с
[Lynar, Herbert,Chivers, 2009].Программное обеспечение узлов кластера было
одинаковое: операционная система DebianGNU/Linux и JavaParty —
кроссплатформенное программное расширение языка Java (ПО JavaParty
располагаетсредствами для распределения потоков выполнения кода по узлам
кластеров).Для оценки производительности кластера были использованы три
версии одной АОМ, в рамках которой тестировались различные стратегии
агентов, принимающих участие в аукционе. Версии различались сложностью
стратегий агентов.
Основной вывод тестирования заключается в том, что использование
кластеров оправданно лишь тогда, когда вычислительная нагрузка отдельных
узлов достаточно интенсивная; в противном случаераспределение потоков,
наоборот, уменьшает скорость работы модели. Отметим от себя, что такое
поведение кластерных приложений неспецифично.
1.2.Среда проектирования агент-ориентированных моделей для

высокопроизводительных вычислений —RepastHPC
Отдельного внимания заслуживает программное обеспечение,
разработанное для проектирования АОМ с целью последующего запуска на
суперкомпьютерах, —RepastforHighPerformanceComputing (RepastHPC). Данный
пакет реализован с использованием языка C++ и MPI — программного
интерфейса для обмена сообщениями между процессами, выполняющими задачу
в параллельном режиме, а также библиотеки Boost, расширяющей C++.
В рамках RepastHPC реализован динамический дискретно-событийный
планировщик выполнения программных инструкций с консервативными
алгоритмами синхронизации, предусматривающими задержку процессов для
соблюдения определенной очередности их выполнения.
В RepastHPC агенты распределяются между процессами, и каждый
процесс связан с агентом, являющимся локальным по отношению к данному
процессу. В свою очередь агент локален к процессу, выполняющему
программный код, описывающий поведение данного агента. При этом копии
остальных —нелокальных— агентов могут присутствовать в любом процессе,
9
что позволяет агентам всей модели взаимодействовать с этими копиями. К
примеру, пусть пользователь в своей модели, предполагающей параллельные
вычисления, использует два процесса —P1 и P2, каждый из которых создает
определенное количество агентов и имеет собственный планировщик
выполнения программных инструкций. Агенты, поведение которых
рассчитывается на процессе P1, являются локальными по отношению к данному
процессу, и только в рамках данного процесса программный код может изменить
их состояние (аналогично и для процесса P2). Предположим, процесс P1
запрашивает копию агента A2 из процесса P2. Агент A2 не является локальным
по отношению к процессу P1, и соответственно программный код, выполняемый
в рамках процесса P1, не может изменить состояние агента A2. При этом агенты,
реализуемые в рамках процесса P1, при необходимости могут запросить
состояние агента A2, но копия A2 останется неизменной. Изменение
оригинального A2 возможно только в рамках процесса P2, но в этом случае
RepastHPC синхронизирует изменения состояния агента между всеми
процессами.
Пример агентной модели в RepastHPC

Как правило, для реализации агентной модели в рамках RepastHPC
требуются: 1) классы объектов типа «Агент» (листинг1); 2) класс верхнего
уровня — Model; 3) функция main.
…
class Agent {
public :
virtual ~Agent () {}
virtualAgentId&getId () = 0;
virtualconstAgentId&getId () const = 0;
};
…
Листинг1.Пример интерфейса класса «Агент»
В листинге2создается конструктор класса с единственной переменной

_state типа int, которая определяет состояние агента. Естественно, в моделях
агенты обычно имеют более сложную структуру.
…
classModelAgent : public repast :: Agent {
private :
repast :: AgentId _id ;
int _state ;
public :
ModelAgent( repast :: AgentId id , int state );
virtual ~ ModelAgent ();
int state () const {
return _state ;
}
10
voidstate (intval ) {
_state = val ;
}
repast :: AgentId&getId () {
return _id ;
}
const repast :: AgentId&getId () const {
return _id ;
}
voidflipState ();
};
…
Листинг2.Конструктор класса, определяющего состояние агента
Далеесоздается структура, позволяющая скопировать агент от одного

процесса к другому (листинг3).
…
structModelAgentPackage {
friend class boost :: serialization :: access ;
template<class Archive >
void serialize ( Archive &ar , const unsigned int version ) {
ar& id;
ar& state ;
}
repast :: AgentId id;
int state ;
repast :: AgentIdgetId () const {
return id;
}
};
…
Листинг3.Пример структуры, осуществляющей копирования агента между

процессами
Класс верхнего уровня Model нужен для начальной инициализации модели

и для старта симуляции. Как правило, в рамках данного класса осуществляется
распределение агентов по процессам, а также создается среда для
функционирования агентов (решетка или непрерывное пространство). Кроме
того, происходит инициализация данных для модели и планирование расписания
для синхронизации. В листинге4 приведен пример определения класса Model.
…
class Model {
private :
int rank ;
public :
repast :: SharedContext<ModelAgent> agents ;
11
repast :: SharedNetwork<ModelAgent , ModelEdge>* net ;
repast :: SharedGrids<ModelAgent>:: SharedWrappedGrid * grid ;
repast :: DataSet * dataSet ;
Model ();
virtual ~ Model ();
voidinitSchedule ();
void step ();
}
…
Листинг4.Инициализация модели (пример класса Model)
В листинге 5 создается конструктор класса Model. Сначала определяется

ранг процессов, в рамках которых выполняются симуляции, а затем в качестве
примера создаются 4 агента с уникальным номером и определением
обслуживающего процесса. Также определяется среда для взаимодействия
агентов — решетка размерностью 40×60 и назначается источник данных.
…
constMODEL_AGENT_TYPE = 0;
Model :: Model()
{
rank = RepastProcess :: instance() ->rank();
for (inti = 0; i< 4; i++) {
AgentIdid(i, rank , MODEL_AGENT_TYPE);
agents.addAgent (newModelAgent (id, rank));
}
net = newSharedNetwork<ModelAgent , ModelEdge> ("network", true);
agents.addProjection(net);
grid = newSharedGrids<ModelAgent>:: SharedWrappedGrid ("grid",
GridDimensions (Point <int> (40, 60)),
std :: vector <int>(2, 2), 2);
agents.addProjection(grid);
NCDataSetBuilder builder ("./output/data.ncf", RepastProcess
:: instance () ->getScheduleRunner(). schedule());
StateSum * sum = newStateSum (this);
builder .addDataSource ( repast :: createNCDataSource ("state_sum",
sum, std :: plus <int>()));
dataSet = builder . createDataSet ();
Provider provider (this);
AgentsCreator creator (this);
grid ->synchBuffer<ModelPackage>(agents, provider, creator);
}
…
Листинг5. Пример конструктора класса Model
В листинге6 приведен пример инициализации планировщика. Как видно,

остановка происходит на 2000-м шаге, но при этом на каждом шаге вызывается
12
метод step, а также осуществляется изменение состояния агентов и запись
данных.
…
voidModel :: initSchedule () {
ScheduleRunner& runner = RepastProcess :: instance () ->
getScheduleRunner ();
runner.scheduleStop (2000) ;
runner.scheduleEvent (1, 1, Schedule :: FunctorPtr (new
MethodFunctor<Model > (this ,& Model :: step)));
runner.scheduleEvent (1.1 , 1, Schedule :: FunctorPtr (new
MethodFunctor<DataSet> (dataSet ,&DataSet :: record)));
Schedule :: FunctorPtrdsWrite = Schedule :: FunctorPtr (new
MethodFunctor<DataSet> (dataSet ,&DataSet :: write));
runner.scheduleEvent (25.2, 25, dsWrite);
runner.scheduleEndEvent (dsWrite);
}
…
Листинг6.Инициализация планировщика модели
И наконец, функция main обычно осуществляет инициализацию MPI в

рамках RepastHPC, создает класс Model и запускает планировщик модели
(листинг7).
…
int main (intargc, char ** argv ) {
mpi :: environment env(argc, argv );
std :: string config = argv [1];
std :: string propsfile = argv [2];
try {
RepastProcess :: init (config);
Properties props (propsfile);
repast :: initializeRandom (props);
Model model ();
model.initSchedule ();
ScheduleRunner& runner = RepastProcess :: instance () ->
getScheduleRunner ();
runner.run ();
} catch (std :: exception & ex) {
std :: cerr<< "Error while running the rumor model : " <<
ex. what () <<std :: endl ;
throw ex;
}
RepastProcess :: instance () ->done ();
return 0;
}
…
Листинг7.Пример функции main
13
Более подробно сданным ПО можно познакомиться в руководстве

пользователя [Collier,2012], а по адресу
http://repast.sourceforge.net/repast_hpc.html можно скачать версию пакета 1.0.1 (по
состоянию на 5 марта 2012 г.).
14
2. Использование графических процессоров для запуска агент-

ориентированных моделей
В этом разделе мы рассмотрим возможность запуска агентных моделей с
использованием графических процессоров (GraphicsProcessingUnit, GPU) вместо
обычных центральных процессоров (CentralProcessingUnit, CPU).
2.1.Возможности графических процессоров

Ядра CPU предназначены для исполнения одного потока
последовательных инструкций с максимальной производительностью, в то время
как GPU изначально проектировались для параллельного выполнения большого
числа инструкций. Различия между CPU и GPU связаны еще и с кэшированием,
а также со спецификой механизмов доступа к встроенным контроллерам памяти.
Помимо этого, частота работы CPU имеет ограничения, связанные с
физическими условиями —работа огромного числа (свыше миллиарда)
транзисторов создает помехи внутри схемы, — а также с высоким
энергопотреблением. Сравнение частот различных процессоров компании Intel
(рис.1) свидетельствует о том, что в последние несколько лет частота
процессоров уже практически не прирастает, а колеблется в районе 3,4 ГГц.
Рис. 1.Тактовая частота процессоров компании Intel (ось ординат имеет

логарифмическую шкалу)3
3
http://www.r-bloggers.com/cpu-and-gpu-trends-over-time/
15
Ресурс дальнейшего увеличения производительности основные
разработчики процессоров — компании Intel и AMD — видят в увеличении
числа ядер. Так, в 2011г. получили распространение 8-ядерные процессоры от
компании Intel. Эта же компания еще в 2009 г. продемонстрировала опытный
образец 48-ядерного процессора, представляющего собой одночиповый
облачный компьютер (Single-chipCloudComputer, SCC), дальнейшее развитие
которого состоит в увеличении числа ядер до ста уже в ближайшие годы 4.
Однако в настоящее время в CPU число ядер несоизмеримо меньше, чем в GPU
(рис. 2).
Рис. 2.Ядра в CPU и GPU
Поддержка многопоточности у этих двух типов процессоров существенно

различается. Если CPU исполняет один-два потока на ядро, то у GPU работа
простая и распараллеленная изначально и видеочипы поддерживают до 1024
потоков на каждый мультипроцессор, которых в чипе несколько штук.
Переключение с одного потока на другой для CPU стоит сотни тактов, а GPU
переключает несколько потоков за один такт [Берилло, 2008].
За последнее десятилетие в области вычислений над операциями с
плавающей точкой графические процессоры намного опередили центральные
процессоры (рис. 3).
4
http://techresearch.intel.com
16
Рис. 3.Сравнительная производительность CPU и GPU в области вычислений

над операциями с плавающей точкой за последнее десятилетие5
Справедливости ради надо сказать, что цифры на рис. 3 приведены для

операций с одинарной точностью, а для двойной точности соотношение
производительностей будет другим, но для большинства параллельных задач
одинарной точности вполне хватает. Так, на сайте компании NVIDIA—мирового
лидера в разработке графических ускорителей и процессоров для них —
приведены данные по увеличению производительности программ за счет
переноса расчетов на видеочипы6. Усредненные оценки демонстрируют
ускорение по сравнению с универсальными процессорами в 30–50 раз, а
максимальные оценки доходят до 1500 (!) раз.
Для облегчения вычислений на GPU, поддерживающих технологию
GPGPU (General-PurposeGraphicsProcessingUnits), т.е. технологию произвольных
вычислений на видеокартах, компания NVIDIA выпустила программно-
аппаратную архитектуру CUDA (ComputeUnifiedDeviceArchitecture),которая
позволяет эффективно управлять памятью графического ускорителя,
организовывать доступ к его набору инструкций и эффективно осуществлять
параллельные вычисления. В основе CUDAAPI лежит C-подобный язык
программирования со своим компилятором и библиотеками для вычислений на
GPU.
В процессе выполнения программы отдельные операции
осуществляетCPU, в то время как код CUDA с параллельными вычислениями
5
http://www.r-bloggers.com/cpu-and-gpu-trends-over-time/
6
www.nvidia.ru
17
выполняется потоками на GPU, и эта часть программы называется ядром
(kernel). Потоки содержат счетчик, регистры и состояние. Для больших объемов
данных (обработка изображений высокой четкости и т.д.) запускаются
миллионы потоков. Потоки объединяются в одномерные или двумерные блоки
потоков (threadblock), которые взаимодействуют друг с другом с помощью
разделяемой памяти и точек синхронизации. Блоки потоков выполняются в виде
групп, которые называются варпами (warp) и содержат 32 потока (это
минимальный объем обрабатываемых мультипроцессором данных). Помимо
этого, в зависимости от задачиCUDA поддерживает выполнение блоков с
размерностью от 64 до 512 потоков (или совокупность варпов от 2 до 16). Блоки
могут быть одно-, двух- или трехмерными по форме, и их совокупность,
называемая сеткой (grid), выполняется на GPU. В каждый момент времени
выполняется одна сетка.
Каждый такт GPU выбирает, какой из варпов исполнять, и переключается
от одного к другому без потерь в тактах. Если проводить аналогию с
центральным процессором, то это похоже на одновременное исполнение
программ, число которых равно числу варпов,а переключение между ними
каждый такт происходит без потерь на переключение контекста. Реально ядра
CPU поддерживают единовременное выполнение одной программы и
переключаются на другие с задержкой в сотни тактов.Одна из главных задач
разработчика, использующего CUDA, — добиться оптимального баланса между
размером и количеством блоков [Берилло, 2008]. Увеличение количества
потоков в блоке сократит влияние задержек памяти, но снизит и доступное число
регистров. Кроме того, блок из 512 потоков неэффективен, и сама NVIDIA
рекомендует использовать блоки по 128 или 256 потоков как компромиссное
решение для достижения оптимальных значений задержек и количества
регистров.
2.2.Графические процессоры и агентные модели

Представляет интерес опыт ученых из Оак-Риджской национальной
лаборатории КэльянаПерумалла и БрэндонаАаби, которые в многочисленных
статьях, размещенных на сайте http://kalper.net/kp, описывают алгоритмы запуска
АОМна суперкомпьютерах двух видов — на основе графических и центральных
процессоров. В общих чертах эти алгоритмы схожи с рассмотренными выше, т.е.
агенты распределяются по процессорам исходя из их географического
расположения. Наибольший интерес в этих статьях представляет сравнение
производительности CPU и GPU при реализации некоторых агентных моделей,
предусматривающих графическое отображение.
К примеру, при тестировании производительности выполнения игры
«Жизнь» (Conway'sGameofLife) размерностью 3750×3750 (т.е. с максимальным
количеством агентов, приблизительно равным 14 млн), по словам
исследователей, скорость GPU была почти в 14 раз выше, чем у CPU
[Perumalla,Aaby, 2008].Но при этом авторы отмечают, что такое преимущество
имеет место только для отдельных задач и, конечно же, GPU не являются
18
полноценной заменой CPU (в их нынешнем виде они для этого и не
предназначены).
Тем не менее решения на базе GPU становятсявсе популярнее. Так, к
примеру, персональный компьютер на базе процессора NVIDIATesla C2070 с
448 ядрами CUDA может обеспечить пиковую производительность до 1
терафлопа, т.е. в сотни раз быстрее обычного ПК. Кроме того, такого рода
суперкомпьютер компактен (чуть больше обычного системного блока), не
нуждается в дополнительных системах охлаждения и электропитания (требуется
лишь блок питания от 700Вт до 1кВт в зависимости от конфигурации). Цена
такого персонального суперкомпьютера с потрясающей для его размеров
производительностью составляет $6000–7000, что несопоставимо меньше
стоимости суперкомпьютеров на основе CPU.
Мы также осуществили запуск игры «Жизнь» на графическом
суперкомпьютере в ЦЭМИ РАН, добившись значительного увеличения прироста
в скорости исполнения за счет использования CUDA на GPU вместо кода C++ на
CPU. Пример соответствующегоCUDA-кода приведен в листинге8, а
графическое отображение самой игры — на рис. 4.
Директива __global__ сообщает компилятору, что функция gol_kernel
будет выполняться на GPU, а не на CPU, threadIdx — индекс текущего потока
(индекс принимает значения между 0 и blockDim— 1), blockIdx — индекс
текущего блока (индекс блока принимает значения между 0 и gridDim — 1).
Конструкция __shared__ означает, что массив GoLArray будет храниться в
разделяемой памяти, за счет использования которой значительно увеличивается
производительность всего приложения. Синхронизация потоков (xIndex, yIndex)
обеспечивается функцией __syncthreads().
…
__global__ void gol_kernel(int * in, int * out, int width, int height)
{
__shared__ intGoLArray[blockDim+2][blockDim+3];
inttx = threadIdx.x, ty = threadIdx.y;
intbx = blockIdx.x, by = blockIdx.y;
intxIndex = tx + bx*blockDim;
intyIndex = ty + by*blockDim;
int index = xIndex + yIndex*width;
int ii, jj, neighbrs;
GoLArray[tx+1][ty+1] = (xIndex< width &&yIndex< height) ? in[index] : 0;
if (tx == 0)
{
GoLArray[0][ty+1] = (xIndex> 0 &&yIndex< height) ? in[index - 1] : 0;
GoLArray[BLOCKDIM+1][ty+1] = (xIndex+blockDim< width
&&yIndex< height) ?in[index + blockDim] : 0;
}
if (ty == 0)
{
GoLArray[tx+1][0] = (xIndex< width &&yIndex>ty) ? in[index - width] : 0;
GoLArray[tx+1][BLOCKDIM+1] = (yIndex+blockDim< height
&&xIndex< width) ?in[index + blockDim*width] : 0;
19
}
if (tx == 0 &&ty == 0)
{
if (xIndex> 0 &&yIndex> 0)
GoLArray[0][0] = (xIndex< width &&yIndex< width)
? in[index - blockDim - 1] : 0;
else
GoLArray[0][0] = 0;
if (xIndex> 0 &&yIndex+blockDim< height)
GoLArray[0][blockDim+1] = (xIndex< width)
? in[index - 1 + blockDim*width] : 0;
else
GoLArray[0][blockDim+1] = 0;
if (xIndex+blockDim< width &&yIndex> 0)
GoLArray[blockDim+1][0] = (yIndex< height)
? in[index + blockDim - width] : 0;
else
GoLArray[blockDim+1][0] = 0;
if (xIndex+blockDim< width &&yIndex+blockDim< height)
GoLArray[blockDim+1][blockDim+1] =
in[index + 1 + blockDim*width];
else
GoLArray[blockDim+1][blockDim+1] = 0;
}
__syncthreads();
tx++;
ty++;
if (xIndex< width &&yIndex< height)
{
for (ii = -1, neighbrs = 0; ii <= 1; ii++)
{
for (jj = -1; jj<= 1; jj++)
{
if (ii != 0 || jj != 0)
neighbrs += GoLArray[tx+ii][ty+jj];
}
}
if (GoLArray[tx][ty])
{
if (neighbrs == 2 || neighbrs == 3)
{
out[index] = 1;
}
else
{
out[index] = 0;
}
}
else
{
if (neighbrs == 3)
20
{
out[index] = 1;
}
else
{
out[index] = 0;
}
}
}
}
…
Листинг 8.Фрагмент CUDA-кода игры «Жизнь»
Рис. 4.Игра «Жизнь» размерностью 1024×1024
21
В настоящее время в распоряженииразработчика решений с
использованиемCUDA имеется множество инструментов: NVIDIAParallelNsight,
CUDASDK и др., библиотеки CUDABLAS, CUDAFFT и др. Кроме того, есть
компиляторы с автоматическим распараллеливанием —PGI Fortran, CAPS HMPP
C и др.
Особенно приятно, что большинство пакетов для символьных вычислений
(MATLAB, Mathematica) поддерживает CUDA, причем многие технические
сложности, к примеру связанные с управлением памятью GPU, эти программы
осуществляют в автоматическом режиме.
Резюмируя, отметим, что как GPU приближаются к CPU, становясь более
универсальными за счет увеличивающихся возможностей по расчетам чисел с
двойной и одинарной точностью, так и в CPU растет число ядер, а
соответственно и способность к параллельным расчетам. Более того, известно,
что у крупнейшего производителя CPU— компании Intel— есть свои разработки
в области GPU (к примеру, процессор Larrabee), да и у компании AMD тоже. Все
это дает основания предполагать, что GPU и CPU в будущем сольются. На
данный же момент можно говорить о несомненной эффективности GPU для
решения задач, связанных с запуском АОМ.
В следующем разделе мы переходим к описанию разработанного нами
подхода к запуску агентных моделей на суперкомпьютерах.
22
3.Адаптация агент-ориентированных моделей для суперкомпьютера: наш

подход
В марте 2011 г. на суперкомпьютере «Ломоносов» (рис. 5) была запущена
модель, имитирующая развитие социально-экономической системы России на
протяжении последующих 50 лет. Эта АОМ основана на взаимодействии 100
млн агентов, условно представляющих социально-экономическую среду России.
Поведение каждого агента задано набором алгоритмов, которые описывают его
действия и взаимодействие с другими агентами в реальном мире.
Рис. 5.Суперкомпьютер «Ломоносов»
В проекте участвовали пять человек: два специалиста ЦЭМИ РАН

(В.Л.Макаров, А.Р. Бахтизин) и три сотрудника МГУ (В.А. Васенин, В.А.
Роганов, И.А. Трифонов). Данные для моделирования были предоставлены
Федеральной службой государственной статистики и Российским мониторингом
экономического положения и здоровья населения. Модель для обычного
компьютера была построена в 2009 г., а в 2011 г. она была конвертирована в
суперкомпьютерную версию. Ниже мы разберем основные этапы и методы
эффективного отображения счетного ядра мультиагентной системы на
архитектуру современного суперкомпьютера, наработанные нами в процессе
решения соответствующей задачи.
3.1.Проблема масштабирования
Важно понимать, что масштабированиепрограмм для суперкомпьютеров
является фундаментальной проблемой. Хотя обычная и суперкомпьютерная
программы реализуют один и тот же функционал, целевые функции их
разработки,как правило, разные.
При начальной разработке сложного прикладного программного
обеспечения в первую очередь стараются сократить издержки на
программирование, обучение персонала, повысить переносимость между
23
платформами и т.д., а оптимизацию откладывают на потом. И это вполне
разумно, так как на ранних стадиях приоритетом разработки является
исключительно функционал.
Однако когда разработанное программное обеспечение уже начало
внедряться, часто выясняется, что на больших реальных данных не хватает
производительности. А поскольку современные суперкомпьютеры— этововсе не
разогнанные в тысячи раз персональные компьютеры, для запуска на
суперкомпьютере программу приходится существенно видоизменять. Причем
эффективно сделать это без специальных знаний и навыков удается далеко не
всегда.
При грамотно проведенной работе значительное повышение
эффективности обычно достигается на трех уровнях:
1) распараллеливание счета;
2) специализация вычислительных библиотек по задачам;
3) низкоуровневая оптимизация.
3.2.Специализация и низкоуровневая оптимизация

Прежде чем всерьез говорить об использовании суперкомпьютеров,
программу следует максимально оптимизировать и адаптировать к целевой
аппаратной платформе. Если этого не сделать, параллельная версия будет лишь
хорошим тестом для суперкомпьютера, а сам счет будет весьма неэффективным.
Использовать суперкомпьютер без оптимизации и адаптации программы к
целевой аппаратной платформе — все равно что послать на боевое задание полк
новобранцев: их нужно сначала хорошо обучить выполнять их задачу
(специализация, оптимизация программного обеспечения), а также эффективно
владеть оружием (низкоуровневая оптимизация программного обеспечения), и
вот тогда это будет эффективное использование ресурсов.
В универсальных системах моделирования типа AnyLogic
предоставляемые процедуры универсальны. А универсальный код часто можно
прооптимизировать для конкретного семейства задач.
3.3.Выбор системы поддержки моделирования

Безусловно, АОМ можно программировать и без специальной среды, на
любом объектно-ориентированном языке.При этомосновным недостатком
существующих пакетов для создания АОМ, кроме RepastHPC, является
невозможность разработки проектов, выполняющихся на вычислительном
кластере (т.е. не предусмотрен механизм распараллеливания процесса
выполнения программного кода).
Однако более разумным подходом будет использование одной из хорошо
зарекомендовавших себя систем для AOM — по причине унифицированной
реализации типичных способов взаимодействия агентов.В целях экономии
места, здесь мы рассмотрим только систему ADEVS7.
7
http://www.ornl.gov/~1qn/adevs/
24
ADEVS представляет собой набор низкоуровневых библиотек для
дискретного моделирования, выполненных на языке C++. Из достоинств стоит
отметить:
 простоту реализации;
 высокую производительность моделей;
 поддержку основных численных методов при построении моделей;
 встроенное распараллеливание симуляции при помощи OpenMP;
 возможность применения стандартных средств распараллеливания;
 достаточно быстрое развитие библиотек в текущий момент;
 кроссплатформенность;
 низкоуровневость (текущий функционал не накладывает никаких
ограничений на модель);
 независимость скомпилированного кода от нестандартных библиотек;
 открытый исходный код.
Однако существенными недостатками этого продукта являются полное

отсутствие средств презентации и достаточно сложная по сравнению, например,
с AnyLogic разработка моделей. Поэтому этот продукт не может использоваться
для построения моделей на уровне заказчика, однако представляет собой
эффективную платформу для реализации параллельных симуляторов.
Основными элементами программы с использованием библиотеки ADEVS
при построении АОМ обычно являются:
 симуляторadevs::Simulator< X >;
 примитив агентовadevs::Atomic<X>;
 модель (контейнер агентов) adevs::Digraph<VALUE, PORT>.
При этом агент представляет собой следующий класс (листинг 9).

…
template<class X> class Atomic: public Devs<X>
public:
virtual void delta_int() = 0;
virtual void delta_ext(double e, const Bag<X>&xb) = 0;
virtual void delta_conf(const Bag<X>&xb) = 0;
virtual void output_func(Bag<X>&yb) = 0;
virtual double ta() = 0;
virtual void gc_output(Bag<X>& g) = 0;
…
Листинг9.Пример представления агента в ADEVS
Соответствующие виртуальные функции определяют необходимые для

симуляции параметры (листинг10).
voiddelta_int() —реакция агента на микроправило;
voiddelta_ext(…) —микрореакция агента на макроправило;
25
voiddelta_conf() —макрореакция агента на макроправило;
doubleta() —время следующего события для агента;
voidgc_output(…) —данные для процедуры сборки мусора.
Листинг10.Виртуальные функции, определяющие параметры агентов
Предоставляемые системой ADEVSразработчику сущности перечислены

ниже (листинг11).
adevs::AbstractSimulator< X >
adevs::Atomic< X >
adevs::Bag< T >
adevs::Bag< T >::iterator
adevs::CellEvent< X >
adevs::CellSpace< X >
adevs::corrected_euler< X >
adevs::crand
adevs::DESS< X >
adevs::Devs< X >
adevs::Digraph< VALUE, PORT >
adevs::Event< X >
adevs::event_locator< X >
adevs::EventListener< X >
adevs::exception
adevs::Hybrid< X >
adevs::InterPoly
adevs::linear_event_locator< X >
adevs::LpGraph
adevs::MessageManager< X >
adevs::ModelWrapper<ExternalType, InternalType>
adevs::mtrand
adevs::Network< X >
adevs::NullMessageManager< X >
adevs::ode_solver< X >
adevs::ode_system< X >
adevs::ParSimulator< X >
adevs::PortValue< VALUE, PORT >
adevs::random_seq
adevs::rv
adevs::Set< T >
adevs::SimpleDigraph< VALUE >
adevs::Simulator< X >
Листинг11.Сущности ADEVS, позволяющие моделировать агенты
В силу перечисленных выше достоинств системы

ADEVSсуперкомпьютерную версию описываемой ниже программы было
решено реализовывать именно на ее базе.В рамках данной работы были
разработаны MPI-версия симулятора ADEVS, а также система визуализации
26
процесса счета на базе библиотеки Qt —кросс-платформенного инструментария
разработки ПОна языке программирования C++.
Далее мы переходим к краткому описанию разработанной модели и
процедуры ее последующего запуска на суперкомпьютере.
3.4.Исходная агент-ориентированная модель

Первый этап разработки описываемой ниже АОМ заключался в
построении инструмента, эффективно решающего задачу исследования на
обычных компьютерах, а также в настройке параметров модели. После ее
успешной апробации с небольшим числом агентов (около 20 тыс.— такова
численность агентов, над которой способен производить вычисления с
удовлетворительной скоростью персональный компьютер с хорошей
производительностью, учитывая сложность агентов) было решено
конвертировать модель для суперкомпьютера — в этом состоял второй этап
разработки. На первом этапе был использован пакет AnyLogic, технические
возможности которого позволили достаточно быстро отладить модель и
настроить ее параметры. Таким образом, модель для обычного компьютера была
построена в 2009г., а в 2011 г. она была конвертирована в суперкомпьютерную
версию.
Рис. 6. Рабочее окно АОМ

На рис. 6 изображено рабочее окно разработанной АОМ (точки — агенты).
В процессе работы системы можно получать оперативную информацию о
социально-экономическом положении всех регионов России, в том числе с
использованием картографической информации, меняющейся в режиме
реального времени в зависимости от значений эндогенных параметров.
27
Спецификация агентов модели осуществлялась с учетом следующих
основных параметров (рис. 7):
o возраст;
o продолжительность жизни;
o специализация родителей;
o место работы;
o регион проживания;
o доход и др.
Рис. 7. Спецификация агентов с помощью диаграммы состояний
Спецификация регионов осуществлялась с учетом следующих параметров:

 географические границы;
 количество жителей;
 количество работников (по типам);
 ВРП;
 ВРП на душу населения;
 объем инвестиций;
 объем инвестиций на душу населения;
 средняя заработная плата;
 средняя продолжительность жизни;
 показатель прироста населения и др.
28
Для наполнения модели данными использовались статистические

сборники Росстата, а также социологические базы данных RLMS.
3.5.Конвертация модели в суперкомпьютерную программу

Выше мы уже обсуждали проблемы, связанные с использованием средств
разработки АОМ для реализации проектов, выполняющихся на вычислительных
кластерах суперкомпьютера. УAnyLogicввидутрудноотделимостисчетной части
от презентативнойи из-зареализации кода на языке высокого уровня Java
производительность выполнения кода существенно ниже, чем у ADEVS, и,
кроме того, очень сложно(либо очень трудоемко) переработать генерируемый
код в параллельно выполняемую программу.
Ниже приведен алгоритм конвертации модели AnyLogic в
суперкомпьютерную программу.
3.6.Трансляция модели
Модели в проекте AnyLogic хранятся в виде XML-файла, содержащего
дерево необходимых для генерации кода параметров, как то: классы агентов,
параметры, элементы презентации, описания UML-диаграмм поведения агентов.
В листинге12 приведен фрагмент XML-кода (дерева, отображающего
структуру модели), сгенерированного программой AnyLogic.
…
<?xmlversion="1.0"encoding="UTF-8"?>

<AnyLogicWorkspaceWorkspaceVersion="1.9"AnyLogicVersion="6.5.0.201004141159"AlpVersio
n="6.5.0">
<Model>
<Id>1245270665890</Id>
<Name><![CDATA[Society]]></Name>
<ExcludeFromBuild>false</ExcludeFromBuild>
<EngineVersion>6</EngineVersion>
<JavaPackageName><![CDATA[society]]></JavaPackageName>
<ActiveObjectClasses>

<ActiveObjectClass>
<Id>1245270665891</Id>
<Name><![CDATA[Main]]></Name>
<ExcludeFromBuild>false</ExcludeFromBuild>
<ClientAreaTopLeft><X>0</X><Y>0</Y></ClientAreaTopLeft>
<PresentationTopGroupPersistent>true</PresentationTopGroupPersistent>
29
<IconTopGroupPersistent>true</IconTopGroupPersistent>
<Import><![CDATA[import java.awt.Rectangle;]]></Import>
<StartupCode><![CDATA
// присваиваниерегионамграниц
regions.get(0).set_border(Belgorodskaya_1);
regions.get(1).set_border(Bryanskaya_1);
regions.get(2).set_border(Vladimirskaya_1);
…
Листинг12.Фрагмент сгенерированного пакетом AnyLogicXML-кода
А на рис.8 показана презентация файларассматриваемой модели в окне

транслятора (.alp — формат AnyLogic).
Рис.8.Представление .alp-файла в трансляторе
В процессе работы конвертера это дерево транслируется в код С++

программы, вычисляющей эту модель. Проход дерева совершается «в глубину»,
при этом выделяются следующие ключевые стадиии происходит их
совмещениес выполнением задачи трансляции.
1. Генерация основных параметров

30
Поиск корня дерева и считывание параметров дочерних вершин, таких как
имя модели,адрес сборки, тип модели, тип презентации.
2. Генерация классов
Генерация классов (более подробно):
1) построение списка классов;
2) считывание основных параметров класса;
3) считывание переменных;
4) считывание параметров;
5) считывание функций;
6) генерация списка функций;
7) считывание кода функций;
8) преобразование кода функций Java -> C++;
9) считывание используемых фигур и элементов управления;
10) генерация кода инициализации фигур и элементов управления;
11) генерация кода конструктора, деструктора, визуализатора;
12) генерация структуры класса;
13) генерация кода заголовочного и source-файлов.
3. Генерация симулятора
Поиск вершины, хранящей информацию о процессе симуляции
(управляющие элементы, значения важных констант, элементы презентации и
т.д.).
4. Генерация общих файлов проекта (main.cpp,mainwindow.h,

mainwindow.cpp и т.д.)
3.7.Импортирование входных данных

В качестве выходных данных в модель загружаются данные из
геоинформационной составляющей исходной модели (карты России),
содержащей всю необходимую информацию.
3.8.Генерация классов ипреобразование кода функций

При генерации функций из дерева считываются:имя функции,
возвращаемый тип, параметры и ее тело (рис. 9).
31
Рис. 9.Представление функции в .alp-файле
На основании построенного ранее списка классов в аргументах функций

производится замена «тяжеловесных классов», т. е. всех сгенерированных
классов, классов фигур и прочих классов, не входящих в стандартное множество,
на соответствующие указатели с целью экономии памяти и во избежание ошибок
при работе с нею. Далее генерируются заголовки функций, которые
впоследствии вставляются в заголовочные и source-файлы. При таком
считывании тело функции посредством соответствующейфункции(листинг 13)
преобразуется из Java-кода в аналогичный ей C++ код (это возможно ввиду
достаточно узкого класса используемых функций, ав случае более сложных
функций требуется ручная доработка странслированного кода), после чего она
добавляется в список тел для данного класса.
void Translate(QString *code, QVector<QString>* libs);
Листинг13.Пример считывающей функции
В ходе трансляции неоднократно возникает задача преобразования

исходного кода функций из языка Java в язык C++. Его можно представить в
виде последовательных замен конструкций, например таких.
 Преобразованиециклов:
Java-формат (листинг 14)
32
for (Class element : containers)
{
body
}
Листинг 14.Цикл в Java-формате
Формат C++ (листинг 15)
for (int kind=0;kind<container.size();kind++)

{
Class *element = container.at(kind);
Body
}
Листинг 15.Цикл в формате C++
 Преобразование стандартных операций работы с контейнерами:

Java-формат (листинг 16)
container.add(element)
container.get(element)
Листинг 16.Операция с контейнерами в Java-формате
Формат C++ (листинг 17)
container.append(&element)
container.at(index)
Листинг 17.Операция с контейнерами в формате C++
 Преобразование указателей
В Java нет столь явного, как в С++, различия между объектом и указателем
на объект, поэтому структуры работы с ними не отличаются. Поэтому вводится
список классов, в которых важно использовать операции с указателем на объект,
а не с самим объектом, и отслеживаются все переменные этих классов с
последующей заменой в пределах данной функции при обращении к ним на
соответствующие обращения к указателям.
 Раскрытие «черных ящиков»

В Java, и конкретно в библиотеке AnyLogic, есть некоторое количество
функций и классов, аналогов которым нет ни в самом C++, ни в библиотеке
ADEVS. В связи с этим были созданы дополнительные библиотеки shapes.h,
mdb-work.h, в которых и реализованы недостающие функции.
33
 На этапе генерации основных параметров списка классов получаются

название основного класса и названия моделируемых классов-агентов. В код
основного класса добавляется процедура добавления агента в зону видимости
симулятора.
С учетом вышесказанного приведем пример кода, описывающего

генерацию классов (листинг 18).
…
intTranslateWindow::TClassGenerate(DomItem *item,QDomElement *cur,int flag)
{
QDomElement Name=cTree.createElement("Name");
QDomElement Include=cTree.createElement("Include");
QDomElementStartUp=cTree.createElement("StartupCode");
QDomElementAgentProperties=cTree.createElement("SimulationProperties");
QDomElement DataCreationProperties=cTree.createElement("DatasetsCreationProperties");
QDomElement Variables=cTree.createElement("Variables");
QDomElement Events=cTree.createElement("Events");
QDomElement Functions=cTree.createElement("Functions");
QDomElementTableFunctions=cTree.createElement("TableFunctions");
QDomElement Connectivity=cTree.createElement("Connectivity");
QDomElementEmbeddedObjects=cTree.createElement("EmbeddedObjects");
QDomElement Shapes=cTree.createElement("Shapes");
QDomElement Controls=cTree.createElement("Controls");
QDomElement Charts=cTree.createElement("Charts");
QDomElement Agent=cTree.createElement("Agent");
int agent=0;
int j=nextChildByName(item,"Agent",-1);
if (j>-2)
{
Agent.setNodeValue(item->child(j)->child(0)->
node().nodeValue().split("\n").join(" "));
cur->appendChild(Agent);
if (Agent.nodeValue().split("\n").join(" ")=="true")
{
agent=1;
}
}
j=nextChildByName(item,"Name",-1);
if (j>-2)
{
Name.setNodeValue(item->child(j)->child(0)->
cur->appendChild(Name);
}
else
{
status->append("No Class Name, stopping...");
return -1;
34
}
QString *filename = new QString(Name.nodeValue().split("\n").join(" ").toUtf8());
DocRedactorClass(filename,agent,packagename);
status->append(QString("Init Class ...").append(*filename));
status->append(" ");
j=nextChildByName(item,"Import",-1);
if (j>-2)
{
Include.setNodeValue(item->child(j)->child(0)->
cur->appendChild(Include);
}
j=nextChildByName(item,"StartupCode",-1);
QStringvv="";
if (j>-2)
{
StartUp.setNodeValue(item->child(j)->
child(0)->node().nodeValue().split("\n").join(" "));
// QStringaa=item->child(j)->child(0)->node().nodeValue().toAscii();
cur->appendChild(StartUp);
vv=item->child(j)->child(0)->node().nodeValue(); //.toUtf8();
}
if (flag)
{
Class.AddConstructor(&vv);
status->append("Translate Constructor ... \n");
}
j=nextChildByName(item,"AgentProperties",-1);
if (j>-2)
{
DomItem *item2=item->child(j);
QDomElementSpType=cTree.createElement("SpaceType");
QDomElementEnvDefLoc=cTree.createElement("DefineLocationfromEnv");
j=nextChildByName(item2,"SpaceType",-1);
if (j>-2)
{
SpType.setNodeValue(item2->child(j)->
AgentProperties.appendChild(SpType);
}
j=nextChildByName(item2,"EnvironmentDefinesInitialLocation",-1);
if (j>-2)
{
EnvDefLoc.setNodeValue(item2->child(j)->
AgentProperties.appendChild(EnvDefLoc);
}
cur->appendChild(AgentProperties);
}
j=nextChildByName(item,"DatasetsCreationProperties",-1);
if (j>-2)
35
{
DomItem *item2=item->child(j);
QDomElement AC=cTree.createElement("AutoCreate");
QDomElement RC=cTree.createElement("Recurrence");
j=nextChildByName(item2,"AutoCreate",-1);
if (j>-2)
{
AC.setNodeValue(item2->child(j)->
DataCreationProperties.appendChild(AC);
}
j=nextChildByName(item2,"RecurrenceCode",-1);
if (j>-2)
{
RC.setNodeValue(item2->child(j)->
DataCreationProperties.appendChild(RC);
}
cur->appendChild(DataCreationProperties);
}
j=nextChildByName(item,"Variables",-1);
if (j>-2)
{
TVariablesGenerate(item->child(j),&Variables,flag,&Class);
cur->appendChild(Variables);
}
j=nextChildByName(item,"Functions",-1);
if (j>-2)
{
TFunctionsGenerate(item->child(j),&Functions,flag,&Class);
cur->appendChild(Functions);
}
j=nextChildByName(item,"EmbeddedObjects",-1);
if (j>-2)
{
TContainersGenerate(item->child(j),&EmbeddedObjects,flag,&Class);
cur->appendChild(EmbeddedObjects);
}
j=nextChildByName(item,"Shapes",-1);
if (j>-2)
{
TShapesGenerate(item->child(j),&Shapes,flag,&Class,"");
cur->appendChild(Shapes);
}
return 0;
}
…
Листинг 18.Фрагмент кода, реализующего генерацию классов
36
3.9.Генерация внешних объектов
В процессе генерации внешних объектов создается отдельная функция
Main::initShapes(), в которой содержится вся «графическая информация», т. е.в
рамках функции происходит инициализация всех фигур, классы которых
реализованы также в shapes.h.Соответствующий пример приведен в следующем
отрывке кода (листинг 19).
…
points[125]=0;
points[126]=0;
points[127]=0;
Krasnodarsky_3.setPoints(64,points);
Krasnodarsky_3.setXX(65);
Krasnodarsky_3.setYY(549);
}
//Krasnodar
{
Krasnodar.setXX(51);
Krasnodar.setYY(565);
Krasnodar.rx=2;
Krasnodar.ry=2;
Krasnodar.center.setX(0);
Krasnodar.center.setY(0);
}
//Adygeya_3
{
int* points=new int[46];
points[0]=0;
points[1]=0;
points[2]=2;
points[3]=-3;
…
Листинг19. Пример инициализации графической информации
3.10.Генерация классов, генерация кода заголовочного и source-файлов

На основе всех считанных и сгенерированных данных создаются
заголовочный и source-файл соответствующего класса (листинг 20).
…
#ifndef PERSON_H
#define PERSON_H
#include "Main1.h"
#include "Region.h"
typedefenum {InitialState,Normal} Branch;
classTRegion;
class Person : public MovingAgent
37
{
public:
Person(adevs::Simulator<IType> *sim);
~Person();
//Events
voidYearFire();
voidBabyBornFire();
int year;
intbabyborn;
//Table Functions
double radius(double T);
voidset_LifeLength(double T);
voidset_Age(double T);
voidset_Region(TRegion *T);
voidset_baby(double T);
voidfindLocation();
voidfindBabyLocation(TRegion *r);
voidInitShapes();
voidvisualise(QPainter *image );
/// Internal transition function.
voiddelta_int();
/// External transition function.
voiddelta_ext(double e, constadevs::Bag<IType>&xb);
/// Confluent transition function.
voiddelta_conf(constadevs::Bag<IType>&xb);
/// Output function.
voidoutput_func(adevs::Bag<IType>&yb);
/// Time advance function.
double ta();
/// Output value garbage collection.
voidgc_output(adevs::Bag<IType>& g);
//Status
typedefenum {NRed,NBlue,NGreen} State;
typedefenum {unborn,startPoint,endPoint,normal,asc,sc,transition1,transition2,transition3,
transition4,transition5,transition6,transition7,transition8,transition9,transition10,
transition11,transition12,transition13,transition14,transition15,transition16,
transition17,transition18,transition19,transition20}
Transition;
State Status;
Transition Current;
Branch Prof;
voidtest_Stat();
doubletest_Trans();
doubletest_Prof();
//Parameters and Variables

intperehod;
38
doubleLifeLength;
double Age;
TRegion *Region;
double baby;
intchilds;
Oval person;
double t;
doubleyeareventtime;
doublebabyeventtime;
};
#endif
…
Листинг 20.Исходный код сгенерированного заголовочного файла Person.h
3.11.Генерация симуляции
Для генерации симуляции оказалось достаточно заранее написанных
файлов main.cpp, mainwindow.cpp, mainwindow.h, в которых шаблоны задают тип
основного класса и подключаемые заголовочные файлы. При компоновке
исходного кода шаблоны заменяются на полученные ранее (на стадии
генерации) названия классов.Этого достаточно для двухпоточной симуляции,
которую позднее можнозаменить на соответствующий модуль для
многопроцессорной симуляции.В листинге21 приведен участок кода,
отвечающий за запуск симулятора.
…
void MainWindow::init()
{
srand(time(NULL));
store=new adevs::Digraph<Man*>();
int i;
model=new #CONTAINERCLASSNAME(store);
tim=0;
inited=1;
sim= new adevs::Simulator<IType>(store);
}
void MainWindow::deinit()
{
inited=0;
delete store;
delete #CONTAINERCLASSNAME;
}
void Proceed(adevs::Simulator<IType> *sim, MainWindow *a)
{
while (inited)
{
while (sim->nextEventTime()<tim) sim->execNextEvent();
tim+=temp;
39
symb=1;
while ((symb) && (inited)) {}
}
}
void MainWindow::startButtonClicked()
{
if (!startButtonClick)
{
startButtonClick=1-startButtonClick;
startButton->setText("Stop");
init();
repaint();
f1= QtConcurrent::run(Proceed,sim,this);
}
else
{
startButtonClick=1-startButtonClick;
startButton->setText("Start");
inited=0;
f1.waitForFinished();
deinit();
}
}
…
Листинг 21.Пример кода, осуществляющего генерацию симулятора
3.12.Дополнительные параметры
На этапе разбора дерева (п. 3.6) параллельно формируется сходное по
строению дерево для генерации C++ кода (рис. 10), с помощью которого на этапе
подготовки к трансляции можно задать необходимые параметры компиляции
(визуализацию тех или иных частей, визуальнуювалидацию распознавания кода,
дополнительные флаги сборки и т.д.).
После этого при команде трансформации с учетом данных параметров и
происходит окончательная компиляция.
40
Рис. 10.Преобразования дерева при трансляции
3.13.Сборка готового проекта

Для сборки странслированного проекта применяется QtCreator—
кроссплатформенная свободно распространяемаяинтегрированная среда
разработки для работы с фреймворкомQt.
3.14.Код агента
При помощи описанного выше транслятора из данных файлов проекта
AnyLogic (model.alp и др.) был сгенерирован исходный код (за исключением
характера поведения агента).
Характер поведения агента должен быть сгенерирован из диаграммы
состояний (см. рис.7), однако на данный момент автоматизация этого процесса
еще не реализована. Таким образом, к сгенерированному коду необходимо было
добавить еще некоторый объем кода (листинг 22).
…
/// Обработкасобытий
void Person::delta_int()
{
if ((t>babyeventtime) && (babyeventtime>0))
{
// Обработка внутреннего события «Рождение ребенка»
BabyBornFire();
}
if (t>yeareventtime)
{
41
// Обработка внутреннего события «Прошел год»
YearFire();
yeareventtime++;
}
test_Stat();//Вычисление состояния агента
t=t+ta();//Получение текущего времени агента
if (LifeLength<0)
{
Current=endPoint;
return;
}
}
///Функция подсчета времени
doublePerson::ta()
{
// test_Trans() — функция, реализующая поведение, соразмерно диаграмме характера
returntest_Trans()+test_Prof();
}
double Person::test_Trans()
{
switch (Current) // Current — текущеесостояниеагента
{
caseunborn:
{
return 0;
}
caseendPoint:
{
if (Region != 0)
{
Region->person = Region->person - 1;
}
get_Main()->remove_people(this);
return MAX;
}
casestartPoint:
{
Current=normal;
return YEAR;
}
}
}
…
Листинг 22.Фрагмент кода, описывающий действия агентов
После внесения необходимых изменений в результате компиляции

получилось кроссплатформенное приложение, повторяющее основную
функциональность данной модели.
42
3.15.Статистика и визуализация временных срезов
Ввиду неинтерактивностизапуска программы на больших
суперкомпьютерах сбор выходных данных и визуализация были разделены (это
связано с неравномерностью нагрузки на кластеры в разное время суток, а
монопольный доступ попросту невозможен).После пересчета модели
получившаяся на выходе информация может быть сновавизуализирована, к
примеру, следующим образом (рис. 11).
Рис.11.Результат работы суперкомпьютерной программы в графическом виде
3.16.Доступные для расчетов суперкомпьютеры

На момент проведения расчетов для нас были доступны три
суперкомпьютера (табл. 1), входящие в первую пятерку суперкомпьютерного
рейтинга Топ-50 в странах СНГ (в редакции от 29.03.2011 г.).
Таблица 1
Доступные для исследовательской группы суперкомпьютеры
Позиция
Суперкомпьютеры Узлы CPU Ядра RAM/узел TFlops
в Топ-50
1 «Ломоносов» (МГУ) 5 130 10 260 44 000 12GB 414
43
4 МВС-100K (МСЦ РАН) 1 256 2 332 10 344 8GB 123
5 «Чебышев» (МГУ) 633 1 250 5 000 8GB 60
Мы использовали для расчетов два суперкомпьютера — «Ломоносов» и

МВС-100K.
3.17.Результаты
За счет применения суперкомпьютерных технологий и оптимизации
программного кода удалось достичь очень высокой производительности.
Сама по себе оптимизация кода и использование C++ вместо
Javaпозволили увеличить скорость выполнения программы. Так, модель
тестировалась при следующих начальных условиях:1) количество агентов — 20
тыс.; 2) прогнозируемый период — 50 лет. По итогам расчетов оказалось, что
время счета модели с использованием ADEVS составило 48 секунд на одном
процессоре, а время счета модели также на одном процессоре с использованием
AnyLogic составило 2 минуты 32 секунды, — а это значит, что среда разработки
была выбрана удачно.
Как уже говорилось выше (п. 3.4), обычный персональный компьютер с
хорошей производительностью способен осуществлять вычисления с
удовлетворительной скоростью над совокупностью агентов числом около 20
тыс. (поведение каждого из них задается приблизительно 20 функциями), и при
этом среднее время пересчета одной единицы модельного времени (один год)
составляет около минуты. При большем числе агентов, к примеру 100 тыс.,
компьютер попросту «зависает».
Задействование 1000 процессоров суперкомпьютера и выполнение
оптимизированного кода позволило увеличить число агентов до 100 млн, а число
модельных лет — до 50. При этом такой гигантский массив вычислений был
выполнен за период времени, приблизительно равный 1 минуте 30 секундам
(этот показатель может несколько меняться в зависимости от типа используемых
процессоров).
Результаты моделирования показали, что при сохранении текущих
тенденций население Сибирского и Дальневосточного федеральных округов
значительно сократится, в то время как в регионах Южного федерального
округа, наоборот, произойдет существенный прирост.Кроме того, проведенное
моделирование дает основания прогнозировать постепенное снижение ВВП, а
также ряда других макроэкономических показателей.
По результатам экспериментов с разработанной АОМ выяснилось, что
масштабирование модели само по себе имеет определенное значение. Так, при
запуске одной и той же версии модели на 50 модельных лет с одинаковыми
параметрами (за исключением числа агентов: в первом случае было 100 млн
агентов, а во втором — 100 тыс. агентов) были получены результаты, а именно
масштабированное число агентов, отличающиеся приблизительно на 4,5%.
44
Можно предположить, чтов сложных динамических системах одни и те же
параметры (рождаемость, продолжительность жизни и т. д.) могут приводить к
разным результатам в зависимости от размера социума.
3.18. Заключение
Хотя подобная работа может быть проделана практически для любой
начальной реализации, в идеале нужны системы, которые ликвидировали бы
этот непростой этап,который сегодня затрудняет широкое внедрение
суперкомпьютерного моделирования.
Тот факт, что в исходном представлении модели значительную роль играет
код на языке программирования, отражает фундаментальное свойство агент-
ориентированного подхода: модель — это программа.
Декларативный подход (набор правил вместо обычной программы) может
сильно упростить задачу определения поведения системы.
Проиллюстрируем вышесказанное (рис.12). При возникновении новой
задачи мы получаем для нее некоторые исходные данные, а аналитики
определяют, к какому классу задач она относится, с целью подбора
соответствующей спецификации для построения соответствующей модели. Для
этого используется наиболее адекватный DSL (DomainSpecificLanguage),
который позволяет описывать модели (в качестве IDE, к примеру, может быть
применен Eclipse). Для этого языка, как правило,уже имеется ряд наработок на
прошлых задачах этого класса, которые содержат ужеадаптированные
специфические библиотеки. В совокупности все это образуетметаязык, который
затем реализуется в некоторой среде разработки, и именно в ней, с точки зрения
прикладников, в итоге и решается задача. После тестовых прогонов готовой
программы на локальной машине следует финальная стадия — запуск на
суперкомпьютере[Макаров, Бахтизин, Васенин, Роганов, Трифонов, 2011].
45
Рис.12.Процесс разработки агентной модели для суперкомпьютера
При этом общая последовательность действий разработки будет

следующая (рис.13).
1. Выбор языка описания модели (т.е. метамодели и языкаописания
моделей). Первый шаг контролируется специалистами формализации моделей и
собственно программистами, которые выбирают язык, наиболее подходящий для
описания данной задачи.
2. Описание модели на выбранном языке (этот шаг контролируется
заказчиком).
3. Поиск и выбор необходимых шаблонов программирования, т.е., по сути,
выбор удобной среды разработки с наиболее подходящим инструментарием.
4. Подготовка алгоритмов распараллеливания и выбор аппаратной части.
5. Выбор библиотек, прочей программной части и непосредственно
программирование.
На четвертом и пятом шагах происходит перевод модели в
низкоуровневые языки, подходящие для распараллеливания, и осуществляется
собственно запуск программы, настройка средств отображения результатов и
представление их заказчику (после чего возможны дополнительные итерации).
46
Рис.13.Структура хранилища, роли и доступ к общему репозиторию
47
4. Выводы
Итак, в работе мы рассмотрели наиболее известный и успешный опыт
зарубежных ученых и практиков по запуску АОМ на суперкомпьютерах, а также
описали этапы и методы эффективного отображения счетного ядра
мультиагентной системы на архитектуру современного суперкомпьютера на
примере агентной модели, разработанной в ЦЭМИ РАН.
Как было показано, суперкомпьютеры позволяют на несколько порядков
увеличить число агентов и других количественных характеристик (количество
узлов сети, размер территории) в моделях, первоначально разработанных для
использования наобычных настольных компьютерах.
Можно сделать однозначный вывод о том, что суперкомпьютерное
моделирование является логичным и крайне желательным шагом для тех
упрощенных моделей, которые уже прошли успешную практическую апробацию
на обычных компьютерах.
Вместе с тем прямое перенесение компьютерной модели на
суперкомпьютер практически невозможно, так как значительное повышение
эффективности обычно достигается на трех уровнях:
1) распараллеливание счета;
2) специализация вычислительных библиотек по задаче;
3) низкоуровневая оптимизация.
При этом возникает принципиальная проблема, связанная с интенсивным
межагентным взаимодействием и заключающаяся в эффективном
распараллеливании программного кода между процессорами.
Опыт зарубежных исследователей, равно как и наш, показывает, что
существуют два способа ее решения.
Способ 1
При распараллеливании кодаагенты модели равномерно распределяются
на группы, количество которых соответствует числу процессоров. Минус такого
подхода заключается в сложности отслеживания статуса отдельного человека, т.
е. еслиi-й индивидуум, к примеру, инфицирован (в случае агентной модели
распространения эпидемий), то информация об этом должна быть
синхронизирована во всех группах, так как мы не знаем, в каких из них
содержатся связи данного человека. Необходимость синхронизировать
информацию влечет за собой большую вычислительную нагрузку.
Способ 2
Основан на разделении людей — агентов модели — в соответствии с их
географическим местоположением (исходя из первоначального предположения о
том, что в основном общение между агентами происходит в рамках небольшой
социальной группы, проживающей приблизительно в одной местности). В этом
случае географическое пространство делится на равные части, количество
которых соответствует числу узлов.
Если первый способ влечет за собой увеличение вычислительной нагрузки
за счет ресурсоемких контактов, то второй чреват опасностью значительного
дисбаланса между аппаратными ресурсами. К примеру, вспышка какого-либо
48
заболевания в одном из регионов загрузит один из вычислительных узлов, в то
время как другие будут простаивать. Таким образом, конкретный способ
распараллеливания зависит от специфики решаемой задачи.
Помимо этого, был рассмотрен опыт реализации АОМ с использованием
графических процессоров, и уже сейчас можно говорить о несомненной
эффективности GPU для решения задач, связанных с запуском агентных
моделей.
49
Литература
1. Берилло А. NVIDIACUDA – неграфические вычисления на графических
процессорах // Информационный ресурс сети интернет IXBT.com, 23.09.2008 г. -
http://www.ixbt.com/video3/cuda-1.shtml.
2. Макаров В.Л., Бахтизин А.Р., Васенин В.А., Роганов В.А., Трифонов И.А.
Средства суперкомпьютерных систем для работы с агент-ориентированными
моделями / Программная инженерия, № 3, 2011.
3. Ambrosiano Nancy (2006): Avian flu modeled on supercomputer. Los Alamos
National Laboratory NewsLetter, Vol. 7, No. 8, 2006.
4. Collier Nick (2012): Repast HPC Manual, February 23, 2012
[http://repast.sourceforge.net].
5. Deissenberg Christophe, Sander van der Hoog, Herbert Dawid (2008): EURACE:
A Massively Parallel Agent-Based Model of the European Economy / Document de
Travail n°2008-39, 24 Juin 2008.
6. Douglas J. Roberts, Diglio A. Simoni, Stephen Eubank. A National Scale
Microsimulation of Disease Outbreaks. RTI International, Research Triangle Park,
NC; Virginia Bioinformatics Institute, Blacksburg, VA, 2007
7. Epstein J.M., Axtell R.L. (1996): Growing Artificial Societies: Social Science
from the Bottom Up Ch. V., MIT Press.
8. Epstein J.M. (2009): Modelling to contain pandemics / Nature 460, 687, 6 August
2009.
9. KalyanPerumalla and Brandon Aaby (2008): Data Parallel Execution Challenges
and Runtime Performance of Agent Simulations on GPUs. Proceedings of Spring
Computer Simulation Conference, Ottawa, Canada, April 2008.
10. Keith R. Bisset, Jiangzhuo Chen, XizhouFeng, V.S. Anil Kumar, Madhav V.
Marathe. EpiFast: A Fast Algorithm for Large Scale Realistic Epidemic Simulations
on Distributed Memory Systems ICS’09, June 8-12, 2009, Yorktown Heights, New
York, USA.
11. Parker Jon (2007): A Flexible, Large-Scale, Distributed Agent Based Epidemic
Model. Center on Social and Economic Dynamics, Working Paper No. 52.
12. Timothy M. Lynar, Ric D. Herbert and William J. Chivers. Implementing an
agent based auction model on a cluster of reused workstations. International Journal of
Computer Applications in Technology, Volume 34 Issue 4, 2009.
13. http://www.r-bloggers.com/cpu-and-gpu-trends-over-time/
14. http://techresearch.intel.com
15. http://repast.sourceforge.net/repast_hpc.html
16. http://www.nvidia.ru
50

В.Л. Макаров, А.Р. Бахтизин

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

В.Л. Макаров, А.Р. Бахтизин

Загружено:

Авторское право:

Доступные форматы

Российский экономический

университет имени Г.В. Плеханова Федеральное государственное

«Пространственные факторы экономики инноваций»

В.Л. Макаров, А.Р. Бахтизин

«Опыт применения суперкомпьютерных технологий

1.Опыт зарубежных ученых и практиков

1.2.Среда проектирования агент-ориентированных моделей для

Пример агентной модели в RepastHPC

Листинг1.Пример интерфейса класса «Агент»

В листинге2создается конструктор класса с единственной переменной

Листинг2.Конструктор класса, определяющего состояние агента

Далеесоздается структура, позволяющая скопировать агент от одного

Листинг3.Пример структуры, осуществляющей копирования агента между

Класс верхнего уровня Model нужен для начальной инициализации модели

Листинг4.Инициализация модели (пример класса Model)

В листинге 5 создается конструктор класса Model. Сначала определяется

Листинг5. Пример конструктора класса Model

В листинге6 приведен пример инициализации планировщика. Как видно,

Листинг6.Инициализация планировщика модели

И наконец, функция main обычно осуществляет инициализацию MPI в

Листинг7.Пример функции main

Более подробно сданным ПО можно познакомиться в руководстве

2. Использование графических процессоров для запуска агент-

2.1.Возможности графических процессоров

Рис. 1.Тактовая частота процессоров компании Intel (ось ординат имеет

Рис. 2.Ядра в CPU и GPU

Поддержка многопоточности у этих двух типов процессоров существенно

Рис. 3.Сравнительная производительность CPU и GPU в области вычислений

Справедливости ради надо сказать, что цифры на рис. 3 приведены для

2.2.Графические процессоры и агентные модели

Листинг 8.Фрагмент CUDA-кода игры «Жизнь»

Рис. 4.Игра «Жизнь» размерностью 1024×1024

3.Адаптация агент-ориентированных моделей для суперкомпьютера: наш

Рис. 5.Суперкомпьютер «Ломоносов»

В проекте участвовали пять человек: два специалиста ЦЭМИ РАН

3.2.Специализация и низкоуровневая оптимизация

3.3.Выбор системы поддержки моделирования

Однако существенными недостатками этого продукта являются полное

При этом агент представляет собой следующий класс (листинг 9).

Листинг9.Пример представления агента в ADEVS

Соответствующие виртуальные функции определяют необходимые для

Листинг10.Виртуальные функции, определяющие параметры агентов

Предоставляемые системой ADEVSразработчику сущности перечислены

Листинг11.Сущности ADEVS, позволяющие моделировать агенты

В силу перечисленных выше достоинств системы

3.4.Исходная агент-ориентированная модель

Рис. 6. Рабочее окно АОМ

Рис. 7. Спецификация агентов с помощью диаграммы состояний

Спецификация регионов осуществлялась с учетом следующих параметров:

Для наполнения модели данными использовались статистические

3.5.Конвертация модели в суперкомпьютерную программу

Листинг12.Фрагмент сгенерированного пакетом AnyLogicXML-кода

А на рис.8 показана презентация файларассматриваемой модели в окне

Рис.8.Представление .alp-файла в трансляторе

В процессе работы конвертера это дерево транслируется в код С++

1. Генерация основных параметров

4. Генерация общих файлов проекта (main.cpp,mainwindow.h,

3.7.Импортирование входных данных

3.8.Генерация классов ипреобразование кода функций

Рис. 9.Представление функции в .alp-файле

На основании построенного ранее списка классов в аргументах функций

void Translate(QString *code, QVector<QString>* libs);

Листинг13.Пример считывающей функции

В ходе трансляции неоднократно возникает задача преобразования

void Translate(QString code, QVector<QString> libs);