CC BY
2EFFICIENT FRAGMENTED IMPLEMENTATION OF THE TWO PHASE FLUID BOUNDARY VALUE PROBLEM
A. A. Kudryavtsev*, V. E. Malyshkin*’**’***, Yu. Yu. Nushtaev*,
*’**’*** *
*Novosibirsk State University,
630090, Novosibirsk, Russia,
**Institute of computational mathematics and mathematical geophysics SB RAS,
630090, Novosibirsk, Russia,
***Novosibirsk State Technical University,
630073, Novosibirsk, Russia
DOI: 10.24412/2073-0667-2023-2-45-73 EDN: IWCDKX
Programs construction automation is an approach which can potentially reduce complexity and laboriousness of development, debugging and modification of numerical parallel programs for multicomputers. In high performance computing it is important not just to construct a valid program, but also to make it efficient, which is a challenging problem with no satisfactory general solution. Thus various programming systems are only capable of providing high efficiency of constructed programs for a limited range of applications. To achieve this the systems employ various heuristics and particular effective solutions. Evolution of parallel program construction automation means consists in accumulating such heuristics and particular solutions in order to improve efficiency of constructed programs, as well as to widen the range of applications the system can handle effectively. It is important to investigate various particular manual implementations of numerical programs from the perspective of the possibilities of further automation of such construction. Fragmented programming technology is an approach for numerical parallel programs development and construction automation. The approach is based on the theory of parallel programs synthesis on the basis of computational models. The approach is partially supported by LuNA system, which is a system for numerical parallel programs construction automation for distributed memory systems (multicomputers). The paper is devoted to study of a particular application a two phase fluid boundary value problem solver for a 3D case and presence of wells. The application is implemented as a fragmented program in two versions: the first one is based on conventional means (MPI and OpenMP), and the second one is using LuNA system.
The basic idea behind fragmented programming is to consider a parallel program as an aggregate of sequential parts called computational fragments (CF). Each CF is implemented by a conventional sequential subroutine with no side effects. Input and output arguments of CFs are immutable pieces of data called data fragments (DFs). The execution process is considered as execution of a set of CFs in a data-flow manner, where each CF is ready for execution once all its input DFs are computed. CF’s execution produces a number of output DFs. If the program is represented as a set of CFs and DFs a system can be used to perform execution and provide dynamic properties of the execution, such as dynamic load balancing.
This work was carried out under state contract with ICMMG SB RAS 0251-2021-0005.
(c) A. A. Kudryavtsev, V. E. Malyshkin, Yu. Yu. Nushtaev, V. A. Perepelkin, V. A. Spirin,
2023
LuNA system offers a domain specific language LuNA to describe the set of CFs and DFs as LuNA-program. The system then translates the program into an intermediate representation, executable by the runtime subsystem. The runtime subsystem is basically a distributed virtual machine, which implements CFs execution in data-flow manner. Such an approach significantly simplifies the process of parallel program construction, since the programmer does not do parallel programming as such. He only describes the set of CFs and DFs, provides conventional sequential subroutines which implement CFs in C++, and that’s all. No programming of communications, synchronizations, memory management and other low-level details is required. However, the efficiency of execution of LuNA programs may be significantly lower, than that of manually developed program using conventional parallel programming means. That is caused by the fact that construction of an efficient parallel program from its high-level specification is algorithmically hard in general case. To help LuNA system to construct more efficient programs the programmer is provided with means to tune the construction process. The means are called recommendations and directives. Usage of the means can significantly increase the efficiency of the constructed program by supplying the system with the programmer’s insight on how he suggests to execute fragments. Such information includes hints on CFs and DFs distribution and redistribution to nodes, order of CFs execution, garbage collection directives, etc.
In the paper an in-depth analysis of the considered application is provided to elaborate an efficient parallel implementation of the numerical algorithm in a multi-core distributed environment. Then an efficient conventional distributed program is developed and described in the paper. The program is developed using MPI and OpenMP. Then, a LuNA program is developed and optimized. The process of development and optimization of LuNA program is presented in the paper to allow reuse of the experience for future development of similar fragmented programs. Then the experimental study of the efficiency of the constructed programs is presented. The implementations were examined on a representative set of parameters for three different hardware environments, namely, Novosibirsk State University Computing Center and Joint Supercomputer Center of RAS with Ethernet and InfiniBand interconnects. The conventional distributed program has shown the speedup of 2.3.к on 6 nodes, which is a satisfactory result for the application class. The LuNA program has shown about 3x slowdown on up to 16 computing nodes as compared to MPI implementation, which is a good result for an automatic parallel programs construction system.
To conclude, the research has resulted in development of an efficient MPI implementation of the application, based on an in-depth analysis of the numerical algorithm. Current version of LuNA system was tested for its ability to construct efficient parallel program in real life computations, and the tests showed, that LuNA is capable of it. All the implementations are described in the paper in details to allow other programmers to reuse the experience for implementation and optimization of other fragmented programs. The conducted research can also be used as the basis for development of system algorithms, capable of automatic optimization of efficiency of similar LuNA programs.
Key words: Fragmented programming, LuNA system, parallel programs construction automation, high performance computing, case study.
References
1. Ivanov M. I., Kremer I. A., Laevskv Yu. M. On the streamline upwind scheme of solution to the filtration problem // Siberian Electronic Mathematical Reports. 2019. V. 16. P. 757-776.
2. Ivanov M. I., Kremer I. A., Laevskv Yu. M. On wells modeling in filtration problems // Siberian Electronic Mathematical Reports. 2019. V. 16. P. 1868-1884.
3. Malvshkin V. E., Perepelkin V. A. LuNA Fragmented Programming System, Main Functions and Peculiarities of Run-Time Subsystem // Malvshkin, V. (eds) Parallel Computing Technologies. PaCT 2011. Lecture Notes in Computer Science. V. 6873. Springer, Berlin, Heidelberg, https://doi.org/ 10.1007/978-3-642-23178-0\_5.
4. Sintez parallelnvkh programm i sistem na vvchislitelnvkh modelvah / V. A. Valkovsky, V. E. Malvshkin. Novosibirsk: Nauka. 1988. 126 p. (In Russian).
5. Malvshkin V. E. Tekhnologiva fragmentirovannogo programmirovaniva // Vestnik YuUrGU. Seriva: Vychislitelnaya matematika i informatika. 2012. N 46 (305) (In Russian).
6. Perepelkin V. A., Ivanov M.I. Povvshenive proizvoditelnosti LuNA-programm na ostove vosproizvedeniva trass // Desvatava Sibirskava konferenciva po parallelnym i vysokoproizvoditelnvm vychislenivam. Sbornik statev. Tomsk, 2021. P. 29-36 (In Russian).
7. Informacionno-vvchislitelnyi tsentr Novosibirskogo gosudarstvennogo universiteta. (Electron. Res.]: http://nusc.nsu.ru/wiki/doku.php/doc/index.
8. Joint supercomputing center of Russian academy of sciences. (Electron. Res.]: http://www.jscc. ru.
ЭФФЕКТИВНАЯ ФРАГМЕНТИРОВАННАЯ РЕАЛИЗАЦИЯ КРАЕВОЙ ЗАДАЧИ ФИЛЬТРАЦИИ ДВУХФАЗНОЙ
ЖИДКОСТИ
А. А. Кудрявцев*, В. Э. Малышкин*’**’***, Ю. Ю. Нуштаев*,
В. А. Перепелкин*’**’***, В. А. Спирин*
* Новосибирский национальный исследовательский государственный университет,
630090, Новосибирск, Россия,
**Институт вычислительной математики и математической геофизики СО РАН,
630090, Новосибирск, Россия,
***Новосибирский государственный технический университет,
630073, Новосибирск, Россия
УДК 004.Р242
DOI: 10.24412/2073-0667-2023-2-45-73 EDX: IWCDKX
Автоматизация конструирования параллельных программ численного моделирования является актуальной темой в области системного нараллельного программирования. В общей постановке задача автоматического конструирования эффективной (но времени выполнения, расходу памяти, нагрузке на сеть и т. н.) параллельной программы но ее высокоуровневой спецификации является алгоритмически труднорешаемой. Развитие языков и систем автоматического конструирования параллельных программ осуществляется за счет накопления в системах частных решений и эвристик, обеспечивающих приемлемую эффективность конструируемых программ для классов приложений. Важную роль в этой связи имеет исследование эффективных параллельных реализаций конкретных задач численного моделирования на предмет возможности создания на основе этого опыта новых методов и алгоритмов конструирования эффективных параллельных программ для аналогичных случаев. Технология фрагментированного программирования является подходом, позволяющим автоматизировать конструирование эффективных параллельных программ численного моделирования. Система LuNA, разрабатываемая в ИВМиМГ СО РАН, инструментально поддерживает этот подход. В статье рассматривается эффективная фрагментированная реализация на мультикомиьютсрах решателя краевой задачи фильтрации двухфазной жидкости в трехмерной области в присутствии скважин. Разработаны и оптимизированы две версии программы одна на основе традиционных средств нараллельного программирования (MPI+OpcnMP), вторая полученная е помощью системы LuNA. Обе реализации основаны на анализе численного алгоритма с точки зрения возможностей его эффективной параллельной реализации. Экспериментальное исследование реализаций показало, что программа, разработанная вручную, обладает удовлетворительной эффективностью, а автоматически сконструированная программа с помощью системы LuNA уступает в производительности ручной реализации около трех раз, что является хорошим показателем для систем такого тина.
Исследование выполнено в рамках государственного задания ИВМиМГ СО РАН 0251-2021-0005.
(с) А. А. Кудрявцев, В.Э. Малышкип, Ю. Ю. Нуштаев, В. А. Переделкин, В. А. Спирин, 2023
Ключевые слова: фрагментированное программирование, система LuNA, автоматизация конструирования параллельных программ, высокопроизводительные вычисления, разбор реализации приложения.
Разработка эффективных параллельных программ численного моделирования на мультикомпьютерах трудоемка, сложна и требует специальной квалификации в области системного параллельного программирования. В частности, приходится решать такие проблемы как декомпозиция данных и вычислений, организация параллельной обработки данных, синхронизация конкурентного доступа к ресурсам, отладка коммуникаций, балансировка нагрузки на вычислительные узлы мультикомпьютера и т. и.
Автоматизация конструирования параллельных программ позволяет снижать сложность разработки, отладки и модификации параллельных программ, а также автоматически обеспечивать нефункциональные свойства программ, такие как динамическая балансировка нагрузки на узлы. Различные системы программирования и конструирования параллельных программ ориентированы на разные области применения, автоматизируют решение различных подзадач параллельного программирования.
В численном моделировании на мультикомпьютерах важнейшую роль играет эффективность конструируемых параллельных программ (тут и далее эффективность понимается в смысле времени вычислений, расхода памяти, нагрузки на есть и других нефункциональных свойств программы). Конструирование эффективной программы по ее высокоуровневой спецификации является в общем случае алгоритмически труднорешаемой задачей, не имеющей удовлетворительного универсального решения, поэтому различные системы автоматического конструирования параллельных программ ориентированы на разные области практического применения (классы алгоритмов, вычислителей и входных данных), в которых требуемая эффективность обеспечивается частными подходами. Развитие систем е точки зрения эффективности конструируемых программ состоит в том, что повышается эффективность конструируемых программ и расширяется область применения системы. С этой точки зрения важно исследовать вопрос эффективной реализации различных классов приложений на мультикомпьютерах е различной конфигурацией, обобщать этот опыт и вносить в систему конструирования в виде различных частных системных алгоритмов и эвристик.
Настоящая работа посвящена такому исследованию для численного алгоритма решения краевой задачи фильтрации двухфазной жидкости в трехмерной области при наличии скважин [1, 2]. В качестве исследуемой системы автоматического конструирования параллельных программ выступает система LuNA [3]. Эта система разрабатывается в ИВМ и МГ СО РАН и базируется на теории синтеза параллельных программ на вычислительных моделях [4], в частности, на подходе технологии фрагментированного программирования [5]. Этот подход подразумевает, что параллельная программа рассматривается как композиция применений последовательных модулей без побочных эффектов, связанных информационными зависимостями, исполнение которых осуществляется параллельно. Такая фрагментированная программа может быть разработана вручную с использованием таких средств параллельного программирования как MPI и ОрепМР, а может быть сконструирована автоматически системой LuNA на основе высокоуровневой спецификации программы на одноименном предметно-ориентированном языке.
За основу в настоящей работе взята существующая многопоточная реализация указанной задачи, разработанная авторами численного алгоритма [1, 2]. Для этой задачи
вручную разработана и оптимизирована распределенная гибридная (MPI+OpenMP) версия на основе технологии фрагментированного программирования. Также разработана и оптимизирована LuNA-версия этой задачи. Интерес в работе представляют следующие вопросы: 1) какой эффективности и масштабируемости можно достичь при ручном программировании распределенной программы; 2) насколько эффективную распределенную программу можно автоматически сконструировать с помощью системы LuNA в сравнении с версией, разработанной и оптимизированной вручную; 3) какая ручная настройка LuNA-программы (средствами самой системы LuNA) потребовалась для достижения этой эффективности, В третьем пункте подразумевается следующее. Система LuNA обеспечивает автоматическое конструирование и исполнение распределенной программы, но эффективность такой программы может существенно уступать ручной реализации в силу недостаточной развитости системных алгоритмов на текущем этапе развития системы LuNA в частности и алгоритмов автоматического конструирования параллельных программ вообще, В системе LuNA имеются средства ручного управления процессом конструирования параллельной программы, называемые аннотациями. Их применение позволяет улучшить ее эффективность за счет высокоуровневых подсказок системе. Полученный опыт ручной настройки исполнения конкретной программы может быть использован как основа для разработки системных алгоритмов, которые для данного класса задач смогут осуществлять аналогичную настройку конструирования программы автоматически.
Описанный в разделе 4 ход работ по разработке и оптимизации LuNA-программы отражает типичную этапность этих работ и поэтому может быть использован в качестве примера разработки и других LuNA-программ,
Остальная часть статьи структурирована следующим образом, В разделе 1 приводятся необходимые определения из области фрагментированного программирования и особенностей системы LuNA, Раздел 2 посвящен анализу исследуемой задачи на предмет возможностей ее эффективной распределенной реализации, В разделах 3 и 4 приводятся описания MPI- и LuNA-программ соответственно, В разделе 5 представлено расширение языка LuNA дополнительными возможностями переиспользования памяти, полученное в результате описываемых работ. Раздел 6 посвящен результатам экспериментального исследования, В заключении подводятся итоги статьи,
1. Фрагментированное программирование и система LuNA. В основе фрагментированного программирования лежит идея сборки параллельной программы из последовательных подпрограмм без побочных эффектов, называемых фрагментами кода (ФК), Каждый из ФК может быть применен к конечному набору входных и выходных аргументов, называемых фрагментами данных (ФД). Каждое такое применение называется фрагментом вычислений (ФВ). ФД являются переменными единственного присваивания и могут быть либо вычисленными, либо не вычисленными в тот или иной момент времени, ФВ исполняются по готовности их входных ФД (когда все входные ФД вычислены). Исполнение ФВ состоит в том, что соответствующий ФК применяется ко входным ФД, и это приводит к тому, что выходные ФД оказываются вычисленными. Описание рекурсивноперечислимого множества ФВ и ФД называется фрагментированным алгоритмом (ФА), Исполнение ФА состоит в исполнении всех его ФД и относится к модели data-flow,
ФВ и ФД являются крупноблочными объектами, т, е, значением ФД может выступать не только число, а например, массив, структура данных, фрагмент численной сетки и т, и, ФК, соответственно, представляет собой не отдельную операцию над числами, а последовательную подпрограмму обработки таких ФД, Такая крупноблочное! ь нужна для того,
чтобы сократить накладные расходы на представление множества ФВ и ФД во время исполнения ФА,
Базовая идея исполнения ФА на мультикомпьютере состоит в следующем. Система порождает множество ФВ и ФД, описанных в ФА, и распределяет их по узлам мультикомпьютера, Если какой-то ФД является входным для некоторого ФВ, то система перемещает этот ФД на узел, где находится ФВ, Когда все входные ФД для этого ФВ окажутся на том же узле, что и сам ФВ, то система запускает ФК, соответствующий этому ФВ, и передает ему в параметры входные ФД, Результатом выполнения ФК является порождение выходных ФД, которые система распределяет по узлам мультикомпьютера, а исполненный ФВ удаляет. Такой подход позволяет использовать в качестве ФК обычную последовательную процедуру, написанную на традиционном языке программирования, таком как C++ или Фортран, Если это не противоречит информационным зависимостям, одновременно возможно выполнение более одного ФВ, как внутри одного узла в многопоточном режиме, так и на различных узлах. Также на системе лежит задача по удалению ненужных более ФД (задача распределенной сборки мусора).
Фрагментированная программа (ФП) — это параллельная программа, реализующая ФА, ФП может быть описана на любом языке параллельного программирования и отличается от обычной параллельной программы тем, что ключевыми абстракциями в ней являются ФВ и ФД, и можно установить соответствие между ее частями и ФА, В частности, фрагментированная структура программы может явно присутствовать во время выполнения ФП, В этом случае возможно реализовать, например, динамическую миграцию ФВ и ФД по узлам с целью выравнивания нагрузки на узлы мультикомпьютера.
Конструирование ФП по описанию ФА может быть выполнено автоматически (например, с помощью системы LuNA), Это снимает с программиста круг задач, связанных с программированием коммуникаций, потоков, синхронизации доступа к памяти и другим низкоуровневым деталям параллельного программирования. Язык LuNA позволяет описывать ФА и является входным языком системы LuNA, Помимо базовых средств описания собственно множеств ФВ, ФД и ФК, в языке LuNA имеются средства, повышающие удобство программирования, например для описания фрагментированных подпрограмм. Последние называются структурированными фрагментами кода, в то время как последовательные процедуры называются атомарными фрагментами кода. Система LuNA конструирует параллельную программу для мультикомпьютера, узлами которого являются мультипроцессоры. При этом на каждом узле мультикомпьютера создаются один процесс и несколько потоков, т, е, в рамках узла применяется многопоточное программирование, а между узлами осуществляются сетевые коммуникации.
Ключевое отличие ФП от ФА заключается в наличии в ФП частичного отображения фрагментов на ресурсы вычислителя (узлы и память) и частичного императивного управления. То есть, в ФП разрешаются такие вопросы как отображение ФВ и ФД на узлы мультикомпьютера во времени, выбор порядка выполнения ФВ в рамках имеющихся информационных зависимостей, организация необходимых коммуникаций (для передачи значений ФД с одного узла на другой), выделение и освобождение памяти и т, и. Если ФА является декларативным представлением в модели data-flow, исполняемым на некотором виртуальном вычислителе, то ФП (в т, ч, в совокупности с исполнительной системой) является императивным представлением в модели CSP (communicating sequential processes), исполняемым на реальном вычислителе.
Исполнение ФА на мультикомпьютере невозможно без конструирования ФП, Алгоритмически труднорешаемая проблема конструирования эффективной параллельной программы по ее высокоуровневой спецификации формулируется в технологии фрагментированного программирования как проблема конструирования эффективной ФП по описанию ФА, Ввиду алгоритмической труднорешаемости этой проблемы автоматическое конструирование эффективных ФП возможно лишь для ограниченного класса приложений, и этот класс определяется конкретными системными алгоритмами. Разработка и развитие таких алгоритмов и методов конструирования является задачей развития системы LuNA (и других аналогичных систем). Это приводит как к повышению эффективности конструируемых программ, так и к расширению класса приложений, на которых система обеспечивает удовлетворительную эффективность.
При этом удовлетворительной является эффективность, которая может существенно уступать ручной реализации того же прикладного алгоритма за счет того, что разработка, отладка и модификация описания ФА существенно проще, чем ФП, Во многих задачах численного моделирования эффективность конструируемых программ, уступающую ручной на порядок и менее, можно считать приемлемой. Замедление до двух раз можно считать хорошим результатом,
В перспективе, по мере развития системных алгоритмов, эффективность автоматически конструируемых параллельных программ будет возрастать и со временем превысит эффективность средней параллельной программы, разработанной вручную, как это произошло с последовательным программированием и компиляторами.
На текущем этапе развития системных алгоритмов эффективность автоматически конструируемых программ может существенно уступать ручной, поэтому в систему LuNA введены вспомогательные средства управления процессом конструирования и исполнения ФП, С помощью этих средств, называемых аннотациями, программист может скорректировать отображение фрагментов на узлы, порядок выполнения ФВ, стратегию сборки мусора и другие аспекты конструируемой ФП, За счет этого возможно применение опыта программиста для повышения эффективности конструируемых ФП, При этом важно, что такая настройка программы не требует низкоуровневого программирования, как в случае ручной разработки эффективной ФП, Вместо этого программист описывает аннотации на предметно ориентированном языке (часть языка LuNA), что существенно проще, чем программирование и отладка аналогичного исполнения вручную.
Разновидностями аннотаций являются рекомендации и директивы. Рекомендации и директивы являются близкими понятиями, разница меду которыми состоит в следующем, Рекомендации носят необязательный характер и могут быть отброшены системой или заменены на другие без риска нарушить работоспособность программы. Использование рекомендаций безопасно с этой точки зрения и может в крайнем случае ухудшить эффективность, но программа выполнится. Директивы являются обязательными для исполнения системой, и с их помощью возможно нарушить работоспособность программы. Программист может применять их на свой страх и риск, но они дают дополнительные возможности по управлению конструированием ФП, Рассмотрим некоторые из наиболее употребимых аннотаций.
Рекомендации класса locator задают правило распределения и динамического перераспределения ФВ и ФД по узлам мультикомпьютера. Правило ставит в соответствие идентификатору фрагмента номер узла, на котором данный фрагмент должен размещаться. Все узлы мультикомпьютера должны иметь сквозную нумерацию, начиная с нуля. Ре-
комендация locator_cyclic задает формулу, по которой определяется номер узла, на котором предписывается хранить ФД или выполнять ФВ, Если формула дает номер узла, превышающий максимальный номер узла, то выбирается узел е номером, сравнимым е заданным по модулю количества узлов. Рекомендация locator_replicating предписывает хранить копии (реплики) ФД на каждом узле (либо на каждом втором, третьем и т, и.).
Директива req^eount относится к директивам сборки мусора. Эта директива указывает, какое количество потребителей будет у данного ФД (т, е, для скольких ФВ этот ФД является входным). После того как ФД будет потреблен заданное количество раз, он будет удален из системы, а занимаемая им память — освобождена.
Описание других директив может быть найдено в документации к системе l.u.XA 1.
В системе l.u.XA имеются средства интероперабельности — возможности вызывать LuNA-подпрограммы из традиционных MPI-программ, а также использовать MPI-программы оговоренного вида в качестве структурированных фрагментов кода. Обе эти возможности будут использованы ниже, в разделе 4, Смысл первой из них состоит в том, что на практике прикладная программа может быть объемной, а вычислительно трудоемкая часть — небольшой, В этом случае возможно переписать лишь основную вычислительно трудоемкую часть в виде LuNA-программы, которую вызвать из основной программы в качестве подпрограммы. Смысл второй возможности в том же, для чего нужны ассемблерные вставки в последовательных языках программирования. Если на высокоуровневом языке ( l.u.XA) не удается добиться удовлетворительной эффективности, то небольшая критическая часть программы может быть написана в виде традиционной низкоуровневой императивной высокоэффективной MPI-программы и вызвана как обычная фрагментированная подпрограмма из LuNA-программы,
Система l.u.XA состоит из двух основных компонент (транслятор е языка l.u.XA в исполняемое представление и исполнительная система, обеспечивающая исполнение и динамические свойства ФП), а также ряда дополнительных компонентов, таких как профилировщик, проигрыватель трасе и пр,, рассмотрение которых выходит за рамки работы,
2. Анализ задачи. Рассмотрим непоередетвенно задачу фильтрации,
В статьях [1, 2] получены векторно-матричные формы систем для решения задачи фильтрации двухфазной жидкости при наличии скважин. Если для этих СЛАУ выписать задачу для дополнения Шура, то получим следующую матрично-векторную систему:
[BТ D-1B + eC]u = f
В указанной формуле D — это симметрическая блочнодиагональная матрица с трехдиагональными блоками, C = (ё • ёТ) — симметрическая квадратная плотная матрица. Матрица В является прямоугольной (количество строк превышает количество столбцов примерно в 3 раза) и разреженной (в каждой строке матрицы по 1-2 элемента, а в каждом столбце по 3-6 элементов),
В статье [1] доказывается положительная определенность матрицы [BТD-1B + eC] для произвольного e > 0, поэтому СЛАУ можно решать итерационным методом сопряженных градиентов, В статье [2] показано, как искать е, чтобы количество итераций метода сопряженных градиентов было близко к минимальному.
Рассмотрим эту задачу на предмет эффективной параллельной реализации. Начнем с составления схемы метода сопряженных градиентов. Она представлена на рис, 1,
1 https://ssd.sscc.ru/luna
Примечание. Входные переменные на схеме дублируются в непосредственных местах потребления, чтобы не перегружать схему большим количеством линий. Также матрица Reg представленная на схеме то входных данных, соотносится с матрицей C в матричновекторной системе, представленной выше; вектор Vb на схеме соотносится с вектором e из формулы C = (е • ёТ), а число K на схеме соотносится с числом е в той же матричновекторной системе. Тот факт, что переменные Vb и K соотносятся с матрицей Reg, показан на схеме как включение переменных в матрицу.
Основу схемы составляют зависимости между данными и блоками вычислений (операциями), Последние делятся на два типа: векторные и матричные.
Векторными операциями являются:
1) VectorAddKV — умножение вектора на коэффициент и добавление его к другому вектору,
2) VectorMultK — умножение вектора на коэффициент,
3) VectorSet — копирование одного вектора в другой,
4) VectorSetLin — установление вектора как линейной комбинации двух других векторов,
5) VectorMult — скалярное произведение векторов,
6) VectorGetNorm — взятие евклидовой нормы вектора,
А матричными операциями являются:
1) MatrixMult VAdd — умножение матрицы на вектор и добавление результата к другому вектору,
2) MatrixTMult VAdd — умножение транспонированной матрицы на вектор и добавление результата к другому вектору,
3) SMatrixProgonka — умножение обратной матрицы на вектор как решение СЛАУ методом прогонки.
Рассмотрим, как можно реализовать параллельные версии этих операций.
Операции VectorAddKV, VectorMvltK, VectorSet и VectorSetLin обладают свойством покомпонентной незавиеимоети: разделив данные на фрагменты, их можно выполнить над фрагментами независимо,
В отличие от вышеперечисленных операций, в операциях VectorMult и VectorGetNorm, при разделении данных на фрагменты, помимо покомпонентных вычислений, также требуется выполнить операции редукционного типа.
Рассмотрим теперь матричные операции.
Первая операция — MatrixMult VAdd — умножение матрицы на вектор. На рис, 2 изображена схема этого умножения.
Можно заметить, что для получения j-ого элемента результирующего вектора достаточно рассмотреть j-ую строку матрицы. Таким образом, матрицу можно разбить на фрагменты, которые будут содержать какое-то множество строк матрицы. Но умножаемый вектор требуется иметь на узле полностью как один фрагмент (при других вариантах хранения вектора потребуются дополнительные коммуникации, что в данном случае негативно скажется на производительности программы).
Особенность операции MatrixTMult VAdd умножения транспонированной матрицы на вектор заключается в следующем: так как матрицы являются разреженными, и для их хранения целесообразно использовать формат CSR или CSC, то в этой операции имеет значение тот факт, что матрица является транспонированной. Схема этого умножения представлена на рис, 3 ниже.
константа
для Процедуры
переменная является выходной для процедуры
iRNonn / FNon
Vector
Set
Vector
Мин
вектор
Vector
SetLin
Vector
set
Vector
Мин
S Matrix ProgonKa
Vector
AddKV
(порядок деления: слева на право!
Vector
Мин
векторы всегда одинаковых размеров (одинаковая толщина
размеров (разная толщина
Vector
AddKV
Vector
AddKV
матрица прямоугольная (разная
| Vector CetNorm
множетсво строк матрицы
Входные данные подпрограммы
Легенда графа
© © (=)л« •
переменная
Промежуточные данные подпрограммы
Rhornv
процедура/операция
оП
переменная является входной
Do
Цвета И ооозначения типов переменных
Немного про процедуры/операции
Вызов процедуры Vector::Set с входным
вектором R и выходным вектором Q
(установить значение вектора О равным
значению вектора К!
Умножение двух чисел с плавающей запятой
И ”Ь" Дает В результате число '
число "Ь". получая в
результате число с
Размерь! векторов и матриц
©®
обводки)
^ векторь! могут оыть разных
©®
ООВОДКИ)
толщина фигурных скобок)
толщина фигурных скобок!
Толщина ооводки векторов соотносится с
толщиной фигурных CKOOOK
Переопределение данных
Левая фигурная скобка представляет
Верхняя фигурная скобка представляет
множество столоцов матрицы
Векторы считаются столоцами
Выходные данные подпрограммы
цикл while
Рис. 1. Схема метода сопряженных градиентов задачи фильтрации
Теперь ©ый элемент результирующего вектора зависит по от j/’-ой строки, а от ©ого столбца матрицы. То сеть можно разбить матрицу па фрагменты но столбцам. Но, как и в предыдущей матричной операции, умножаемый вектор придется хранить полностью.
«1,1 «2.1 «1,2 «2.2 ••• а1,п-1 «2 .п- 1 «1,71 а2.п XI *2 7Г /2 «1,1*1 + «1.2*2 А • «2.1*1 А «2.2*2 4" •+ 0\пхп . 4- «2,71*71
«то, 1 ат. 2 ••• 0*171,71- 1 0-171,11 1 1 К 1 Jm «т,1*1 4“ 0,71,2X2 4" - .. 4~ от<нхп
Рис. 2. Операция умножения матрицы на вектор
«1,1 «1,2 • «2.1 «2,2 • ■ «1,п 1 • «2,п -1 «1.П «2,л Т Ху х2 ' /1 ' /2 «1,1*1 4- «2.1*2 У •• «1.2^1 4- «2.2*2 4* •• 4- «771.1*771 4" «771.2 * 777
«т, 1 «т.2 • • «т,п - 1 «т,л хтп 1 «1,п—1*1 «2,п—1*2 + «1,п*1 + «2,п*2 4- ■■ • - У «771,71 - 1*771 4" «771.71*771
Рис. 3. Операция умножения транспонированной матрицы на вектор
Другой подход, которой можно использовать — это разбить матрицу но строкам. Это позволит также разбить умножаемый вектор па фрагменты е соответствующими размерами. Но в этом случае выполнение операции над каждым фрагментом создаст множество частичных векторов, над которыми нужно выполнить редукционную операцию. Схематично это можно увидеть па рис. 4 ниже.
Выбор способа должен осуществляться с учетом размещения данных в памяти. Этот вопрос рассматривается в разделе 3.
Последняя матричная операция — SMatrixProgonka — решает СЛАУ методом прогонки. Дня этого метода матрица должна быть трехдиагопалыюй. Методы параллельной реализации прогонки известны, по в данном случае в них пет необходимости ввиду блочной структуры матрицы, которая позволяет решать уравнения прогонки дня каждого блока (и соответствующей правой части) независимо. Количество блоков заведомо превышает количество ядер вычислительной системы при реальном моделировании, что позволяет разбить матрицу па требуемое количество частей и обрабатывать их одновременно, каждый с помощью последовательной прогонки.
3. MPI-реализация. В анализе, который представлен в предыдущем разделе, рассмотрены основные возможности реализации параллелизма. Это позволяет достичь достаточной эффективности, и в этом разделе рассматривается реализация этих возможностей в виде MPI программы. Уменьшение времени работы операций достигается пе только за счет параллелизма по процессам, по и параллелизма по потокам, а также за счет экономии па коммуникациях.
3.1. Схема параллельной программы,. Для рассматриваемой в статье задачи была построена схема параллельной программы, которая во многом совпадает со схемой, представленной в предыдущем разделе. Но теперь па схеме учтены декомпозиция данных и коммуникации, которые соотносятся с проведенным анализом. Полученная схема представлена иа рис. 5.
Рассмотрим основные моменты па этой схеме:
«1.1 01.2 • - Ol,n-l 01,71 X Х\
(72.1 а 22 ■ • 0-2,п -1 02, п XI
А1 ”1" &2,1
/2,1 а1.2*^1 ^ ^2,2*^2
fn -1.1 а1,п-1ж1 + а2,п-\х2
_ /п,1 _ _ ah„xi + а-1пх2
0(71 -1,1 0,(7 -1,2 - • 0,71 - 1 ,71 _ 1 О 777 - 1 ,11 т X „7-1
0(11,1 От,2 - • о,,,,, _ 1 О in. it Х,п _
f\,k ^777 - 1.1 *^1 ^777,1 *^2
fl.k -1,2*^1 ^ 2^2
fn-\,k - 1 ,n -1 1 “b ^771,n-1 *^2
fn.k - 1, n 1 i ,71^2
' /1 ' /1.1 h.k
/2 — /2.1 - ... + f2.k
f n - 1 /гг -1,1 fn - l,k
. /n . . /"d . _ /т7, A’ _
Рис. 4. Параллельная версия умножения транспонированной матрицы на вектор
— Наличие у данных индекса г или j показывает декомпозицию на фрагменты. Причем, в общем случае, индекс % используется дня фрагментов одного размера, а индекс j - дня фрагментов другого размера.
— Выполнение операций на схеме рассмотрим через пример. Пусть задан некоторый вектор R из алгоритма. Он представлен множеством фрагментов Я1; Я2, ,, ■ > Rm■ Если на схеме показано, что в операции участвует "R_i", то это означает, что операция выполняется над всеми фрагментами вектора /?.
— Так как появилась декомпозиция данных па фрагменты, должна быть возможность производить операции типа gather, scatter и reduce, дня которых присутствуют эффективные реализации в MPI.
3.2. Особенности реализации MPI программы. Рассмотрим особенности реализации схемы в MPI программе.
Реализация параллельных версий векторных операций полностью соотносится с описанием, представленным в раздаче 2. При декомпозиции векторов па фрагменты часть векторных операций выполняются независимо, а другие также выполняют редукцию частичных результатов но всем процессам.
Перед рассмотрением матричных операций отметим, что матрицы являются разреженными и для реальных размеров задач должны храниться в разреженном формате. Выбран
B D
деппой в начале разде.ча 2), тогда как формат CSC — дня обхода только одной матрицы
константа
infinity
переменная является входной
while
(RNorm' FNorm >
вектор
матрица
Vector
Set
результате число "с"
(порядок деления: слева на право)
размеров (одинаковая толщина
векторы могут быть разных размеров (разная толщина
матрица прямоугольная (разная
множетсво строк матрицы
Выходные данные подпрограммы
Входные данные подпрограммы
Легенда графа
{Reg
переменная
Промежуточные данные подпрограммы
процедура/операция
оп
для Функции
Do
выходной для функции
Цвета типов переменных
Немного про процедуры'операции
Вызов процедуры vector ::Set с входным
вектором R и выходным вектором Q
(установить значение вектора Q равным
значению вектора R)
Умножение двух чисел с плавающей запятой
Ь дает В результате число
Деление числа
число Ь". получая
Размеры векторов и матриц
а векторы всегда одинаковых
©0
В ооводки)
0®
ООВОДКИ)
*
матрица квадратная (одинаковая
t , толщина фигурных скобок)
толщина фигурных скобок)
- Толщина ооводки векторов соотносится с
толщиной фигурных скооок.
- Левая фигурная скоока представляет
- Верхняя фигурная скобка представляет
множество столоцов матрицы
Векторы считаются столоцами
цикл while
а_. - Фрагмент вектора Л. - Фрагмент матрицы
U - Gather + * Reduce - Scatter
Переопределение
данных
Рис. 5. Схема параллельного метода сопряженных градиентов
(Б1
и обратно имеет смысл, по в данной работе не рассматривается.
Составление параллельной версии операции умножения матрицы па вектор является одной из простых - используется подход, описанный ь разделе 2, и формат храпения матриц по повлиял па реализацию. Помимо того, что строки матрицы обрабатываются
Размеры матрицы: mxn, где m - количество потоков, п -размер выходного вектора
Шаг 1: вычисление частичных векторов:
« 1.1 «1.2 ■ • «1,71-1 «1.1, <- сюда пишет поток 0
«2.1 «2.2 • ■ «2.П-1 «2 11 сюда пишет поток 1
_«,п.1 «771.2 ' • «771,71-1 « 711,11 г- сюда пишет поток т-1
столбцы столбцы
суммирует суммирует
поток 0 поток т-1
Шаг 2: суммирование частичных векторов:
«1.1 О] 2 «1,71
«2.1 а2,2 ... &2,п-1 а2,п
«111,1 «717,2 ... (1т п - 1 &т.и
It ... 4 4
[/> /2 ■ * * In - 1 /„]
Рис. 6. Схема параллельного умножения транспонированной матрицы на вектор с использованием
потоков
разными процессами, внутри каждого процесса принадлежащие ему строки также распределяются между потоками.
Реализация параллельной версии операции умножения обратной матрицы на вектор использует метод прогонки и полностью соответствует тому, что описано в разделе 2. Стоит отметить, что количество диагональных блоков, на которые воможио разбить матрицу, заведомо больше, чем требуется дня загрузки каждого ядра вычислителя. А дня реализации параллелизма достаточным будет количество блоков, сопоставимое с произведением количества процессов на количество потоков. Каждый процесс берет на себя группу блоков и распределяет их между своими потоками (с соответствующим распределением блоков но узлам и ядрам мультикомиыотера).
С операцией умножения транспонированной матрицы на вектор возникла проблема с распределением вычислений но потокам. Так как обход производится но строкам (делать обход но столбцам не позволяет формат хранения), возникает следующая проблема: использование потоков дня распределения итераций цикла нецелесообразно, так как тогда потоки будут конкурировать за данные, и возникает потребность в добавлении взаимного исключения, что сделает производительность данной операции только хуже.
Но можно реализовать другой подход распределения вычислений но потокам. Дня этого требуется создать несколько копий выходного вектора дня частичных результатов, которые можно представить как матрицу. Тогда каждый поток может писать в определенную строку матрицы, которая соответствует его идентификатору, и все потоки могут независимо друг от друга производить вычисления. После вычислений требуется выполнить редукцию копий в единый вектор. Схематично работа алгоритма представлена на рис. 6.
Один из минусов такого подхода — это потребление памяти. Насколько этот объем будет большим, зависит от количества потоков и размера результирующего вектора. Поэтому на большом количестве потоков и на больших размерах сетки последовательная версия может оказаться более эффективной по времени и/или памяти,
4. LuNA-реализация. Данный раздел посвящен разработке программы и ее оптимизации, также анализу нефункциональных свойств программ, конструируемых системой I.U.ХА для фрагментированных программ. Наибольший интерес представляет текущее состояние системы 1.11.ХА. ее возможности и результаты, которые могут быть получены с помощью данной системы. Достижение удовлетворительной эффективности конструируемых программ в таких системах, как i.uX А. является проблемой, поэтому интерес представляет то, какую производительность на текущий момент способна выдавать система на данном классе задач. Конструирование программы с 2-3-кратным отставанием можно считать приемлемым. Основные вопросы, на которые отвечает данный раздел:
1) Возможно ли реализовать фрагментированный алгоритм решения реальной задачи фильтрации в системе I.uX А'.’
2) Какова эффективность реализации в системе I.uX А по сравнению с MPI реализацией?
3) Какие методы надо использовать для достижения максимальной эффективности конструируемой I.uX А программы?
В рамках данной работы была реализована и оптимизирована I.uX А программа, реализующая алгоритм фильтрации. Ниже рассмотрим эту реализацию в 4 этапа, которые соответствуют хронологическим этапам разработки и могут быть использованы для решения других похожих задач. Каждый этап приближает показатели эффективности реализации задачи в системе I.uX А к MPI реализации алгоритма,
4.1. Реализация алгоритма в система LuNA. Реализация в системе LuNA была создана на основе параллельной программы [6] и реализации, описанной в разделе 3, Использовалась схема параллельного метода сопряженных градиентов (рис, 5), Подробно задача фильтрации описывается в разделе 2, Для каждой процедуры из параллельной реализации создан фрагмент кода с такими же входными и выходными данными. Каждому фрагменту вектора в алгоритме был поставлен в соответствие ФД в LuNA,
Как пример можно рассмотреть процедуру VeetorGetNorm из схемы параллельного метода сопряженных градиентов. Есть входные и выходные данные процедуры, тип зависимости по данным и его особенности. Благодаря этой информации можно создать соответствующий ФВ в программе LuNA, Пример в листинге 1,
Листинг 1. Подпрограмма Norm.
01: sub Norm (name FNorm, name F)
02: {
03: df tmp;
04: for i =0, ,$FG—1 05: norm(tmp[i], F [ i ]) ;
06: ReduceSum(FNorm, tmp, $FG);
07: }
В листинге 1 представлена фрагментированная подпрограмма Norm, Выходными данными тут являются итоговая норма вектора F, Сам вектор F представлен в фрагментированном виде, каждому фрагменту соответствует свой ФД в программе LuNA, Фрагмент
кода состоит из ФВ norm (строка 05), который производит вычисление нормы соответствующего ФД и ФВ RedueeSum (строка 06), который производит суммирование всех норм, советующих ФД вектора, Константа $FG имеет значение общего количества ФД, на которое разбит вектор F,
Основная цель данного этапа — написание корректной программы в системе LuNA. Под корректностью понимается соответствие выходных данных, то есть выходные данные программ, реализованных на MPI и на LuNA, должны совпадать.
На данный момент развития системы LuNA алгоритмы автоматического управления памяти и распределения по узлам в системе LuNA не могут обеспечить удовлетворительную эффективность в данной задаче, поэтому необходима настройка исполнения. Основные проблемы:
1) чрезвычайно большой расход памяти из-за плохого автоматического управления памятью;
2) алгоритмы автоматического распределения фрагментов по узлам в сети производят неэффективное распределение по узлам ФВ и ФД,
4,2, Настройка исполнения, использование основных аннотаций. Цель данного этапа - базовая настройка исполнения посредством аннотаций.
Были решены проблемы первого этапа.
Основные изменения представлены ниже:
1) Для решения проблемы с переполнением памяти во время работы программы решено использовать директиву системы LuNA, а именно req^count. Данная директива указывает, сколько раз должен будет потреблен ФД перед удалением. Пример в листинге 2,
Листинг 2. Подпрограмма set_lin.
01: sub set_lin(name res , name kl , name vl , name k2, name v2)
02: {
03: for i=0,,$FG—1 04: cf setlin^mat [ i ] : setlin^mat ( res [ i ] , kl , vl[i], k2, v2[i]) @{
05 locator_ cyclic : $LOCl (i);
06 req coun t res [ i] = 5 5
07 };
08 } @ {
09 locator_ cyclic res [n ] => $LOCl (n
10 locator_ cyclic vl M => $LOCl(n)
И locator_ cyclic v2M => $LOCl(n)
12 locator replic ating kl => all ;
13 }
В листинге 2 представлена фрагментированная подпрограмма set_____lin, необходимая
для реализации алгоритма. Используется директива req^count “имя ФД”[индеке] = целое число, В данном фрагменте кода указывается, что ФД res[i] будет потреблен 5 раз, после чего удален автоматически средой выполнения,
2) Для более эффективного управления распределением по узлам были добавлены локаторы, а именно locator_cyclic. Локаторы реализуют выбор узлов в распределенной
системе. Данный локатор указывает, на каком узле будет выполняться ФВ и на каком узле хранить ФД;
Пример в листинге 3,
Листинг 3. Подпрограмма vector_mult.
01: sub vector_mult (name res , name X, name Y) {
02: df tmp;
03: for i=0,,$FG—1
04: vector_mult_mat (tmp [ i ] , X[ i ] , Y[ i ]) @ {
05: locator_cyclic :$LOCl( i );
06: req^count tmp [ i ] = 1;
07: };
08: reduee^sum (res , tmp, tmp, $FG);
09: } @ {
10: locator_cyclic Y[n] => $LOCl(n);
11: locator_cyclic X[n] => $LOCl(n);
12: locator_cyclic tmp[n] => $LOCl(n);
13: }
В листинге 3 представлена фрагментированная подпрограмма реализации vector_mult. Данный фрагмент кода состоит из ФВ veetor_mult_mat и reduee^sum. Произведение фрагментов векторов производит vector_mult_mat, а объединение результатов — reduee^sum, В строке 05 указана рекомендация locator_cyclic, которая указывает на узел, на котором будет выполнен соответствующий ФВ, Рекомендации, указанные в строках 10, 11, 12, указывают, где находятся соответствующие ФД,
3) Построение программы в системе LuNA на основе уже имеющейся параллельной реализации накладывает некоторые ограничения. Одно из таких ограничений — это структуры данных, которые используются в оригинальной программе, В данном случае говорится про структуру (в смысле C++) Matrix, которая используется в существующем коде для представления значений разреженных матриц и которая не лежит непрерывно в памяти, в отличии от ФД системы LuNA, Некоторые ФВ используют в процессе своей работы именно структуры Matrix, для использования этой структуры в ФВ необходима сериализация и десериализация в ФД, Причем для экономии памяти нужно отображение Matrix в ФД, То есть фактически Matrix превращается в интерфейс для доступа к различным областям соответствующего ФД,
4) В алгоритме существуют состояния, в которых необходимо иметь полный вектор для дальнейших вычислений. Для объединения фрагментов векторов в единый вектор используется фрагментированная подпрограмма. Она рекурсивно собирает полный вектор, Для эффективности данная подпрограмма сначала собирает все ФД внутри узла, объединяя их в единый ФД, после данные ФД с разных узлов объединяет в единый ФД, представляющий полный вектор.
После данных манипуляций над программой LuNA было проведено сравнительное тестирование, которое показало отставание реализации LuNA от MPI реализации в 5 раз в общей памяти на одном узле и в 30-40 раз на распределенной памяти. Такие показатели являются неприемлемыми, в связи с этим целесообразна дальнейшая настройка исполне-
ния.
4,3, Дополнительная настройка исполнения, использование дополнительных аннотаций. Цель данного этапа - более тонкая настройка исполнения, затрагивающая более сложные механизмы исполнения.
Изменения в данном этапе:
1) Одна из проблем е производительностью на распределенной памяти связана е чрезмерным количеством рассылок по сети. Матрицы, необходимые для работы множеству ФВ, изначально инициализируются на основном узле и находятся в его локальной памяти, Остальные узлы не имеют копий матрицы, следовательно, при запусках ФВ на этих узлах каждый такой запуск сопровождается запросом и пересылкой матрицы на соответствующий узел. Для решения этой проблемы была использована рекомендация locator_replicating, которая указывает на то, что соответствующий ФД надо поместить на определенное множество узлов. Пример в листинге 4,
Листинг 4. Подпрограмма init_args.
01: init _ args (m_R_init_full , m_pr_inil_fu 11 .
02: m_pVb_init_full , m_K, m_pB , mj>D, m_pBt) @ {
03: req^eount in__H___inil_fu 11 = $FG/$NP + 1;
04: req^eount in__pi _init_fu 11 = $FG/$NP;
05: req^eount in__p \ 1 л_init_fu 11 = $FG/$NP;
06: locator _ replicating m_pB => all;
07: locator _ replicating m _pD => all;
08: locator _ replicating mj>Bt => all;
09: locator _ replicating m^E^init^full => all;
10: locator _ replicating m_pr_inii___fn 11 => all;
11: locator _ replicating m_pVb_init_full => all;
12: };
В листинге 4 представлена фрагментированная подпрограмма, инициализирующая данные, такие как матрицы m_pB. m^pBt, m^pBt, loeator^replieating “имя ФД” => множество узлов, В данном листинге рекомендация locator_replicating указывает скопировать ФД е этими матрицами на вес доступные узлы. Если ФВ запросит любой из этих ФД, то в результате запроса будут получены данные, находящиеся в локальной памяти соответствующего узла.
Выгода в данном случае состоит в том, что ФД однократно рассылается по всем узлам, а затем многократно потребляется на различных узлах. Каждое из таких потреблений выполняется локально, без необходимости многократно передавать ФД с единственного узла хранения на узлы потребления,
2) Система LuNA является системой с единственным присваиванием. При модификации ФД ФВ создают новые ФД с уже измененными данными, при создании ФД выделяется память и происходит копирование новых данных, а предшествующий удаляется из памяти. При итерационной обработке данных это неэффективно. Поэтому решено использовать механизм уничтожающего потребления. Этот механизм позволяет использовать и изменять буфер предшествующего ФД в текущем ФД,
Тестирование показало, что отставание реализации LuNA к MPI реализации удалось сократить, В общей памяти показатели почти приблизились к удовлетворительным. На распределенной памяти отставание в 6-10 раз в зависимости от количества узлов.
4,4, MPI процедура. Как показало профилирование, узким местом в программе является сборка вектора из распределенных фрагментов в один фрагмент, представляющий весь вектор. При исполнении этой подпрограммы стандартными алгоритмами системы LuNA возникает большое количество выделений памяти и копирования ее значений. Также из-за особенностей алгоритма здесь происходит наибольшее количество рассылок по сети. То же самое верно и для подпрограмм, реализующих редукцию,
В системе LuNA есть возможность описывать подпрограммы на N11*1. Этот механизм позволяет встраивать низкоуровневый императивный код в LuNA-программу в качестве распределенной подпрограммы, представляющейся для объемлющей программы обычной LuNA-подпрограммой с точки зрения ее интерфейса, но внтури реализуемую традиционным MPI-кодом, Логику работы такой подпрограммы можно представить в виде следующих 4 частей:
1) запрос всех необходимых входных ФД;
2) сборка фрагментов вектора в рамках одного узла (в общей памяти) или суммирование частичных сумм одного узла;
3) объединение фрагментов векторов с каждого узла в один вектор посредством MPI_Allgatherv или суммирование частичных сумм всех узлов посредством MPI_Reduce;
4) помещение собранного вектора или итоговой суммы на нужные узлы.
Для пользователя MPI подпрограмма выглядит как обычный фрагмент вычислений со своими входными и выходными данными. Рассмотрим такую подпрограмму на примере редукции (листинг 5),
Листинг 5. Вызов reduce_ sum_mpi.
01: reduee^sum^mpi (tmp, res) @ {
02: number^dfs: $FG ‘tmp;
03: number^dfs: 1 ‘res;
04: };
В листинге 5 представлен вызов ФК reduce^sum^mpi. Входные ФД — tmp, выходные — res, В строке 02 указано количество входных ФД (тут $FG — это обозначение статической константы, задающей количество фрагментов), в строке 03 - выходных.
Листинг 6. Реализация reduce_sum_mpi.
01: class EeduceSum : public Subroutinelnstance {
02: using Subroutinelnstance :: Subroutinelnstance ;
03: double result = 0;
04: double local^result = 0;
05: std :: mutex mutex;
06: int dfs^count ;
07:
08: void request^dfs () override {
09: dfs^count = id_info [ 0 ], number [ 0 ] ;
10: int chunk = dfs^count / mpiSize ;
11: for (int i = chunk * mpiRank;
12: i < chunk * (mpiRank + 1); i++)
13: request (id^info [0] , id [ i ] ,
14: CyclicLocator (mpiRank) ,
15: [this](const DF &df) {
16: on_reeeive_df ( df);
17: }
18: );
19:
20: void on_receive_df (const DF &df) {
21: loeal^result += df . get _ real ();
22:
23: std : : atomie_feteh_add(&reeeived_eount , 1); 24:
25: if (received_count = dfs^eount) {
26: submit^job ([ this ] () {
27: MPI_Reduce(&local_result , &result ,
28: 1, MPI_DOUBLE, MPI_SUM, 0, MFI_OCMM_WMD); 29: if (mpiRank = 0) {
30: post (
31: id_info [ 1 ] , id ,
3 2: DF (result),
33: CyclicLocator (0) ,
34: dfs^eount * mpiSize + 2);
35: destroy_callback ();
36: }
37: });
38: }
39: }
40: };
В листинге 6 представлена реализация ФВ reduee^sum^mpi, В соответствии е логическими частями, изложенными выше, она поделена на 4 части, В строках 08-18 определен метод, который выполняет запрос всех необходимых ФД, Для этого из аннотаций number^dfs извлекается количество входных ФД (строка 09), затем е помощью цикла по индексам входных ФД, отображенных на текущий узел (строки 11-12) осуществляется их запрос из системы в подпрограмму (строка 13) с указанием обратного вызова на обработку каждого входного ФД (строки 15-17), В методе on_receive_df (строки 20-39) определяется обработка каждого из входных ФД, А именно, осуществляется их суммирование (строка 21) и подсчет их количества (строка 23), Когда все входные ФД получены (строка 25), то вызывается коллективная операция MPI_Reduce (строка 27), после чего результат редукции — выходной аргумент подпрограммы — передается системе (строки 30-34), а сама подпрограмма редукции завершается (строка 35),
5. Расширение возможностей управления памятью. В данном разделе рассматривается расширение языка LuNA дополнительными средствами, обеспечивающими более эффективную работу с памятью за счет переиспользования памяти для хранения различных ФД, ФД являются переменными единственного присваивания, что означает, что даже незначительное изменение некоторого крупного объекта данных означает, что в ФА будет описано два ФД — до модификации и после. Наивная реализация множества ФД подразумевает, что для каждого выделяется область в памяти. Соответственно, в итерационных и аналогичных алгоритмах расход памяти будет существенно выше, чем у программ, написанных вручную, В частности, данная проблема наблюдалась и в рассматриваемой выше
задаче фильтрации двухфазной жидкости: в ней выполняется итерационная обработка данных, работающая недостаточно эффективно при постоянном копировании данных. Решение было найдено в незадокументированном системой способе присвоить буфер памяти одного ФД другому, что можно считать довольно опасным решением, побочные эффекты которого непредсказуемы. Поэтому была предложена идея поддерживаемого системой механизма уничтожающего потребления, позволяющего перезаписывать участок памяти, занимаемый входным аргументом, новыми данными, составляющими выходной аргумент. Идея данного механизма довольно проста: он позволяет разработчику пометить один из аргументов атомарного фрагмента кода как поглощающий, а другой как поглощаемый, При написании самой подпрограммы, соответствующей фрагменту кода, программист должен позаботиться о том, чтобы данные поглощающего аргумента находились в том же участке памяти, что и данные поглощенного аргумента, в противном же случае возникнет ошибка в системе.
На основе данной идеи был реализован механизм уничтожающего потребления в системе LuNA, разработка которого состояла из следующих этапов:
1) В грамматику языка добавлена директива уничтожающего потребления, что позволяет использовать ее в коде LuNA-программ;
2) Разработчику предоставлен метод DF::grab_buf(DF &df), позволяющий поглощающему аргументу захватывать буфер поглощаемого;
3) Добавлены поля в генерируемом компилятором json файле, позволяющие системе обнаружить, что аргументы связаны директивой уничтожающего потребления;
4) Реализована генерация кода проверки компилятором LuNA, обеспечивающая контроль над выполнением уничтожающего потребления: если оно объявлено, то оно действительно должно произойти.
Пример использования уничтожающего потребления приведен в LuNA-программе на листингах 7 и 8,
Листинг 7. LuNA-программа (program.fa)
01: import init _ var (name, int , int) as init_var;
02: import destructive_consuming (name a, value b) as DC @ {
03: destruct b => a;
04: };
05:
06: sub main()
07: {
08: d f x , у ;
09:
10: i nit_v а г ( x . 2, 0) @ {
11: req^count x=2;
12: };
13:
14: DC(v, x) @ {
15: req^count у = 1;
16: };
17: }
В LuNA-программе на листинге 7 объявлено два фрагмента вычислений (строки 09-11 и 13-15), Сигнатуры соответствующих им фрагментов кода приведены в строках 01-04, Параметр типа name в сигнатуре является выходным, остальные — входными. Это задает информационные зависимости фрагментов вычислений. Аннотация destruet показывает, что выходной ФД а должен быть записан в буфер, в котором будет подан на вход ФД Ь. Листинг 8. Фрагменты, кода (ucodes.cpp)
01: ^include <estdio>
02: ^include "ucenv.h"
03:
04: void init_var(DF A*<1(1 , int vail , int va 12 )
05: {
06: int *arr = (int*) malloe(2 * sizeof (int ));
07: arr[0] = vail ;
08: arr[1] = val2 ;
09: dfl,create<int >(2);
10: memcpv ( dfl , getDatacint > (), arr, 2 * sizeof (int ));
11: free ( arr );
12: }
13:
14: void destructive_consuming (DF Ad 12 . DF Adfl)
15: {
16: df2 , grab^buf ( dfl );
17: }
В листинге 8 определены ФК init_var (строки 04-12) и destructive_consuming (14-17), Сигнатуры методов соответствуют объявлениям в листинге 7, В ФК init_var создается и инициализируется массив целых чисел, который затем переписывается в выходной ФД dfl. Во втором ФК осуществляется передача буфера от входного ФД к выходному ФД, В общем случае значение буфера памяти может быть изменено.
Данная работа — это важный шаг в сторону улучшения эффективности управления памятью в системе LuNA, Также стоит отметить, что была реализованна проверка выполнения уничтожающего потребления, которая заключается в следующем. Фрагмент кода — это процедура на языке C++, автоматический анализ которого затруднителен. Но возможно проверить после вызова фрагмента кода, что разработанный метод DF::grab_buffer действительно был вызван ровно один раз для каждой пары поглощающего и поглощаемого ФД,
6. Экспериментальное исследование. Тестирование полученных программ проводится в двух целях:
1) Оценить, насколько эффективной получилась MPI реализация, каков ее коэффициент распараллеливания, и какого ускорения удалось достигнуть по сравнению с многопоточной реализацией. Также стоит отметить, что данную MPI реализацию можно условно считать эталоном эффективности, с которым LuNA должна сравниваться,
2) Посмотреть, какая достижимая эффективность программы, сконструированной системой LuNA на конкретном примере.
Соответственно, был проведен сравнительный анализ MPI и LuNA реализаций на предмет эффективности.
Таблица 1
Конфигурации вычислительных узлов на кластерах МВС-10П и НГУ
Характеристика Кластер М ВС-11)11 Кластер НГУ
Процессор Illt6l ХбОП Е5-2690 (Sandy Bridge) Intel Xeon Х5670 (Westmere)
Частота процессора 2.9 ГГц 2.932 ГГц
Кол-во ядер процессора 8 6
Кол-во вирт. процессоров 16 12
Кол-во процессоров в узле 2 2
Кол-во ядер в узле 16 12
Кол-во вирт. процессоров в узле 32 24
Объем опер, памяти в узле 64 ГБ 24 ГБ
Таблица 2
Оптимальное количество потоков на разном количестве узлов
Кол-во Кластер НГУ Кластер МВС
узлов ОрепМР MPI LuNA ОрепМР MPI LuNA LuNA IB
1 12 8 12 16 8 18 21
2 12 4 15 16 8 18 21
4 12 4 15 16 8 18 21
6 12 4 15 _ _ _ _
8 _ _ _ 16 8 18 21
12 _ _ _ 16 8 18 21
16 - - - 16 8 18 21
Тестирование проводилось на двух кластерах: на кластере НГУ [7] и на кластере МВС-10П [8]. На последнем также рассмотрены разные сетевые интерфейсы (Ethernet и InfiniBand), Это позволяет увидеть, как разное оборудование влияет на работу программ. Конфигурации узлов представлены в табл, 1,
Для тестирования были выбраны такие параметры задачи, которые используют для типичного расчета:
— размер сетки: 100x100x100,
— количество шагов по времени: 1,
— максимальное количество итераций: 100,
— размер временного шага: 2000,
Примечание, В реальных расчетах количество шагов по времени может быть больше на порядки. Но виду того, что каждый шаг по времени выполняется одинаково е точки зрения нефункциональных свойств исполнения программы, то в настоящей работе проводятся эксперименты с количеством шагов, равным 1,
Эмпирическим путем для каждой реализации, кластера и количества узлов было выбрано оптимальное количество потоков (дающее наименьшее время выполнения программы), Выбранное количество потоков на разном количестве узлов и на разных кластерах представлено в табл, 2, Отметим, что ОрепМР — это многопоточная реализация, MPI и LuNA — реализации с использованием соответствующих технологий, a LuNA IB — LuNA реализация, запуск которой производится с использованием сетевого интерфейса InfiniBand,
Рис. 7. Графики результатов тестирования MPI и LnNA реализаций на разных кластерах. А на кластере НГУ, Б на кластере МВС, В на кластере МВС с использованием InfiniBand. Г на
кластере МВС без учета коммуникаций
Время работы программ па разных кластерах и разном количестве узлов
Таблица 3
Кол-во Кластер НГУ К тетер МВС
узлов ОрспМР MPI LuNA ОрспМР MPI MPI IB MPI NX' MPI IB КС LuNA LuNA IB
1 G.7113G 7.17733 9.21200 5.04908 7.07G4G 7.14995 G.40000 G.45000 12 12.54000
2 G.7113G 4.84004 5.77500 5.04908 74.37290 19.72170 4.39000 4.2G000 104 22.19400
4 G.7113G 3.G1975 4.5G400 5.04908 12G.G1900 11.41900 2.99000 3.23000 245 10.10900
G G.7113G 3.11598 4.14400 - - - - - - -
8 - - - 5.04908 179.4G900 11.44580 2.48000 2.71000 37G 18.21900
12 - - - 5.04908 1G2.03300 13.84410 2.48000 2.3G000 401 23.54100
1G - - - 5.04908 212.37G00 12.55710 2.21000 2.17000 714 27.31500
В результате получены графики, представленные иа рис. 7. На графиках дня удобства восприятия время выполнения многопоточной реализации на одном узле продублировано дня всех значений количества узлов.
В табл. 3 представлены значения, на основе которых строились графики. Отметим в дополнение к тому, что описано перед табл. 2, MPI IB — запуск MPI реализации е использованием InfiniBand, MPI ХС — результаты MPI реализации без учета коммуникаций, MPI IB ХС — объединение двух предыдущих.
По графикам на рис. 7 видно, что результаты дня различных кластеров отличаются. На графике А (кластер НГУ) время выполнения программы уменьшается с увеличением количества вычислительных узлов, что является ожидаемой картиной. Но иа кластере МВС-10П (графики Б и В) картина обратная, с увеличением количества узлов время возрастает. Так как программа и ее параметры были одни и те же, то такая разница характеризует аппаратное обеспечение. Наиболее вероятная причина может быть в том, что производи-
Рис. 8. Графики зависимости ускорения и эффективности от количества узлов на кластере НГУ,
Д ускорение. Е эффективность
'вольность коммуникационной подсистемы относительно производительности процессоров па кластере НГУ выше, чем па МВС-10П, что позволяет поставлять по сети данные дня обработки достаточно быстро, чтобы от параллельного исполнения был выигрыш. На кластере же МВС-10П сетевая подсистема по справляется, поэтому увеличение количества узлов приводит к замедлению. Эту версию подтверждает и разница между графиками Б и В, где па кластере МВС-10П использовались коммуникационные подсистемы с разной производительностью (Infiniband быстрее Ethernet, и, соответственно, увеличение времени выполнения меньше в случае Infiniband). Также это косвенно подтверждается тем, что время собственно вычислений (график Г) падает пропорционально числу узлов, а значит время расходуется именно па коммуникации. Такая качественная картина сохраняется и дня MPI-, и дня LuXA-ирограммы, что говорит о том, что соответствующие нефункциональные характеристики этих программ аналогичны. При этом LuXA-ирограмма работает медленнее за счет накладных расходов па работу исполнительной системы, и но графикам видно, что основная часть этих накладных расходов приходится па коммуникации.
Тем самым, па кластере НГУ удалось добиться эффективности выше, чем дня многопоточной реализации. Отметим дополнительно, какие значения получились дня ускорения и эффективности распараллеливания дня реализаций. Их зависимость от количества узлов представлена па рис. 8. Полученная эффективность является нормальной дня такого класса задач, а именно, для разреженных матрично-векторных операций, характеризующихся малым объемом вычислений па единицу объема данных.
Касательно LuXA реализации также можно отметить, что после проведения всех оптимизаций она показана достаточно хорошие результаты при решении этой задачи. На кластере НГУ с быстрой коммуникационной подсистемой отставание составило примерно 30 %, па кластере МВС отставание составило 2,5 и 3,5 раза соответственно с InfiniBand и без. Насколько такое отставание является приемлемым — зависит от конкретной ситуации, в которой требуется программа. В этой связи можно назвать следующие соображения. Во-первых, часто более существенной является экономия по времени выполнения программы, а времени разработки программы, особенно если программу по планируется эксплуатировать длительное время. Следует также сопоставлять расходы па эксплуатацию суперкомпьютера с расходами па разработку программы. Существенно, что и квалификационные требования к программисту при ручном программировании выше.
Во-вторых, системы параллельного программирования в настоящее время еще по являются доминирующим инструментом разработки параллельных программ, в отличие от ручного программирования. По мере развития системных алгоритмов эффективность ав-
тематически конструируемых программ будет повышаться, как это было с компиляторами дня последовательных языков программирования, В частности, будет повышаться эффективность и тех программ, которые были написаны ранее.
Заключение. В работе рассмотрена задача эффективной параллельной реализации решения реальной численной краевой задачи фильтрации па основе технологии фрагментированного программирования вручную и с использованием системы автоматического конструирования параллельных программ LuXA, Проведено исследование нефункциональных свойств численного алгоритма и его параллельных реализаций, в том числе экспериментальное иа двух различных мультикомиыотерах. Была вручную получена эффективная реализация фрагментированной программы. Был рассмотрен процесс разработки и оптимизации LuXA-реализации той же задачи. Достигнута эффективность, уступающая ручной около 3-х раз, что является хорошим показателем дня системы LuXA, Результаты исследования могут быть взяты за основу дня разработки аналогичных фрагментированных программ, а также дня разработки улучшенных алгоритмов системы LuXA, обеспечивающих оптимизацию LuXA-ирограмм такого типа автоматически.
Список литературы
1. Ivanov M.I., Krcmcr I. A., Laevskv Yu. М. On the streamline upwind scheme of solution to the filtration problem /7 Siberian Electronic Mathematical Reports. 2019. V. 16. P. 757 776.
2. Ivanov M.I., Krcmcr I. A., Laevskv Yu.M. On wells modeling in filtration problems /7 Siberian Electronic Mathematical Reports. 2019. V. 16. P. 1868 1884.
3. Malvshkin V. E., Pcrcpclkin V. A. LuXA Fragmented Programming System, Main Functions and Peculiarities of Run-Time Subsystem /7 Malvshkin, V. (eds) Parallel Computing Technologies. PaCT 2011. Lecture Notes in Computer Science. V. 6873. Springer, Berlin, Heidelberg, https://doi.org/ 10.1007/978-3-642-23178-0\_5.
4. Синтез параллельных программ и систем на вычислительных моделях / В. А. Вальковский, В.Э. Малышкин; Отв. род. В.Е. Котов; АН СССР, Сиб. отд-ние, ВЦ. Новосибирск: Наука. Сиб. отд-нис, 1988. 126 с.
5. Малышкин В.Э. Технология фрагментированного программирования /7 Вестник ЮУрГУ. Серия: Вычислительная математика и информатика. 2012. № 46 (305).
6. Перенелкин В. А., Иванов М. И. Повышение производительности LuNA-нрограмм на основе воспроизведения трасе /7 Десятая Сибирская конференция но параллельным и высокопроизводительным вычислениям. Сборник статей. Под редакцией А. В. Старченко. Томск, 2021. С. 29 36.
7. Информационно-вы числительный центр Новосибирского государственного университета [Электронный рссурсф http://nusc.nsu.ru/wiki/doku.php/doc/index.
8. Межведомственный Суисркомиьютсрный Центр Российской Академии Наук [Электронный рссурсф http://www.jscc.ru/.
Кудрявцев Андрей
Александрович студент бакалавриата факультета информационных технологий Новосибирского национального исследовательского государственного университета; e-mail: a.kudryavtscv2@g.nsu.ru. Область научных ин-
тересов: параллельные алгоритмы, высокопроизводительные вы числения.
Kudryavtsev Andrey Aleksandrovich
is a student of bachelor of the Faculty of Information Technology of Novosibirsk State University; cvniail: a.kudryavtscv2@g. nsu.ru.
Research interests: parallel algorithms, high
performance computing.
Виктор Эммануилович Малышкин получил степень магистра математики в Томском государственном университете (1970), степень доктора технических наук в Новосибирском государственном университете (1993). В настоящее время является заведующим лабораторией синтеза параллельных программ в Институте вычислительной математики и математической геофизики СО РАН. Он также основал и в настоящее время возглавляет кафедру параллельных вычислений в Национальном исследовательском университете Новосибирска. Является одним из организаторов международной конференции РаСТ (Parallel Computing Technologies), проводимых каждый нечетный год в России.
Имеет более 110 публикаций но параллельным и распределенным вычислениям, синтезу параллельных программ, суисркомиыотср-ному программному обеспечению и приложениям, параллельной реализации крупномасштабных численных моделей.
В настоящее время область его интересов включает параллельные вычислительные технологии, языки и системы нараллельного программирования, методы и средства параллельной реализации крупномасштабных численных моделей, технология активных знаний.
Victor Emmanuilovich Malyshkin graduated from Tomsk State University with the master of sciences degree in 1970, defended his candidate dissertation in physical and mathematical sciences in Computing Centre of SB RAS in 1984, and defended his doctoral dissertation in technical sciences in Novosibirsk State University (1993). Currently is head of parallel programs synthesis laboratory in the Institute of computational mathematics and mathematical geophysics SB RAS.
Is also a founder and head of the chair of parallel computing in Novosibirsk State University. Is one of organizers of the PaCT (Parallel Computing Technologies) international conference, being held each odd year in Russia. Has more than 110 publications on parallel and distributed computing, parallel
programs synthesis, supercomputing software and applications, parallel implementation of large-scale numerical models. Current scientific interests include parallel computing technologies, languages and systems of parallel computing, methods and tools of software implementation of large-scale numerical models, the active knowledge technology.
Нуштаев Юрий Юрьевич Студент 4-го курса бакалавриата но направлению «Информатика и вычислительная техника» Новосибирского шсударственного университета. Область интересов: фрагментированное программирование, система LuNA Почта: у,nushtaev@g.nsu.ru. Телефон: 89529454298.
Перепелкин Владислав Александрович научный сотрудник Института вычислительной математики и математической геофизики СО РАН; старший преподаватель каф. параллельных вычислений факультета информационных технологий Новосибирского национального исследовательского государственного университета. Тел.: (383) 33089-94, e-mail: perepelkin@ssd.sscc.ru.
В 2008 году окончил Новосибирский государственный университет е присуждением степени магистра техники и технологии но направлению «Информатика и вычислительная техника». Имеет более 20 опубликованных статей но теме автоматизации конструирования параллельных программ в области численного моделирования. Является одним из основных разработчиков экспериментальной системы автоматизации конструирования численных параллельных программ для мультикомньютеров LuNA (от Language for Numerical Algorithms). Область профессиональных интересов включает автоматизацию конструирования параллельных программ, языки и системы параллельного программирования, высокопроизводительные вычисления.
Perepelkin Vladislav Aleksandrovich.
Graduated from Novosibirsk State University
in 2008 with the master degree in engineering and technology in computer science. Nowadays has the research position at the Institute of Computational Mathematics and Mathematical Geophysics (Siberian Branch of Russian Academy of Sciences), and also has a part time senior professor position in the Novosibirsk State University. He is an author of more than 20 papers on automation of numerical parallel programs construction. He is one of main developers of system LuNA (Language for Numerical Algorithms) for automatic construction of numerical parallel programs. Professional interests include automation of parallel programs construction, languages and systems of parallel programming, high performance computing.
Спирин Виталий Андреевич студент бакалавриата факультета информационных технологий Новосибирского национального исследовательского государственного университета; e-mail: vaspirinOl® gmail. com. Область научных интересов: параллельные алгоритмы, высокопроизводительные вычисления.
Spirin Vitaly Andreevich is a student of bachelor of the Faculty of Information Technology of Novosibirsk State University; email: vaspirinOlSgmail. com. Research interests: parallel algorithms, high performance computing.
Дата поступления 01.04.2023
