commit c290b82246a08e504c1fd90f62518dc0ef25f39e
parent d6422fa977574dc0f124fe92c061691ff08fd616
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Tue, 7 Nov 2017 20:32:26 +0300
Edit.
Diffstat:
| arma-thesis-ru.org | | | 91 | ++++++++++++++++++++++++++++++++++++++++--------------------------------------- |
| arma-thesis.org | | | 45 | ++++++++++++++++++++++++--------------------- |
2 files changed, 70 insertions(+), 66 deletions(-)
diff --git a/arma-thesis-ru.org b/arma-thesis-ru.org
@@ -2097,6 +2097,7 @@ arma.print_openmp_vs_opencl(model_names, row_names)
**** Производительность ввода-вывода.
:PROPERTIES:
:header-args:R: :results output raw :exports results
+:CUSTOM_ID: sec-io-perf
:END:
Несмотря на то что в тестах из предыдущего раздела запись данных в файлы не
@@ -2352,11 +2353,11 @@ OpenGL увеличивает производительность путем и
отправить сетевой пакет между любой парой узлов кластера.
**** Уровень резидентных процессов.
-Состоит из процессов, находящихся на узлах кластера и иерархических логических
+Состоит из процессов, запущенных на узлах кластера и иерархических логических
связей (главный/подчиненный) между ними. На каждом узле запущен ровно один
процесс, поэтому эти понятия взаимозаменяемы в данной работе. Роль главного и
подчиненного назначается резидентным процессам динамически, т.е.\nbsp{}любой
-физический узел может стать главным или подчиненным, или быть и тем и другим
+физический узел может стать главным или подчиненным, или быть и тем, и другим
одновременно. Динамический выбор ролей использует алгоритм выбора лидера, не
требующий периодической отправки широковещательных сообщений всем узлам
кластера, вместо этого роль определяется IP-адресом узла. Подробное описание
@@ -2367,19 +2368,18 @@ OpenGL увеличивает производительность путем и
иерархии, от его IP-адреса, что делает его непригодным для виртуальных сред, где
IP-адрес узла может динамически меняться.
-Единственным предназначением древовидной иерархии состоит в балансировке
-нагрузки между узлами кластера. Нагрузка распределяется от текущего узла к его
-соседям в иерархии путем простой итерации по ним. Когда в иерархии появляются
-новые связи или меняются старые (из-за того что новый узел присоединяется к
-кластеру или работающий узел выходит из строя), резидентные процессы
-обмениваются сообщениями, передавая друг другу количеством узлов, находящихся
-/за/ соответствующей связью в иерархии. Эта информация используется для
-равномерного распределения нагрузки, даже если распределенная программа
-запускается на подчиненном узле. Кроме того, иерархия уменьшает количество
-одновременных сетевых соединений между узлами: на каждую связь в иерархии
-устанавливается и поддерживается только одно соединение\nbsp{}--- что уменьшает
-вероятность возникновения перегрузки сети при большом количестве узлов в
-кластере.
+Единственное предназначение древовидной иерархии состоит в балансировке нагрузки
+между узлами кластера. Нагрузка распределяется от текущего узла к его соседям в
+иерархии путем простой итерации по ним. Когда в иерархии появляются новые связи
+или меняются старые (из-за того что новый узел присоединяется к кластеру или
+работающий узел выходит из строя), резидентные процессы обмениваются
+сообщениями, передавая друг другу количество узлов, находящихся /за/
+соответствующей связью в иерархии. Эта информация используется для равномерного
+распределения нагрузки, даже если распределенная программа запускается на
+подчиненном узле. Кроме того, иерархия уменьшает количество одновременных
+сетевых соединений между узлами: на каждую связь в иерархии устанавливается и
+поддерживается только одно соединение\nbsp{}--- что уменьшает вероятность
+возникновения перегрузки сети при большом количестве узлов в кластере.
Балансировка нагрузки реализована следующим образом. Когда узел \(A\) пытается
стать подчиненным узлу \(B\), он отправляет сообщение на соответствующий
@@ -2393,10 +2393,10 @@ IP-адрес, передавая, сколько узлов уже связан
узлами он вычитает количество узлов за главным, чтобы получить правильную сумму.
Для распределения управляющих объектов (см.\nbsp{}разд.\nbsp{}[[#sec-kernel-layer]])
между узлами используется циклический алгоритм (round-robin),
-т.е.\nbsp{}производится итерации по всем связям текущего узла, включая связь с
+т.е.\nbsp{}производится итерация по всем связям текущего узла, включая связь с
главным узлом, и, принимая во внимание количество узлов, находящихся за каждой
из связей. Таким образом, даже если программа запускается на подчиненном узле,
-находящимися внизу иерархии, ее управляющие объекты распределяются равномерно
+находящимся внизу иерархии, ее управляющие объекты распределяются равномерно
между всеми узлами кластера.
Предложенный подход может быть расширен, включив сложную логику в алгоритм
@@ -2427,7 +2427,7 @@ IP-адрес, передавая, сколько узлов уже связан
между параллельно выполняющимися задачами. Когда такая зависимость есть,
руководящая задача становится ответственной за перезапуск подчиненной,
завершившейся неудачно, на оставшихся узлах кластера. Для того чтобы иметь
-возможность перезапустить задачу, у которой нету задачи, главенствующей над ней,
+возможность перезапустить задачу, у которой нету главенствующей над ней задачи,
создается копия, и отправляется на другой узел
(см.\nbsp{}разд.\nbsp{}[[#sec-fail-over]]). Существует несколько систем, которые
способны выполнять направленные ациклические графы задач
@@ -2437,17 +2437,17 @@ IP-адрес, передавая, сколько узлов уже связан
руководящих узлов.
Основное назначение предлагаемого подхода состоит в упрощении разработки
-распределенных приложений для пакетной обработки и промежуточного программного
-обеспечения, а идея состоит в обеспечении отказоустойчивости на самом низком из
-возможных уровней. Реализация разделена на два слоя: нижний слой состоит из
-подпрограмм и классов для приложений, работающих на одном узле (без
+распределенных приложений, работающих в пакетном режиме, и промежуточного
+программного обеспечения, а идея состоит в обеспечении отказоустойчивости на
+самом низком из возможных уровней. Реализация разделена на два слоя: нижний слой
+состоит из подпрограмм и классов для приложений, работающих на одном узле (без
взаимодействия по сети), а верхний слой предназначен для приложений, работающих
на произвольном количестве узлов. Предполагается наличие двух типов сильно
связанных сущностей\nbsp{}--- это /управляющие объекты/ (или /объекты/ для
краткости) и /конвейеры/,\nbsp{}--- которые составляют основу программы.
Управляющие объекты реализуют логику (порядок выполнения) программы в методах
-~act~ и ~react~ и хранят состояние текущей ветки исполнения. Как логика так и
+~act~ и ~react~ и хранят состояние текущей ветки исполнения. Как логика, так и
состояние задаются программистом. В методе ~act~ какая-либо функция либо
вычисляется непосредственно, либо разлагается на вложенные функции
(представляемые подчиненными управляющими объектами), которые впоследствии
@@ -2462,7 +2462,7 @@ IP-адрес, передавая, сколько узлов уже связан
использоваться разные потоки).
Конвейеры осуществляют асинхронные вызовы методов ~act~ и ~react~, стараясь
-сделать как можно больше вызовов параллельно, учитывая предоставляемый
+сделать как можно больше вызовов одновременно, учитывая предоставляемый
платформой параллелизм (количество процессорных ядер на узле и количество узлов
в кластере). Конвейер включает в себя пул управляющих объектов, содержащий все
подчиненные объекты, отправленные в него родителями, и пул потоков,
@@ -2470,9 +2470,9 @@ IP-адрес, передавая, сколько узлов уже связан
параграфе. Для каждого устройства используется отдельный конвейер. Существуют
конвейеры для параллельной обработки, обработки по расписанию (периодические и
отложенные задачи) и промежуточный конвейер для обработки управляющих объектов
-на узлах кластера (см.\nbsp{}рис.\nbsp{}[[fig-subord-ppl]]).
+на других узлах кластера (см.\nbsp{}рис.\nbsp{}[[fig-subord-ppl]]).
-По принципу работу механизм управляющих объектов и конвейеров напоминает
+По принципу работы механизм управляющих объектов и конвейеров напоминает
механизм работы процедур и стеков вызовов, с тем лишь преимуществом, что методы
объектов вызываются асинхронно и параллельно друг другу (насколько это позволяет
логика программы). Поля управляющего объекта\nbsp{}--- это локальные переменные
@@ -2607,7 +2607,7 @@ graph G {
**** Программный интерфейс.
Каждый управляющий объект имеет четыре типа полей (перечисленных в
табл.\nbsp{}[[tab-kernel-fields]]):
-- поля, относящиеся к управлению потоком исполнения,
+- поля, относящиеся к управлению потоком выполнения,
- поля, определяющие исходное местонахождение управляющего объекта,
- поля, определяющие текущее местонахождение управляющего объекта и
- поля, определяющие целевое местонахождение управляющего объекта.
@@ -2658,9 +2658,9 @@ downstream-объектов метод ~react~ их родителя вызыв
Не существует способа предоставить мелкозернистую отказоустойчивость к сбоям
узлов кластера, если в программе присутствуют downstream-объекты кроме тех, что
-возвращаются к своим родителям. Вместо этого, код завершения управляющего
-объекта проверяется и пользовательская подпрограмма для восстановления
-выполняется. Если проверки на ошибку не выполняется, система перезапускает
+возвращаются к своим родителям. Вместо этого, проверяется код завершения
+управляющего объекта и выполняется пользовательская подпрограмма для
+восстановления. Если проверка на ошибку отсутствует, система перезапускает
выполнение, начиная с первого родительского объекта, который не создавал
downstream-объектов. Это означает, что если решаемая программой задача имеет
информационные зависимости между частями вычисляемыми параллельно, и узел
@@ -2673,7 +2673,7 @@ downstream-объектов. Это означает, что если решае
В отличие от функции ~main~ программ, основанных на библиотеке MPI, первый
(главный) управляющий объект изначально запускается только на одном узле, а
-другие узлы кластеры используются при необходимости. Это позволяет использовать
+другие узлы кластера используются при необходимости. Это позволяет использовать
больше узлов для участков кода с большой степенью параллелизма, и меньше для
других участков. Похожий подход применяется во фреймворках для обработки больших
объемов данных\nbsp{}cite:dean2008mapreduce,vavilapalli2013yarn --- узлы, на
@@ -2681,13 +2681,13 @@ downstream-объектов. Это означает, что если решае
находятся входные файлы.
**** Отображение алгоритма генерации взволнованной поверхности на архитектуру системы.
-Модель АРСС реализована в программном комплексе, работающем по принципу
+Модели АР и СС реализованы в программном комплексе, работающем по принципу
вычислительного конвейера, в котором каждое звено применяет некоторую функцию к
выходным данным предыдущего звена. Звенья конвейера распределяются по узлам
вычислительного кластера, чтобы сделать возможным параллелизм по операциям, а
затем данные, перемещающиеся между звеньями конвейера распределяются между
ядрами процессора, чтобы сделать возможным параллелизм по данным. На
-рис.\nbsp{}[[fig-pipeline]] представлена схема конвейера обработки данных, в которой
+рис.\nbsp{}[[fig-pipeline]] представлена схема такого конвейера. Здесь
прямоугольниками со скругленными углами обозначены звенья конвейера, обычными
прямоугольниками\nbsp{}--- массивы объектов из предметной области задачи,
передаваемые от одного звена к другому, а стрелками\nbsp{}--- направление
@@ -2698,10 +2698,10 @@ downstream-объектов. Это означает, что если решае
готовности. Секции работают параллельно на нескольких ядрах процессора
(нескольких узлах кластера). Таким образом, между множеством ядер процессора,
секций звеньев конвейера и объектами устанавливается сюръективное отображение,
-т.е. на одном ядре процессора может работать несколько секций звеньев конвейера,
-каждая из которых может обрабатывать несколько объектов последовательно, но одна
-секция не может работать сразу на нескольких ядрах, а объект не может
-обрабатываться сразу несколькими секциями конвейера.
+т.е.\nbsp{}на одном ядре процессора может работать несколько секций звеньев
+конвейера, каждая из которых может обрабатывать несколько объектов
+последовательно, но одна секция не может работать сразу на нескольких ядрах, а
+объект не может обрабатываться сразу несколькими секциями конвейера.
#+name: fig-pipeline
#+begin_src dot :exports results :file build/pipeline-ru.pdf
@@ -2820,9 +2820,10 @@ Parallel)\nbsp{}cite:valiant1990bridging, применяемой в систем
Конвейер объектов ускоряет программу путем параллельного выполнения блоков кода,
работающих с разными вычислительными устройствами: в то время как текущая часть
взволнованной поверхности генерируется на процессоре, предыдущая часть
-записывается на диск. Такой подход позволяет получить ускорение, потому что
-различные вычислительные устройства работают асинхронно, и их параллельное
-использование увеличивает производительность программы.
+записывается на диск. Такой подход позволяет получить ускорение
+(см.\nbsp{}разд.\nbsp{}[[#sec-io-perf]]), потому что различные вычислительные
+устройства работают асинхронно, и их параллельное использование увеличивает
+производительность программы.
Поскольку передача данных между звеньями конвейера происходит параллельно с
вычислениями, то на одном и том же конвейере можно запустить сразу несколько
@@ -2840,11 +2841,11 @@ Parallel)\nbsp{}cite:valiant1990bridging, применяемой в систем
Конвейеризация шагов программы, которые в противном случае последовательны,
выгодно не только для кода, работающего с различными устройствами, но и для
кода, различные ветки которого могут быть запущены на нескольких аппаратных
-потоках одного процессорного ядра, т.е. ветки, осуществляющие доступ к различным
-блокам памяти или использующие смешанную арифметику (целочисленную и с плавающей
-точкой). Ветки кода, которые используют различные модули процессора, являются
-хорошими кандидатами для параллельного запуска на процессорном ядре с
-несколькими аппаратными потоками.
+потоках одного процессорного ядра, т.е.\nbsp{}ветки, осуществляющие доступ к
+различным блокам памяти или использующие смешанную арифметику (целочисленную и с
+плавающей точкой). Ветки кода, которые используют различные модули процессора,
+являются подходящими кандидатами для параллельного запуска на процессорном ядре
+с несколькими аппаратными потоками.
Таким образом, вычислительную модель на основе конвейера можно рассматривать как
/массивно асинхронную модель/ (bulk-asynchronous model) из-за параллельной
diff --git a/arma-thesis.org b/arma-thesis.org
@@ -2045,6 +2045,7 @@ need to be computed.
**** I/O performance.
:PROPERTIES:
:header-args:R: :results output raw :exports results
+:CUSTOM_ID: sec-io-perf
:END:
Although, in the benchmarks from the previous section writing data to files does
@@ -2291,7 +2292,7 @@ network connectivity, i.e.\nbsp{}an ability to send network packet between any
pair of cluster nodes.
**** Daemon process layer.
-Consists of daemon processes residing on cluster nodes and hierarchical
+Consists of daemon processes running on cluster nodes and hierarchical
(master/slave) logical links between them. Only one daemon process is launched
per node, so these terms are use interchangeably in this work. Master and slave
roles are dynamically assigned to daemon processes, i.e.\nbsp{}any physical
@@ -2600,24 +2601,25 @@ 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.
**** Wavy surface generation algorithm mapping on system architecture.
-Software implementation of ARMA model works as a computational pipeline, in
-which each joint applies some function to the output coming from the pipe of the
-previous joint. Joints are distributed across computer cluster nodes to enable
-function parallelism, and then data flowing through the joints is distributed
-across processor cores to enable data parallelism. Figure\nbsp{}[[fig-pipeline]]
-shows a diagram of data processing pipeline in which rectangles with rounded
-corners denote joints, regular rectangles denote arrays of problem domain
-objects flowing from one joint to another, and arrows show flow direction. Some
-joints are divided into /sections/ each of which process a separate part of the
-array. If joints are connected without a /barrier/ (horizontal or vertical bar),
-then transfer of separate objects between them is done in parallel to
-computations, as they become available. Sections work in parallel on each
-processor core (or node of the cluster). There is surjective mapping between a
-set of processor cores, a set of pipeline joint sections and objects, i.e. each
-processor core may run several sections, each of which may sequentially process
-several objects, but a section can not work simultaneously on several processor
-cores, and an object can not be processed simultaneously by several sections.
-So, the programme is a pipeline through which control objects flow.
+Software implementation of AR and MA models works as a computational pipeline,
+in which each joint applies some function to the output coming from the pipe of
+the previous joint. Joints are distributed across computer cluster nodes to
+enable function parallelism, and then data flowing through the joints is
+distributed across processor cores to enable data parallelism.
+Figure\nbsp{}[[fig-pipeline]] shows a diagram of such pipeline. Here rectangles with
+rounded corners denote joints, regular rectangles denote arrays of problem
+domain objects flowing from one joint to another, and arrows show flow
+direction. Some joints are divided into /sections/ each of which process a
+separate part of the array. If joints are connected without a /barrier/
+(horizontal or vertical bar), then transfer of separate objects between them is
+done in parallel to computations, as they become available. Sections work in
+parallel on each processor core (or node of the cluster). There is surjective
+mapping between a set of processor cores, a set of pipeline joint sections and
+objects, i.e.\nbsp{}each processor core may run several sections, each of which
+may sequentially process several objects, but a section can not work
+simultaneously on several processor cores, and an object can not be processed
+simultaneously by several sections. So, the programme is a pipeline through
+which control objects flow.
#+name: fig-pipeline
#+begin_src dot :exports results :file build/pipeline.pdf
@@ -2736,8 +2738,9 @@ model global synchronisation occurs after each step.
Object pipeline speeds up the programme by parallel execution of code blocks
that work with different compute devices: while the current part of wavy surface
is generated by a processor, the previous part is written to a disk. This
-approach allows to get speed-up because compute devices operate asynchronously,
-and their parallel usage increases the whole programme performance.
+approach allows to get speed-up (see\nbsp{}sec.\nbsp{}[[#sec-io-perf]]) because
+compute devices operate asynchronously, and their parallel usage increases the
+whole programme performance.
Since data transfer between pipeline joints is done in parallel to computations,
the same pipeline may be used to run several copies of the application but with
