commit 73dfeff75d34cb125ec7e9e3e4297387bd7dc4ac
parent 622557cdfbb2e8dc6344f52543365d417adf77be
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Fri, 3 Nov 2017 10:14:09 +0300
Edit kernels.
Diffstat:
2 files changed, 59 insertions(+), 74 deletions(-)
diff --git a/arma-thesis-ru.org b/arma-thesis-ru.org
@@ -2503,39 +2503,6 @@ IP-адрес, передавая, сколько узлов уже связан
связанных сущностей\nbsp{}--- это /управляющие обеъкты/ (или /объекты/ для
краткости) и /конвейеры/,\nbsp{}--- которые составляют основу программы.
-**** Программная реализация.
-Из соображений эффективности конвейер объектов и методы обеспечения
-отказоустойчивости (которые будут описаны далее) были реализованы во фреймворке
-на языке C++: с точки зрения автора язык C слишком низкоуровневый для написания
-распределенных программ, а использование языка Java влечет за собой накладные
-расходы, и не популярно в высокопроизводительных вычислениях. На данный момент
-фреймворк запускает сервис и приложение в одном процессе. Фреймворк называется
-"Фабрика" и находится на этапе проверки концепции.
-
-**** Обзор вычислительной модели.
-Ключевой особенностью, которая отсутствует в текущих технологиях параллельного
-программирования, является возможность указать иерархических зависимостей между
-параллельными задачами. Когда такая зависимость есть, определить, какая из задач
-должна быть ответственна за повторное выполнение не удавшейся задачи на одном из
-выживших узлов, тривиально. Чтобы повторно выполнить задачу на вершине иерархии,
-создается резервная задача, выполняющаяся на другом узле. Существует ряд систем,
-которые способны выполнять направленные ациклические графы задач
-параллельно\nbsp{}cite:acun2014charmpp,islam2012oozie, но графы не подходят для
-определения отношений руководитель-подчиненный между задачами, поскольку узел
-графа может иметь несколько родительских узлов.
-
-Основное назначение модели состоит в упрощении разработки распределенных
-приложений для пакетной обработки данных и промежуточного программного
-обеспечения. Основное внимание направлено на обеспечение устойчивости приложений
-к поломкам оборудования, т.е. обеспечение отказоустойчивости и высокой
-доступности, которое прозрачно для программиста. Реализация модели состоит из
-двух слоев: на нижнем слое находятся подпрограммы и классы для приложений,
-работающих на одном узле (без сетевых взаимодействий), на верхнем слое\nbsp{}--- для
-приложений, работающих на произвольном количестве узлов. Модель включает в себя
-два вида сильно связанных друг с другом сущностей\nbsp{}--- /управляющие объекты/ (или
-/ядра/) и /конвейеры/,\nbsp{}--- которые используются совместно для написания
-программы.
-
Управляющие объекты реализуют логику (порядок выполнения) программы в методах
~act~ и ~react~ и хранят состояние текущей ветки исполнения. Как логика так и
состояние задаются программистом. В методе ~act~ какая-либо функция либо
@@ -2565,15 +2532,15 @@ IP-адрес, передавая, сколько узлов уже связан
По принципу работу механизм управляющих объектов и конвейеров напоминает
механизм работы процедур и стеков вызовов, с тем лишь преимуществом, что методы
объектов вызываются асинхронно и параллельно друг другу (насколько это позволяет
-логика программы). Поля управляющего объекта\nbsp{}--- это локальные переменные стека,
-метод ~act~\nbsp{}--- это последовательность процессорных инструкций перед вложенным
-вызовом процедуры, а метод ~react~\nbsp{}--- это последовательность инструкций после
-вложенного вызова. Создание и отправка на конвейер подчиненного объекта\nbsp{}--- это
-вложенный вызов процедуры. Наличие двух методов обуславливается асинхронностью
-вложенных вызовов и помогает заменить активное ожидание завершения подчиненных
-объектов пассивным при помощи конвейеров. Конвейеры, в свою очередь, позволяют
-реализовать пассивное ожидание и вызывают правильные методы, анализируя
-внутреннее состояние объектов.
+логика программы). Поля управляющего объекта\nbsp{}--- это локальные переменные
+стека, метод ~act~\nbsp{}--- это последовательность процессорных инструкций
+перед вложенным вызовом процедуры, а метод ~react~\nbsp{}--- это
+последовательность инструкций после вложенного вызова. Создание и отправка на
+конвейер подчиненного объекта\nbsp{}--- это вложенный вызов процедуры. Наличие
+двух методов обуславливается асинхронностью вложенных вызовов и помогает
+заменить активное ожидание завершения подчиненных объектов пассивным при помощи
+конвейеров. Конвейеры, в свою очередь, позволяют реализовать пассивное ожидание
+и вызывают правильные методы, анализируя внутреннее состояние объектов.
#+name: fig-subord-ppl
#+begin_src dot :exports results :file build/subord-ppl-ru.pdf
@@ -2685,7 +2652,16 @@ graph G {
#+label: fig-subord-ppl
#+RESULTS: fig-subord-ppl
[[file:build/subord-ppl-ru.pdf]]
-**** Основополагающие принципы модели.
+
+**** Программная реализация.
+Из соображений эффективности конвейер объектов и методы обеспечения
+отказоустойчивости (которые будут описаны далее) были реализованы во фреймворке
+на языке C++: с точки зрения автора язык C слишком низкоуровневый для написания
+распределенных программ, а использование языка Java влечет за собой накладные
+расходы, и не популярно в высокопроизводительных вычислениях. Фреймворк
+называется Bscheduler и находится на этапе проверки концепции.
+
+**** Основополагающие принципы модели. :noexport:
Модель конвейера обработки данных строится по следующим принципам, следование
которым обеспечивает максимальную эффективность программы.
- В модели отсутствует понятие сообщения, роль сообщения выполняет сам
@@ -2793,16 +2769,27 @@ downstream-объектов метод ~react~ их родителя вызыв
Не существует способа предоставить мелкозернистую отказоустойчивость к сбоям
узлов кластера, если в программе присутствуют downstream-объекты кроме тех, что
возвращаются к своим родителям. Вместо этого, код завершения управляющего
-объекта проверяется и пользовательский код для восстановления выполняется. Если
-проверки на ошибку не выполняется, система перезапускает выполнение, начиная с
-первого родительского объекта, который не создавал downstream-объектов. Это
-означает, что если решаемая программой задача имеет информационные зависимости
-между частями вычисляемыми параллельно, и узел выходит из строя во время
-вычисления этих частей, то эти вычисления перезапускается с самого начала,
-отбрасывая части, вычисленные ранее. Такого не происходит в высоко параллельных
-программах, где параллельные части не имеют таких информационных зависимостей
-между друг другом: в этом случае только части с вышедших из строя узлов
-вычисляются заново, а все ранее вычисленные части сохраняются.
+объекта проверяется и пользовательская подпрограмма для восстановления
+выполняется. Если проверки на ошибку не выполняется, система перезапускает
+выполнение, начиная с первого родительского объекта, который не создавал
+downstream-объектов. Это означает, что если решаемая программой задача имеет
+информационные зависимости между частями вычисляемыми параллельно, и узел
+выходит из строя во время вычисления этих частей, то эти вычисления
+перезапускается с самого начала, отбрасывая части, вычисленные ранее. Такого не
+происходит в высоко параллельных программах, где параллельные части не имеют
+таких информационных зависимостей между друг другом: в этом случае только части
+с вышедших из строя узлов вычисляются заново, а все ранее вычисленные части
+сохраняются.
+
+В отличие от функции ~main~ программ, основанных на библиотеке MPI, первый
+(главный) управляющий объект изначально запускается только на одном узле, а
+другие узлы кластеры используются при необходимости. Это позволяет использовать
+больше узлов для участков кода с большой степенью параллелизма, и меньше для
+других участков. Похожий подход применятся во фреймворках для обработки больших
+объемов данных\nbsp{}cite:dean2008mapreduce,vavilapalli2013yarn --- узлы, на
+которых будет выполняться задача выбираются в зависимости от того, где физически
+находятся входные файлы.
+
**** Отображение алгоритма генерации взволнованной поверхности на архитектуру системы.
Модель АРСС реализована в программном комплексе, работающем по принципу
вычислительного конвейера, в котором каждое звено применяет некоторую функцию к
diff --git a/arma-thesis.org b/arma-thesis.org
@@ -2502,9 +2502,8 @@ graph G {
For efficiency reasons object pipeline and fault tolerance techniques (which
will be described later) are implemented in the C++ framework: From the author's
perspective C language is deemed low-level for distributed programmes, and Java
-incurs too much overhead and is not popular in HPC community. As of now, the
-framework runs in the same process as an parallel application that uses it. The
-framework is called Bscheduler, it is now in proof-of-concept development stage.
+incurs too much overhead and is not popular in HPC community. The framework is
+called Bscheduler, it is now in proof-of-concept development stage.
**** Application programming interface.
Each kernel has four types of fields (listed in table\nbsp{}[[tab-kernel-fields]]):
@@ -2555,24 +2554,23 @@ make it possible for a parent to collect the result of the execution.
There is no way to provide fine-grained resilience to cluster node failures, if
there are downstream kernels in the programme, except the ones returning to
-their parents. Instead, an exit code of the kernel is checked and a custom
-recovery code is executed. If there is no error checking, the system restarts
-execution from the first parent kernel, which did not produce any downstream
-kernels. This means, that if a problem being solved by the programme has
-information dependencies between parts that are computed in parallel, and a node
-failure occurs during computation of these parts, then this computation is
-restarted from the very beginning, discarding any already computed parts. This
-does not occur for embarrassingly parallel programmes, where parallel parts do
-not have such information dependencies between each other: in this case only
-parts from failed nodes are recomputed and all previously computed parts are
-retained.
-
-Unlike ~main~ function in programmes based on message passing library, the first
-(the main) kernel is initially run only on one node, and remote nodes are used
-on-demand. This design choice allows to have arbitrary number of nodes throughout
-execution of a programme, and use more nodes for highly parallel parts of the
-code. Similar choice is made in the design of big data
-frameworks\nbsp{}cite:dean2008mapreduce,vavilapalli2013yarn \nbsp{}--- a user
+their parents. Instead, an exit code of the kernel is checked and a
+user-provided recovery subroutine is executed. If there is no error checking,
+the system restarts execution from the first parent kernel, which did not
+produce any downstream kernels. This means, that if a problem being solved by
+the programme has information dependencies between parts that are computed in
+parallel, and a node failure occurs during computation of these parts, then this
+computation is restarted from the very beginning, discarding any already
+computed parts. This does not occur for embarrassingly parallel programmes,
+where parallel parts do not have such information dependencies between each
+other: in this case only parts from failed nodes are recomputed and all
+previously computed parts are retained.
+
+Unlike ~main~ function in programmes based on MPI library, the first (the main)
+kernel is initially run only on one node, and other cluster nodes are used
+on-demand. This allows to use more nodes for highly parallel parts of the code,
+and less nodes for other parts. Similar choice is made in the design of big data
+frameworks\nbsp{}cite:dean2008mapreduce,vavilapalli2013yarn --- a user
submitting a job does not specify the number of hosts to run its job on, and
actual hosts are the hosts where input files are located.
