CC BY
23
С. В. Помелов, аспирант, Институт вычислительной математики и математической геофизики СО РАН, г. Новосибирск, s.v.pomelov@gmail.com
Параллельные вычисления: симуляция исполнения алгоритма на заданной архитектуре
В статье описываются две математические модели — вычислительного алгоритма и компьютерной архитектуры, и их практическое применение. Обе модели, несмотря на то что представляют принципиально различные объекты, описываются одинаковыми терминами, имеют одинаковые детализацию и структуру. Разработанные модели алгоритма и архитектуры, связанные общими элементами и концепциями, отличают эту работу от работ в этом же направлении — приближенной оценки характеристик вычислительного процесса с помощью абстрактных моделей. Это отличие позволяет разработать новый подход к сравнительному анализу масштабируемости алгоритма, а также его эффективности для заданной архитектуры. В статье после построения моделей и описания принципа симуляции вычислительного процесса с их использованием представлена возможность практического использования предлагаемого подхода.
Ключевые слова: симуляция вычислительного процесса, параллельные архитектуры, математическая модель вычислений, масштабирование приложений, оптимизация алгоритмов.
Введение
Важная составляющая современной науки — численные расчеты. Они требуют максимально полного использования вычислительной техники, зависящего от эффективной организации параллельных вычислений [1; 2].
Многие свойства архитектуры вычислительной системы, например время операций и передачи данных, формализуемы [3; 4]. Алгоритмы вычислений и способы их декомпозиции для параллельных вычислений формальны. Исходя из этого предлагается построение математической модели и реализующего ее программного комплекса, с помощью которого симулируется взаимодействие архитектуры с параллельным вычислительным алгоритмом. Посредством таких симуляций исполнения задачи делают сравнитель-
ный вывод о ее масштабируемости и свойствах различных разбиений исходных данных для параллельного исполнения на заданной архитектуре. В случае неудовлетворительных выводов о ресурсоемкости или масштабируемости, после анализа журнала симуляции вносят коррективы в алгоритм или выбирают более подходящую архитектуру. В результате получают оптимизацию ресурсов для параллельных вычислений.
Оценки масштабируемости и эффективные способы распараллеливания алгоритма будут получены до написания и тестирования ресурсоемкой программы. Такой подход позволит получить оценку эффективности для данной задачи и вычислительной системы только на основе информации о скоростях выполнения заложенных в алгоритм операций с данными и передачи данных между ее (машины) компонентами.
Преимущества и область применения подхода
Место, которое занимает подход симуляции исполнения алгоритма на архитектуре среди других подходов к повышению эффективности параллельных вычислений, необходимо очертить для понимания его сильных сторон, ограничений и надежности получаемых оценок. По критерию удаленности от аппаратного уровня построим иерархию уровней подходов к улучшению производительности параллельных вычислений.
1. Аппаратный уровень.
На данном уровне рассматриваются конвейеризация, исполнение нескольких операций за такт, поддержка аппаратных векторных инструкций, многопоточность, рост числа ядер, кластерные решения и прочие имеющие аппаратную поддержку параллельные возможности. Это база, дающая возможность параллельной обработки данных. По причине общеизвестности этих технологий мы лишь назовем их и место основы иерархии уровней подходов.
Отметим удаленность этого уровня от уровня приложений, описанного в пункте 3 раздела «Уровень приложений». Аппаратные возможности уже учитываются в информации о ресурсоемкости на данном устройстве различных операций, используемой для симуляции вычислительного процесса. К сожалению, такая информация, полученная из документации или в результате эксперимента, неточно и неполно отражает многообразие реального поведения устройств и скорость исполнения задач. Это принципиальная проблема используемого метода, над уменьшением ее влияния на достоверность результатов идет работа. Одно из направлений разработки для решения этой проблемы — встроенный инструмент, позволяющий провести профилирующий тест для замера средней скорости исполнения отдельных подзадач алгоритма и будущего вычислительного приложения с учетом нюансов целевой среды ис-
полнения, чтобы освободить от этого разработчика.
2. Уровень языков программирования.
Подходы этого уровня представляют собой возможности языков и сопутствующих им сред исполнения, они позволяют программисту упростить создание параллельно исполняемых алгоритмов. Уровень языков программирования — также и уровень поддержки существующих стандартов параллельного программирования, например стандартов реализации исполнения потоков. К реализациям подходов этого уровня относятся библиотеки (пример — Java Concurrency [5]) и реализации стандартов параллельного программирования для операционных систем (пример — POSIX-Threads [6]).
К этому или первому уровню в зависимости от аппаратной или программной части реализации относится модель памяти и ее детали, существенные для параллельного программирования. Пример — транзакционная память [7].
На этом уровне также рассматриваются примитивы параллельного программирования и их аппаратная поддержка. Достоинство и недостаток этого уровня — прямая технологическая цепочка, связывающая разработчика низкоуровневого кода с устройством и кодом, исполняемым на нем. В реальных системах цепочка содержит ряд неявных и необходимых изменений относительно «простой» трансляции кода программы в машинный код, зависящих от реализации языка, операционной системы и устройства. В качестве примера к этому абзацу можно привести работу «Multi-level parallelism for incompressible flow computations on GPU cluster» [8].
3. Уровень приложений.
К этому уровню относится описываемый в статье подход симуляции исполнения алгоритма на заданной архитектуре для последующей его оптимизации. Он оперирует более общим масштабом, чем находящиеся на этом же уровне подходы распределения вычислений внутри процессора или графи-
[ 71 ]
ческого ускорителя (OpenMP [9], CUDA [10], Threads [11]), выраженные в терминах встроенных возможностей устройства, переведенных в код языка и собранных во внешние библиотеки. И оперирует более общим масштабом, чем масштаб подходов инструментов, также основанных напрямую на аппаратных инструкциях класса устройств или устройств конкретных производителей, но предлагающих в дополнение свою модель параллельных вычислений для программиста (OpenHMPP [12], Intel TBB [13]). И наряду с этим место симуляционного подхода в нашей иерархии ниже, чем место инструментов, позволяющих распределять задачи между компьютерами в облаке или кластере и также входящих в уровень приложений.
В области параллельных вычислений на уровне приложений существует недостаток стандартов и инструментов распределения данных и вычислений на них между отдельными ядрами суперкомпьютера [1] и прочих вычислительных систем, не исключая мобильные и встраиваемые устройства. Этот недостаток является причиной отсутствия ряда важных инструментов, позволяющих полноценно учесть особенности архитектур, занимающих на момент написания статьи основные ниши на рынке вычислительных систем. Подавляющее большинство таких систем не только многоядерные, но и гетерогенные. Это обстоятельство послужило поводом для ряда работ [3; 14; 15], в том числе и для решения, состоящего из математических моделей, и их реализации в виде инструментальной программы, описанных в статье.
Симуляционный подход
В симуляционном подходе рассматриваются отдельные свойства устройств обработки и передачи данных в составе вычислительной машины и их взаимодействие с математическим представлением системы подзадач алгоритма, а не с его реализацией в коде
или в машинных командах. Преимущество такого подхода в следующем: есть возможность получить существенные выводы о поведении и быстродействии, абстрагируясь от конкретного устройства и множества факторов, затрудняющих его точное моделирование (например, необходимость для этого не менее мощной, чем моделируемая, системы). Другое преимущество — получение этих выводов до запуска ресурсоемких вычислительных приложений, всех потенциально успешных параллельных вариаций на предположительно подходящих системах. Во многих случаях это долго, дорого или невозможно. Еще одно достоинство — внесение изменений в модель как алгоритма, так и архитектуры происходит быстрее, чем эксперименты со сменой реальной архитектуры или даже с изменением кода вычислительного приложения.
Недостаток данного подхода — необходимость детальных и достоверных данных в части свойств архитектур, таких как скорость ее операций или пропускная способность памяти, а также устаревание этой информации.
PVM, Supercomputer task managers
OpenCL, RapidMind, OpenHMPP, Intel TBB
OpenMP, CUDA, POSIX, Windows, Boost Threads
Уровень приложений
Рис. 1. Уровень приложений — место симуляции исполнения алгоритма среди других подходов
Fig. 1. Applications level — the place of the execution simulation approach among the other approaches
Последнее частично нивелируется тем, что кардинальные прорывы в быстродействии редки, и обычно такие изменения — борьба за проценты и доли процентов.
На рис. 1 изображена описанная иерархия подходов и масштабов.
Реализация симуляции исполнения алгоритма на заданной архитектуре в инструментальном приложении
На первом шаге архитектура и алгоритм приводятся в форму математической модели способом, описанным в следующих разделах: «Математическая модель архитектуры» и «Математическая модель алгоритма». Эта математическая форма имеет соответствующее ей объектное представление в коде инструментальной программы и, соответственно, может быть задана пользователем при помощи интерфейса. Обладая моделью архитектуры и моделью алгоритма во внутреннем представлении, инструментальная
программа может выполнить симуляцию исполнения алгоритма на выбранной архитектуре, записывая ключевые моменты и временные отрезки этого процесса в журнал. По журналу можно сделать автоматизированные выводы о масштабируемости (по нескольким симуляциям на различном числе ядер и их временном результате) и некоторых других свойствах процесса взаимодействия архитектуры и алгоритма. На основе этих выводов и анализа журнала разработчиком можно улучшить алгоритм или принять решение о поиске более подходящей под этот алгоритм архитектуры. Автоматизация этих выводов и механизм, предлагающий гарантированные улучшения алгоритма или более подходящие архитектуры, — важная, но еще не реализованная задача. Схема оптимизации параллельных вычислений с помощью такой реализации инструментальной программы, позволяющей проводить симуляцию исполнения алгоритма на архитектуре, проиллюстрирована на рис. 2.
Система отвечает требованиям
О
Анализ
Рис. 2. Схема процесса поиска эффективного алгоритма и подходящей архитектуры
Fig. 2. The efficient algorithm and adequate architecture search process scheme
Элементы архитектуры, внутри которых происходит исполнение взаимосвязанных задач алгоритма, и порядок операций могут быть заданы для известных архитектур и операционных систем экспертами либо указаны пользователем вручную. Оба варианта возможны только в случае, если гарантия последовательности выполнения машиной задач существует, например предоставляется используемым языком. Таким образом, неоднозначность, а следовательно, и возможность расхождения с реальным поведением машины, которое в общем случае недетерминированно, убывает. Более того, практически все языки и операционные системы имеют способы гарантировать порядок исполнения для крупных задач (порядок выполнения которых не подвержен оптимизациям на аппаратном уровне), а также, с некоторыми допущениями, могут гарантировать выделенные ресурсы памяти для их исполнения. Именно подзадачами такого масштаба и оперирует предлагаемый метод. В случае отсутствия механизмов, гарантирующих (или хотя бы поддерживающих приоритеты) выполнение задачи на определенном ресурсе (ядро, узел) или его эквиваленте, метод неэффективен.
Для упрощения задачи пользователя известные архитектуры и алгоритмы могут сохраняться и использоваться повторно. С помощью знаний о том, на каких элементах какие операции будут исполняться, и алгоритма на основе диаграмм Ганта [16] программа может предположить ход исполнения алгоритма в выбранной архитектуре самостоятельно. Существуют другие подходы к симуляции процесса вычислений, в том числе рассчитанные на суперкомпьютеры, разработанные в ИВМиМГ [17], а также подходы, рассчитанные конкретно на экзафлопсные кластеры, HAW-Hamburg [18]. Разработаны и другие математические модели, которые могут быть использованы в конкретной реализации симуляции взаимодействия алгоритма и архитектуры, например модель акторов [19].
Математическая модель архитектуры
Выделим основные типы элементов архитектуры вычислительного комплекса. В соответствие этим элементам поставим свойства. Мы отказываемся от рассмотрения масштаба, в котором приходится учитывать отдельно такие малые хранилища памяти и команд, как кэш или регистры процессора, в пользу более общего. Это оправдано тем, что вычислительные задачи, с нашей точки зрения, будут представлены не уровнем набора базовых операций, или типов данных, или наборов процессорных и иных инструкций, а более общим масштабом, при котором существенен не столько сам процесс вычисления внутри, например, процессора, сколько вероятностное распределение его временных результатов. Оптимизация исполнения программы на данных уровнях отдается аппаратной логике и компиляторам [20]. Исключение составляют некоторые объемные инструкции, например векторные команды для устройств с большим объемом регистров, и некоторые другие ситуации, которые по вышеописанному критерию попадают в рассматриваемый нами масштаб.
В основу терминологии модели и выделения свойств элементов архитектуры легла система понятий, предложенная фон Нейманом [21]. Основными понятиями модели архитектуры являются арифметические или вычислительные элементы, управляющий элемент и элементы памяти. Информацию о прочих существующих моделях параллельных вычислений и их реализациях можно найти в обзорах «Models for Parallel Computing: Review and Perspectives» [22] и «Parallel and Distributed Computing. A survey of models, paradigms and approaches» [23].
1. Свойства элементов.
E — конечное множество элементов архитектуры. Включает в себя два непересекающихся множества элементов памяти M и арифметических элементов A.
M, A с E; M n A =0 — конечное множество упорядоченных кортежей свойств элемента архитектуры.
p — свойство, допустимое для одного или всех типов элементов (M, A). Свойства, разбитые по допустимости, обозначены ниже, в конце этого и нескольких последующих подразделов — 2. «Элементы памяти, их свойства»; 3. «Арифметические элементы»; 4. «Связи». Элемент и множество его свойств образуют упорядоченное множество, где на первом месте элемент, а далее идут его упорядоченные свойства (E х P).
Далее следует общее свойство для всех элементов из E, которое необходимо, в частности, для описания программируемой логической интегральной схемы (ПЛИС) [24], FPGA (Field-Programmable Gate Array) [25], программируемых архитектур в целом и некоторых других частных случаев архитектурных особенностей.
Общее свойство, присущее представителям как M, так и A:
F: (E х P)2 ^ E х P —
функция (F) воздействия данного элемента на другие элементы. Изменение при заданном наборе значений свойств элемента (P) набора свойств других элементов.
2. Элементы памяти, их свойства (M с E).
T — конечное множество типов данных. Список возможных в вычислительном процессе типов данных. Имеются в виду обобщенные типы данных, а не привычные для программистов примитивы. Например, матрица 100x100 элементов размером в 4 байт — допустимый в нашей модели тип данных.
Под элементами памяти может быть представлено очень большое количество устройств — обычная оперативная память, память на твердотельных носителях, магнитной ленте, жестких дисках, внутренней памяти графических процессоров, разделы и уровни памяти или выделенная алгоритмом под конкретную задачу область памяти и многое другое.
Свойство. Максимальный объем хранения различных данных (Т) или, другими словами, максимальное число значений данного типа в элементе памяти F: Т ^ N.
3. Арифметические элементы (А ^ Е).
О — конечное множество типов операций. Список возможных в вычислительном процессе операций. Пример: {«транспонирование», «произведение»}.
О х (Т х N) — множество «-арных операций на арифметическом элементе. Пример подмножества такого множества: {{«транспонирование», массив 2 х 2 чисел с плавающей запятой по 8 байт, 1}, {«произведение», целое число 2 байт, 2}, {«произведение», массив 10 х 10 целых чисел по 4 байт, 2}}.
Арифметические элементы выполняют операции с данными, предписанные вычислительным алгоритмом в определенном взаимосвязью подзадач и архитектурой порядке. В качестве основных и наиболее актуальных примеров арифметических элементов из реальных вычислительных систем можно назвать процессор, ядро графического процессора, сопроцессор.
Одинаковые типы операций на разных арифметических элементах обладают разными свойствами. Также одинаковые типы операций в нашей модели могут выполняться над разными типами данных. Примеры — умножение матрицы, умножение двух чисел с плавающей запятой.
В результате получаем математический объект «операция», принадлежащий множеству А х О х(Т х N). Абстрактный тип этой операции — (О). Операция исполняется на арифметическом элементе (А). Число аргументов — п, аргументы являются представителями обобщенных типов данных (Т), где п е N. Подмножествами множества типов операций (О) являются как непосредственно вычисления, так и передача данных или команд. Большинство доступных типов операций будут одинаковыми для всех арифметических элементов, но следует помнить о том, что в большинстве современных компьюте-
[ 75 ]
ров бывает как минимум два типа арифметических устройств (GPU, CPU) с разными наборами инструкций и различным временем выполнения одинаковых операций над одинаковым объемом данных.
Свойство 1. Ap1 с O x(T х N) — множество операций, доступных данному арифметическому элементу.
Свойство 2. F: Ap1 ^ R — скорость операций в условных или реальных (мс) единицах.
4. Связи (L).
L с {{е'х P',e" х P,,) |e',e" е E;P,,P,, eP} —
конечное множество связей в архитектуре. Связи могут быть между любыми элементами любых типов архитектуры.
(T х N) — подходящие для передачи по данной связи блоки размера из N значений соответствующих им типов данных (T).
В совокупности L может быть представлено как множество дуг направленного, обычно связного мультиграфа с вершинами из E.
Именно множество связей есть полное описание архитектуры в модели.
Свойство F: T х N^ R — скорость передачи для различных абстрактных типов (некоторого числа значений их представителей) между парой элементов архитектуры (e', e").
Модель алгоритма
Параллелизм вычислений может быть задан на уровне выделения отдельных областей данных для потоков вычисления, соответствующих определенным выше операциям, и условий их корректности, определяющих их взаимосвязанность в процессе вычислений. Этой взаимосвязанностью существенно обусловлена нелинейная масштабируемость алгоритмов. Одна из причин — добавление в вычислительный процесс нового ядра и выделение еще одной области ведет к росту накладных расходов на поддержание корректности и взаимосвязей областей.
Исходя из этого предлагаемая математическая модель вычислительного алгоритма, так же как и модель архитектуры, может быть представлена в виде ориентированного графа. Вершинами графа станут операции, такие как передача данных и локальные вычисления, направленными ребрами графа станут взаимозависимости операций. Формальную запись модели получают аналогично приведенной в разделе «Математическая модель архитектуры». Такое представление алгоритма зависимо от среды исполнения, в частности от набора поддерживаемых операций, но за счет этого оно ближе к реальности вычислительного процесса и может давать лучшие рекомендации к оптимизации.
Терминология модели алгоритма идентична терминологии модели архитектуры, более того, чтобы подчеркнуть взаимосвязь между их подобными элементами, используются схожие обозначения. Принципы построения модели у них общие, поэтому формальное описание модели алгоритма приводится ниже в краткой форме.
1. Свойства операций алгоритма.
Е — конечное множество операций. Включает в себя два непересекающихся множества операций передачи данных (М) и локальных операций над данными (А).
М, А с Е; Мп А = 0. Нет общих свойств.
2. Операции передачи данных (М с Е).
Т — конечное множество типов данных.
Эквивалентно множеству из модели архитектур.
Свойство d е Т х N — объем передачи данных.
3. Операции над данными (А с Е).
О — конечное множество типов операций. Эквивалентно множеству из модели архитектур.
Свойство а е О х (Т х N — и-арная операция алгоритма с указанием типов и объемов данных.
4. Связи между операциями (Ь).
Ь с {(е'х Ре,, Л Ре, )|е', Е; Ре,, Ре„е Р} —
конечное множество связей. Связи могут быть между любыми операциями. Множество связей является описанием архитектуры. Нет свойств.
Взаимодействие архитектуры и алгоритма, описание работы приложения
Опишем базовый пример, иллюстрирующий то, что происходит с описанными математическими моделями внутри инструментальной программы, реализующей симуляцию исполнения. Рассмотрим простую вычислительную операцию и узнаем целевую функцию нашей оптимизации — ее время. Модуль инструментальной программы, отражающий запрограммированный путь вычислений, аппаратную логику и операционную систему, задает модуль памяти, в котором находится нужная матрица из 10 000 элементов некоторого типа. Первый шаг и первая вершина графа вычислительного алгоритма — операция передачи этого объема данных через связь между арифметическим элементом и выбранным элементом памяти. Скорости данных операций известны либо из документации, либо из экспериментальных данных, которые можно получить, запустив соответствующий тест производительности на выбранной архитектуре.
Заранее известно и отражено в допустимых для арифметических операций на этом элементе типах, что матрица поместится, например, в кэш процессора. Известно, что все наши операции можно провести в один этап и в рамках одного только вычислительного элемента при нашем масштабе, т. е. они атомарные. Следующая вершина построенного графа алгоритма — выполнение некоторой операции над матрицей; выполняем ее в рамках арифметического элемента. Складывая предполагаемые временные затраты операций передачи данных и вычисления, получаем результаты симуляции исполнения алгоритма на нашей архитектуре
в виде оценки времени, необходимого для вычисления.
Архитектура в этом примере соответствует упрощенному персональному компьютеру, в масштабе которого процессор считается единым целым, не занятым другими задачами (или занятым так, чтобы сохранить с некоторой точностью время записи в кэш и вычислений). В рассматриваемой математической модели архитектура была представлена графом с вершиной в оперативной памяти, вершиной в процессоре и ребром канала связи от оперативной памяти к процессору. Алгоритм же был представлен вершиной операции передачи данных и вершиной операции над матрицей, а также ребром, определяющим взаимосвязь (в данном случае линейный порядок) этих действий (подробнее на рис. 3).
Формальное описание примера
Архитектура.
• т е М — память, со свойством
о рт = 1)}, где t еТ и является матрицей 100 х 100; 1 — объем хранимых данных этого типа;
• а е А — процессор, со свойствами:
о 1: а еО х(Т х а = (о, t,í), где о — «некоторая операция», ра1= {а};
о 2: ра2 = {(а, 100)}, где 100 условная скорость операции;
• 11 =((т,{Рт })^ {Ра^ Ра2
12 =((а,{Ра1, Ра2 } , {Рт })) е ^ —
связи в архитектуре.
Множество {/1; /2} и является математическим описанием архитектуры. Алгоритм.
• т е М — операция передачи данных со свойством
о Рт = №, 1)}, где t е Ти является матрицей 100 х 100; 1 — объем передаваемых данных этого типа;
• а е А — «некоторая операция» со свойством
[ 77 ]
Архитектура
Рис. 3. Граф архитектуры, алгоритма, связи между ними и шаги вычислений
Fig. 3. A graph of the architecture, algorithm, linkage between them, and the computation process steps
о ра = {а}, а е О х (Т х И), а = (о, ^ 1), операция над одной единицей данных типа V.
• I = (ЫРт }) ^ {Ра }))е L -
связи в архитектуре.
Множество {/} и является описанием алгоритма.
Расширенный теоретический эксперимент с использованием приложения и математической модели
Усложним базовый эксперимент до трех «компьютеров» с 1, 2 и 4 ядрами. Алгоритм усложним до операции с матрицей, но в этой модификации примера лишь операция над четвертью матрицы (50 х 50, полная матрица 100 х 100, 10 000 элементов типа 0 может быть выполнена в рамках одного ядра без дополнительных обращений к памяти (атомарная). Свойство каждого ядра — всего одна абстрактная операция над матрицей 50 х 50 за 1000 мс. Свойства оперативной памяти — вмещает одну матрицу из элементов
данного типа t размером 100 х 100. Свойство 4 каналов связи от памяти до каждого ядра (несмотря на то что физически канал один, представление таким графом не повлияет на результат) — передача матрицы 50 х 50 типа t за 250 мс. Этой информации достаточно для построения графа архитектуры. Граф алгоритма — 4 операции-вершины передачи данных, каждая предшествует соответствующей ей одной из 4 вершин операций с матрицами 50 х 50. Операция записи в оперативную память результата всего алгоритма с матрицей 100 х 100 для упрощения и наглядности результатов опущена. Операции разделения на подматрицы и объединения матрицы-результата также исключены как несущественно влияющие на общее время, поэтому граф алгоритма получился несвязным, состоящим из четырех К2.
В случае 2 и более ядер исполнение подзадач алгоритма уже будет параллельным. Запустим программу и построим диаграммы процессов вычислений (рис. 4-6). Этот упрощенный эксперимент иллюстрирует законы Амдала [26] и Густавсона [27].
Передача данных Ядро 1 — вычисления Передача данных Ядро 1 — вычисления Передача данных Ядро 1 — вычисления Передача данных Ядро 1 — вычисления
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Рис. 4. Диаграмма Ганта для последовательного вычисления на 1 ядре
Fig. 4. Gant diagram for a consequential computation on one core
Передача данных Ядро 1 — вычисления Передача данных Ядро 2 — вычисления Передача данных Ядро 1 — вычисления Передача данных Ядро 2 — вычисления
Рис. 5. Диаграмма Ганта для параллельного вычисления на 2 ядрах
Fig. 5. Gant diagram for a parallel computation on two cores
Эксперимент с использованием реального вычислительного устройства
Проверим теоретическое построение синтетическим тестом с реальным компьютером. Существенные детали персонального компьютера, использованного для демонстрации:
• операционная система: 64-битная Ubuntu 14.04, реализация многопоточности, близкая к POSIX стандарту;
• процессор: Intel Core 2 Duo Processor T5800, два ядра, два аппаратных потока;
• память: SK Hynix HYMP125S64CP8, в режиме 333 МГц, задержки при этой частоте — 5 5 5 15;
• исполняемый код генерируется: Oracle JVM, Java compiler 1.8.0_60, JDK 8u77.
Замеры проводились после компиляции замеряемого участка байт-кода JIT и контроля прочих оптимизаций во время исполнения. Инструменты замеров: JMH [28] (в качестве результатов приведены его данные) и Intel VTune [29]. Intel VTune использовался для перекрестной проверки возможных отклонений в результатах, вызванных методикой измерения. Также с помощью профили-
0
0
Передача данных Ядро 1 — вычисления Передача данных Ядр о 2 — вычи сл ения Передача данных Ядр о 3 — вычи сл ения Передача данных Ядр о 4 — вычи сл ения
Рис. 6. Диаграмма Ганта для параллельного вычисления на 4 ядрах
Fig. 6. Gant diagram for a parallel computation on four cores
рования контролируется исполнение параллельных подзадач на параллельных исполнителях — ядрах.
Входные данные для эксперимента: случайная плотная квадратная матрица в несжатом формате, общим размером 4 Мбайт (2024 — длина ребра, ячейки — байты), без учета указателя, выравниваний и т. п. Операции: независимые друг от друга, произведение матрицы или субматрицы на константу (2) 1000 раз. Как и в примере выше, операции объединения результатов субматриц нет. Модификации следующие: со всей матрицей, при ограничении в один поток; две операции, каждая с половиной матрицы в два параллельных потока. Модель подобного алгоритма дана ранее. К этим двум модификациям добавлены случаи с выделением 4 и 8 параллельных подзадач (потоков ОС, без контроля выполнения на выделенном аппаратном потоке) для контроля результатов.
Были получены следующие результаты тестирования модификаций алгоритма. Приведены средние округленные значения скорости выполнения операции за сто итераций по минуте исполнения каждая для всех модификаций. Среднее время операции со всей матрицей — 3909,608 ± 46,161 (здесь и далее величины в миллисекун-
дах). Время для двух параллельных операций с половиной матрицы 1856,361 (~47,48% от 3909.608) ± 54,803 (мс). Для четырех — 1518,733 ± 29,503. Для восьми — 1463,249 ± 11,261. Скорость обработки одним потоком матрицы линейно зависит от размера для матриц от 4 Мбайт до 512 Кбайт и для 512 Кбайт составляет 482,11 ± 8,621. Скорость обработки матрицы в 512 Кбайт — единственное необходимое измерение с учетом прочих допущений для симуляции исполнения в нашем приложении.
Линейная в определенных рамках функция масштабируемости этой операции заменила все остальные замеры. Погрешности получены расчетом 99,9% доверительного интервала в предположении, что мы имеем нормальное распределение времени исполнения операций. Эти данные согласуются с результатами модели. Эксперименты для четырех и восьми потоков демонстрируют, что упрощенная модель ПК не учла прочие процессы в системе и, следовательно, присутствующий в этой системе эффект улучшения утилизации процессора под конкретную задачу с увеличением числа потоков, занятых ею. Время работы с памятью, в отличие от модели, здесь опущено, так как оно меньше погрешности используемых методов
0
измерения. теоретическая пропускная способность памяти (DDR2, 333 МГц в двухка-нальном режиме) равна ~10,6 Гбайт/с, грубая оценка--400 мкс для 4 Мбайт данных исходной матрицы. Практическая скорость для данной задачи по результатам отдельных измерений оказалась ниже не более чем на порядок.
Эксперимент показал, что возможно получать релевантные данные, основываясь на представленных в данной работе моделях и их симуляции при знании трудоемкости одной отдельной операции (в общем случае операций) и функции роста ее трудоемкости в зависимости от объема входных данных для оценки соответствующих модификаций алгоритма. Для этого необходимо выдержать масштаб операций, мало подверженных возмущениям (учесть все существенные для выбранного масштаба возмущения), связанным с реализацией вычислительной системы, соблюсти атомарность операций и получить гарантию порядка крупных операций.
Заключение
В статье дан краткий обзор существующих подходов к оптимизации параллельных вычислений, описаны их преимущества и масштаб. Определено место симуляции исполнения в этой области, а также выбрана степень детализации архитектуры и алгоритмов для реализации этого метода. Обозначены его ограничения, достоинства и недостатки. Представлены математическое описание используемых моделей архитектуры и алгоритма, принцип работы разработанного приложения, реализующего взаимодействие архитектуры и алгоритма и использующего построенные модели. Раскрыты особенности такого подхода для оптимизации параллельного алгоритма и выбора более подходящей для него архитектуры. Дан пример построения моделей архитектуры и алгоритма, а также симуляции вычислительного процесса, и описан синтетический
эксперимент, демонстрирующий использование реализации вышеприведенных моделей в виде инструментальной программы. Проведен эксперимент с реальным вычислительным устройством, и его результаты сопоставлены с теоретическими, полученными с использованием симуляции и математической модели.
Список литературы
1. Heroux M. A. Software challenges for extreme scale computing: Going from petascale to exascale systems // International Journal of High Performance Computing Applications. 2009. Vol. 23. No. 4. P. 437-439.
2. Keyes D. E. Exaflop/s: The why and the how // Comptes Rendus Mécanique. 2011. Vol. 339. No. 2. P. 70-77.
3. PeutoB. L., ShustekL. J. An instruction timing model of CPU performance // ACM SIGARCH Computer Architecture News. 1977. Vol. 5. No. 7. P. 165-178.
4. Rosenblum M. et al. Complete computer system simulation: The SimOS approach // Parallel & Distributed Technology: Systems & Applications, IEEE. 1995. Vol. 3. No. 4. P. 34-43.
5. Java Concurrency Utilities. URL: http://docs.oracle. com/javase/1.5.0/docs/guide/concurrency/index.html
6. Mueller F. et al. A Library Implementation of POSIX Threads under UNIX // Winter USENIX. San Diego, CA. 1993. P. 29-42.
7. Ali-RezaAdl-Tabatabai, Kozyrakis C, Saha B. Unlocking concurrency: multicore programming with transac-tional memory // ACM Queue. 2006.
8. Jacobsen D. A., SenocakI. Multi-level parallelism for incompressible flow computations on GPU clusters // Parallel Computing. 2003. Vol. 39. No. 1. P. 1-20.
9. The OpenMP API specification for parallel programming. URL: http://openmp.org/wp/openmp-specifica-tions
10. Nvidia CUDA C Programming Guide. URL: http:// docs.nvidia.com/cuda/cuda-c-programming-guide/in-dex.html
11. POSIX — Austin Joint Working Group. URL: http:// standards.ieee.org/develop/wg/POSIX.html
12. DolbeauR., Bihan S,BodinF. HMPP: A hybrid multi-core parallel programming environment // Workshop on General Purpose Processing on Graphics Processing Units (GPGPU 2007). Technical report. 2007.
13. Threading Building Blocks. URL: http://threading-buildingblocks.org
14. Kohn S. R., Baden S. B. A robust parallel programming model for dynamic non-uniform scientific computations // Proceedings of the Scalable High-Performance Computing Conference. 1994. P. 509-517.
[ 81 ]
15. Tarkov M. S. Mapping parallel programs onto multi-core computer systems by Hopfield networks // Optical Memory and Neural Networks (Information Optics). 2013. Vol. 22. No. 3. P. 148-155.
16. Wilson J. M. Gantt charts: A centenary appreciation // European Journal of Operational Research. 2003. Vol. 149. No. 2. P. 430-437.
17. Chernykh I., Glinskiy B. et al. Using Simulation System AGNES for Modeling Execution of Parallel Algorithms on Supercomputers // Computers, Automatic Control, Signal Processing and Systems Science. 2014. P. 66-70.
18. Karfich O., Bartols F., Steinbach T., Korf F., Schmidt T. C. A hardware/software platform for realtime ethernet cluster simulation in OMNeT++: poster abstract // Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques. 2013. P. 334-337.
19. Baker H., Hewitt C. Laws for communicating parallel processes // Massachusetts Institute of Technology. 1977.
20. Ануфриенко А. В., Панов Н. В., Касьянов В. Н., Идрисов Р. И. Intuit. Оптимизация приложений с использованием компиляторов Intel. URL: http://www. intuit.ru/studies/courses/707/563/info
21. Von Neumann J. First Draft of a Report on the EDVAC // Annals of the History of Computing. IEEE. 1993. Vol. 15. No. 4. P. 27-75.
22. Kessler C., Keller J. Models for parallel computing: Review and perspectives // PARS Mitteilungen. 2007. P. 13-29.
23. LeopoldC. Parallel and Disturbed Computing. A survey of models, paradigms and approaches // Wiley, New York, 2000.
24. Абрамов С. М. и др. Возможности суперкомпьютеров «СКИФ» ряда 4 по аппаратной поддержке в ПЛИС различных моделей параллельных вычислений // Материалы международной научно-технической конференции «Суперкомпьютерные технологии: разработка, программирование, применение» (СКТ-2010). Дивноморское, 2010. Vol. 1. P. 11-21.
25. FPGAArchitecture for the Challenge. URL: http://www. eecg.toronto.edu/~vaughn/challenge/fpga_arch.html
26. Amdahl G. M. Validity of the single processor approach to achieving large scale computing capabilities // Proceedings of the spring joint computer conference. 1967. P. 483-485.
27. Gustafson J. L. Reevaluating Amdahl's law // Communications of the ACM. 1988. Vol. 31. No. 5. P. 532-533.
28. OpenJDK. Code Tools: jmh. URL: http://openjdk.java. net/projects/code-tools/jmh/
29. Donell J. Java Performance Profiling using the VTune Performance Analyzer // Intel Corporation. 2004.
References
1. Heroux M. A. Software challenges for extreme scale computing: Going from petascale to exascale systems. International Journal of High Performance Computing Applications, 2009, vol. 23, no. 4, pp. 437-439.
2. Keyes D. E. Exaflop/s: The why and the how. Comptes Rendus Mécanique, 2011, vol. 339, no. 2, pp. 70-77.
3. Peuto B. L., Shustek L. J. An instruction timing model of CPU performance. ACM SIGARCH Computer Architecture News, 1977, vol. 5, no. 7, pp. 165-178.
4. Rosenblum M. et al. Complete computer system simulation: The SimOS approach. Parallel & Distributed Technology: Systems & Applications, IEEE, 1995, vol. 3, no. 4, pp. 34-43.
5. Java Concurrency Utilities. Available at: http://docs.oracle.com/javase/1.5.0/docs/guide/concur-rency/index.html
6. Mueller F. et al. A Library Implementation of POSIX Threads under UNIX. Winter USENIX. San Diego, CA, 1993, pp. 29-42.
7. Ali-Reza, Adl-Tabatabai, Kozyrakis C. and Saha B. Unlocking concurrency: multicore programming with transactional memory. ACM Queue, 2006.
8. Jacobsen D. A., Senocak I. Multi-level parallelism for incompressible flow computations on GPU clusters. Parallel Computing, 2003, vol. 39, no. 1, pp. 1-20.
9. The OpenMP API specification for parallel programming. Available at: http://openmp.org/wp/openmp-specifications
10. Nvidia CUDA C Programming Guide. Available at: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html
11. POSIX — Austin Joint Working Group. Available at: http://standards.ieee.org/develop/wg/POSIX.html
12. Dolbeau R., Bihan S., Bodin F. HMPP: A hybrid multi-core parallel programming environment. Workshop on General Purpose Processing on Graphics Processing Units (GPGPU 2007). Technical report, 2007.
13. Threading Building Blocks. Available at: http://threadingbuildingblocks.org
14. Kohn S. R., Baden S. B. A robust parallel programming model for dynamic non-uniform scientific computations. Proceedings of the Scalable High-Performance Computing Conference, 1994, pp. 509-517.
15. Tarkov M. S. Mapping parallel programs onto multi-core computer systems by Hopfield networks. Optical Memory and Neural Networks (Information Optics), 2013, vol. 22, no. 3, pp. 148-155.
16. Wilson J. M. Gantt charts: A centenary appreciation. European Journal of Operational Research, 2003, vol. 149, no. 2, pp. 430-437.
17. Chernykh I., Glinskiy B. et al. Using Simulation System AGNES for Modeling Execution of Parallel Algorithms on Supercomputers. Computers, Automatic
Control, Signal Processing and Systems Science, 2014, pp. 66-70.
18. Karfich O., Bartols F., Steinbach T., Korf F., Schmidt T. C. A hardware/software platform for real-time ethernet cluster simulation in OMNeT++: poster abstract. Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques, 2013, pp. 334-337.
19. Baker H, Hewitt C. Laws for communicating parallel processes. Massachusetts Institute of Technology, 1977.
20. Anufrienko A. V. et al. Optimizatsiya prilozhenii s ispol'zovaniem kompilyatorov Intel [Application optimization using the Intel compiler]. Intuit. Available at: http://www.intuit.ru/studies/courses/707/563/info
21. Von Neumann J. First Draft of a Report on the ED-VAC. Annals of the History of Computing, IEEE, 1993, vol. 15, no. 4, pp. 27-75.
22. Kessler C., Keller J. Models for parallel computing: Review and perspectives. PARS Mitteilungen, 2007, pp. 13-29.
23. Leopold C. Parallel and Disturbed Computing. A survey of models, paradigms and approaches. Wiley, New York, 2000.
24. Abramov S. M. et al. Vozmozhnosti superkomp'yuterov «SKIF» ryada 4 po apparatnoi podderzhke v PLIS razli-chnykh modelei parallel'nykh vychislenii. [The «SKIF» fourth family capabilities of hardware supporting different parallel computation models at PLIS]. Materialy mezhdunarodnoi nauchno-tekhnicheskoi konferentsii «Superkomp'yuternye tekhnologii: razrabotka, pro-grammirovanie, primenenie» (SKT-2010). Divnomor-skoe, 2010, vol. 1, pp. 11-21.
25. FPGA Architecture for the Challenge. Available at: http://www.eecg.toronto.edu/~vaughn/challenge/fpga_ arch.html
26. Amdahl G. M. Validity of the single processor approach to achieving large scale computing capabilities. Proceedings of the spring joint computer conference, 1967, pp. 483-485.
27. Gustafson J. L. Reevaluating Amdahl's law. Communications of the ACM, 1988, vol. 31, no. 5, pp. 532-533.
28. OpenJDK. Code Tools: jmh. Available at: http://openjdk.java.net/projects/code-tools/jmh/
29. Donell J. Java Performance Profiling using the VTune Performance Analyzer. Intel Corporation, 2004.
S. Pomelov, Institute of Computational Mathematics and Mathematical Geophysics SB RAS, Novosibirsk, Russia, s.v.pomelov@gmail.com
Parallel programming: simulation of the algorithm execution on a given architecture
An important part of modern science and economics are numerical computations in mathematical models. Their efficiency depends on the effectiveness of the hardware. This, in turn, is related to parallel computations' optimizations. A new approach to the optimizations and developing a tool for parallel computing process optimization are the goals of the ongoing research. These software tool development principles and other resulted applications are described in the paper. Properties of computer architecture are suitable for formalization. Parallel algorithms already exist in a mathematical form. From the two points, two mathematical models are derived: the model of the computational algorithm and the computer architecture model. Along with other points, here described their properties and applications. Both models, even though they represent vastly different real-world objects, are described in the same terms and with the equivalent level of detail and structure. This distinction from similar works allows developing a new approach to comparative analysis of the algorithm scalability, as well as algorithm efficiency for a given architecture. These models are used as a basis for a core module of the software implementation for simulation and optimizing the architecture and algorithm interactions. In this article, after the computational process simulation description with the models' usage, as a midline working result, placed suggestions for practical using the software, proposed approach and results of those simulations. At the ending, a few practical examples are demonstrated. The last simulation example is crosschecked with a computational experiment, derived important conclusions from its results.
Keywords: computation simulation, parallel architectures, computation model, software scaling, algorithm optimization. About authors: S. Pomelov, Postgraduate
For citation: Pomelov S. Parallel programming: simulation of the algorithm execution on a given architecture. Prikladnaya Informatika — Journal of Applied Informatics, 2016, vol. 11, no. 6 (66), pp. 70-83 (in Russian).
