Модель системы онлайн-визуализации. Плакат для конференции ПАВТ-2023.

Модель системы онлайн-визуализации
П. А. Васёв
Институт математики и механики им. Н.Н. Красовского УрО
РАН
г. Екатеринбург, Россия
Область применения
Онлайн-визуализация
– методика визуализации,
обеспечивающая
наблюдение
и
контроль
за
выполняющейся
вычислительной
программой.
Наблюдение подразумевает визуальное представление
текущего состояния модельных сущностей и программы.
Контроль подразумевает возможность управления
вычислением – изменение переменных, влияние на
данные, а также подачу особых команд (например,
приостановку, создание контрольных точек, перезапуск с
определённого момента и так далее).
Insitu-визуализации
–
методика
визуализации,
подразумевающая выполнение элементов конвейера
визуализации на суперкомпьютере во время вычисления,
имеющая целью минимизацию операций вывода данных,
замену их на подготовку к визуализации.
Пример. Визуализация во
время вычисления; расчёты для
получения этого изображения
используют 256 тысяч ядер
(Bauer,2016)
A. C. Bauer, H. Abbasi, J. Ahrens, H. Childs, B. Geveci, S. Klasky, K. Moreland, P. O’Leary, V. Vishwanath, B. Whitlock, and E. W.
Bethel, “In Situ Methods, Infrastructures, and Applications on High Performance Computing Platforms”, in Computer Graphics
Forum, 2016, vol. 35, no. 3, pp. 577-597. doi: 10.1111/cgf.12930.
Решаемая проблема
●
●
●
Вычислительные программы стали настолько большими, что для их
визуализации требуется чтобы программа визуализации была сама
параллельной.
Возникает задача создания технологии параллельного программирования,
удобная для создания программ онлайн-визуализации.
Особенность – взаимодействие с существующими вычислительными
программами (получение данных от них).
Будем считать, что вычислительные программы работают
в итеративном режиме. На каждой итерации они порождают
набор сущностей.
Пример сущности: сетка с данными в ячейках.
Каждая такая сущность распределена в оперативной памяти
вычислительных процессов (см. рисунок).
Рисунок: Распределение
структурированных данных по
процессорным ядрам. Потехин,2022
Основная идея
●
●
●
Легко писать алгоритм преобразования сущности (рендеринг, фильтрацию, генерацию новых
сущностей), если есть доступ к элементам этой сущности.
Элементы сущности можно заменить на мета-информацию об этих элементах. Это позволит
генерировать управляющие команды сразу же, не дожидаясь фактического вычисления этих
элементов.
Алгоритм преобразования можно представить таким образом, чтобы его результат был также
мета-информацией. Это поволит получать результат “сразу же”, не дожидаясь фактического
завершения его вычисления.
Итог: параллельный алгоритм преобразования распределённых сущностей выражается в
форме последовательного алгоритма. Это удобно для мышления.
Используется подход “обещаний” (анг. promises). Обещание – объект мета-информации о данных,
которые будут вычислены в будущем. Обещание удобно тем, что его можно передавать на вход
алгоритмам, возвращать его и т.п – поскольку объем памяти для обещания мал и фиксирован.
Обещания можно совмещать с продолжениями (анг. continuations) – что делать, когда обещание
будет выполнено. Особенность заключается в том, что результат такого продолжения доступен сразу
же – в форме обещания.
Пример. Интерактивный параллельный рендеринг
данных на регулярной сетке 1000x1000x100
Постановка задачи: необходимо загрузить и интерактивно изображать данные в ячейках на регулярной сетке.
Подробнее: Потехин, А. Л., Об одном способе организации структур данных в системах научной визуализации // Вопросы
атомной науки и техники. Серия: Математическое моделирование физических процессов. – 2022. – № 4. – С. 64-71. – DOI:
10.53403/24140171_2022_4_64
Решение:
let filenames = [“1.dat”,”2.dat”,…,”50.dat”]
let blocks = filenames.map( load* )
reaction( "camera_position", pos => {
let images = render_cube( blocks, pos)
let merged = recursive_merge( images )
send( "final_image", merged )
})
func render_cube( parts, camera_position ) {
return
parts.map( render*(camera_position) )
}
func recursive_merge( row ) {
if (row.length == 1) return row[0]
let results = []
for (let i=0; i<row.length; i+=2) {
let img = merge*( row[i],row[i+1])
retults.push( img )
}
return recursive_merge( results )
}
Пояснение к решению.
Решение представлено
алгоритмом с реакцией на
изменение среды (параметр
camera_position).
Операции со звёздочкой* это постановка задачи на
параллельное исполнение.
Задача будет исполнена
системой, когда все её
операнды будут вычислены
фактически.
При этом результат от
постановки задачи доступен
сразу же, не дожидаясь её
фактического решения.
Визуализация работы алгоритма
Синие точки – задачи загрузки блоков.
Красные – задачи рендеринга блоков.
Белые – задачи слияние изображений.
Зеленые линии – ожидание назначения.
Линии между задачами – зависимости
по данным.
Нижний ряд – исполнители.
Исполнитель раскрашен цветом задачи.
Светлый – исполнитель простаивает.
Линии от исполнителей к задачам –
когда задача решена.
Анимация:
Реализация. 1 уровень
●
Сообщение – пара (атрибуты,нагрузка)
где атрибуты это набор пар (ключ,значение) а нагрузка это набор “тяжелых” данных.
Пример сообщения (нагрузка записана в атрибуте payload):
label: “cube_part”
part_size: [1000,1000,20] }
payload: [ Float32Array( voxel_positions ), Float32Array( voxel_values ) ]
●
Реакция – пара (критерий, действие)
где критерий это параметр функции проверки соответствия сообщения реакции, т.е. f:
( критерий, сообщение ) → bool
а действие это “обычный” алгоритм, который следует выполнить если критерий
“выполнился”.
Пример реакции (критерием выбрана метка label, действие описано на языке
javascript):
crit: ‘render_cube_part”
action: (msg) => rapi.exec( render_cube_part( {part: msg, camera_position} ) )
В системе нефиксированное число участников, которое может
менятся во времени.
●
●
Участники могут посылать сообщения в произвольные моменты
времени.
Участники могут размещать реакции в произвольные моменты
времени. Также можно отзывать реакции.
Система обеспечивает, что на любое посылаемое сообщение
выполняются действия всех реакций, соответствующих этому
сообщению и размещенные к настоящему моменту времени.
●
Текущая реализация такова, что все реакции выполняются на
участниках. То есть фактически сообщения никуда не посылаются, а
наоборот – рассылаются алгоритмы обработки.
●
●
●
●
Представленная модель позволяет реализовывать различные
способы взаимодействия. Например, на ней реализован “запрос”.
Запрос это набор (критерий, действие, callback). Запрос позволяет
получать сообщения в клиентском процессе. По сути это то же самое
что реакция, но результат обработки действием присылается в
процесс, разместивший запрос.
Пример:
query(“exec-request”,msg=>msg, msg => schedule_exec_request( msg ) )
Запросы позволяют “получать” сообщения, рассылаемые другими
участниками.
Реализация. 2 уровень.
●
●
●
●
●
●
Задача это набор (оператор, операнды,шаблон сообщения).
При постановке задачи она ставится в очередь и когда-нибудь будет исполнена на одном
из процессов-исполнителей.
Оператор определяет алгоритм, который следует вычислить.
Операнды определяют аргументы, которые будут поданы алгоритму на вход. Операнды это
выражения, включающие константы, спецпотребности, и вложенные выражения из exec.
Результат выполнения задачи посылается в форме сообщения по указанному в параметрах
задачи шаблону.
Операция постановки задачи возвращает обещание (promise), который можно использовать
в операндах других задач.
Пример: let part_coords = exec(
load_coords, file: “part10.xyz” )
let part_values = exec(
load_values, file: “part10.field.dat” )
let rend = exec( render_voxels, coords:part_coords, values: part_values )
●
Система решит сначала первые
две задачи, а затем их результаты подставит в аргументы третьей задаче.
Ставится 3 задачи. Причем последняя зависит по операндам от первых двух.
Взаимодействие с параллельными вычислительными
программами
●
На каждой итерации для каждой сущности счетная программа формирует
структуру данных, составленную из обещаний. Каждое обещание в такой структуре
соответствует некоторому блоку данных сущности в памяти параллельной
программы, который будет когда-нибудь вычислен.
●
Структуры предаются системе онлайн-визуализации в форме сообщений.
●
Визуализация программируется в форме реакций на подобные сообщения.
●
●
●
Алгоритму действия реакции доступны сущности, представленные в форме
структур из обещаний. С помощью таких структур “легко” программируется
преобразование сущностей, которое будет выполняться параллельно.
Результаты этих преобразований также являются структурами данных из
обещаний. Их можно использовать в других алгоритмах. И так далее.
Итоговый алгоритм – рендеринг. Он берет на вход набор структур из обещаний –
изображаемые блоки данных. На выходе выдает изображение, посылаемое
терминалу визуализации в форме сообщения. См. пример.
Виды операндов задач
●
Константы.
●
Обещания (promise).
●
●
Подзадачи (сoneed) – задачи, которые можно
выполнить на других узлах.
(аналог Джек Донгарра TTG: pull).
Потребности (need) — подзадачи,
которые следует выполнить на исполнителе
и держать в его памяти.
“Потребности” позволяют “кешировать”
подготовительные и общие операции,
и использовать их между задачами.
Например: загрузить данные в GPU,
загрузить в память библиотеку, и т.п.
Рисунок: выражение, описывающее задачу.
Обведененные узлы – операнды-“потребности”
При назначении задач выгодно учитывать потребности, уже развёрнутые на исполнителях.
Исполнители удаляют развертнутые потребности по мере достижения установленных лимитов.
Дополнительно при планировании требуется учитывать:
●
Затраты на передачу данных между узлами. Зачастую необходимо минимизировать количество таких передач.
●
Суммарный объём ресурсов, требуемый задаче и всем её потребностям – чтобы исполнитель мог обеспечить их наличие.