Преимущества применения dataflow-парадигмы в вычислительных системах
Анализ существующих решений в области dataflow-ВС. Выбор и обоснование критериев оценки и параметров моделируемой системы. Бенчмарк GREP – алгоритм сопоставления файловых строк шаблонам команды. Тестовые прогоны на модели ОА-архитектуры dataflow-ВС.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | диссертация |
| Язык | русский |
| Дата добавления | 02.04.2016 |
| Размер файла | 3,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
NewFU={Mnemo="Scheduler" FUType=FUScheduler}
Scheduler.ContextPopMk=MainBus.SchedulerContextSet \\ Настройка ссылки на балансир (планировщик)
NewFU={Mnemo="Eventser" FUType=FUEventser}
NewFU={Mnemo="GraphGen" FUType=FUGraph500Manager}
NewFU={Mnemo="GraphCollector" FUType=FUGraph500Collector}
NewFU={Mnemo="Chart" FUType=FUChart}
NewFU={Mnemo="Plot" FUType=FUPlot}
\\ Настройка рисования графика
Plot.SeriaCreat
Chart.ParentSet
Chart.Caption="Parallel factor"
Chart.Focus
Plot.SeriaCreat
Chart.ChartPopMk=Plot.ParentSet
Plot.ColorSet=clRed
Plot.PenWidthSet=3
Chart.TitleYSet="Parallel factor"
Chart.TitleXSet="Model time"
Chart.TitleSet="Graph500 parallel factor"
Scheduler.SheduleTimeSet=0
\\ Подпрограмма вывода параметра в окно графика
Eventser.OutProgSet={Eventser.CurrentTimePopMk=Plot.XSet Eventser.CurrentParallelFactorPopMk=Plot.YSet}
Eventser.CurrentTimePointPopMk=Scheduler.TimePointerSet
Eventser.ContextPopMk=Scheduler.EventserContextSet
\\ Настройка Eventser-а
Scheduler.NCoresSet=30
Eventser.NEUSet=30
\\ Настройка ФУ вычислительного поля для теста Graph500
GraphGen.ContextPopMk=GraphCollector.GraphGenSet
GraphGen.ScaleSet=10
GraphGen.EdgeFactorSet=16
GraphGen.FUFieldRangeSet=7
\\ Перевод ФУ в режим моделирования
GraphGen.ManualModeSet=true
GraphCollector.ManualModeSet=true
\\ Запуск теста
GraphGen.Run=64
Console.Out="Средняя длина пути в графе: "
GraphCollector.TraceLongPopMk=Console.Out
Eventser.Start
\\ Вывод результатов моделирования
Console.LnOut="Process time: " Eventser.CurrentTimePointPopMk=Console.OutLn
Console.LnOut="Parallel dipertion: "Eventser.DispParallelFactorPopMk=Console.Out
Console.LnOut="Evens count: "Eventser.EventsCountPopMk=Console.Out
Console.LnOut="Use factor: " Eventser.UseFactorPopMk=Console.Out
Листинг 4. Реализация теста бенчмарка Graph500 на ПЯ
3.3 Бенчмарк GREP - алгоритм сопоставления файловых строк шаблонам команды
Grep - хорошо известная утилита командной строки различных операционных систем. С её помощью можно производить поиск по тексту строк, соответствующих некоторому заданному регулярному выражению.
Для проведения моделирования работы команды GREP необходим следующий набор функциональных устройств:
· String Sourсe
· Regexp Manager
· Regexp Worker
· Regexp Collector
· String Receiver
Структура виртуальной вычислительной системы ОА-архитектуры для реализации бенчмарка GREP приведена на рис. 70.
ФУ для реализации бенчмарка команды GREP
В Таблица 20 собран набор милликоманд ФУ, предназначенных для прогона тестового приложения бенчмарка команды GREP (алгоритма сопоставления файловых строк шаблонам команды GREP) на модели суперкомпьютерной системы ОА-архитектуры.
Рисунок 15 - Структура вычислительной системы для моделирования GREP
Таблица 3 - Милликоманды устройства вычислений бенчмарка команды GREP
|
Индекс милликоманды |
Мнемоника милликоманды |
Описание |
|
|
0 |
Reset |
Сброс ФУ |
|
|
20 |
PatternSet |
Установка поискового шаблона (регулярное выражение) |
|
|
21 |
StringSet |
Установка входной строки для поиска |
|
|
22 |
PatternSetStart |
Установка поискового шаблона (регулярное выражение), затем запуск поиска |
|
|
23 |
StringSetStart |
Установка входной строки для поиска, затем запуск поиска |
|
|
25 |
ResultMkSet |
Установка милликоманды для отправки результата (первого найденного вхождения) |
|
|
26 |
ResultMatrMkSet |
Установка милликоманды для отправки результата в формате массива/матрицы (все внайденные вхождения) |
|
|
27 |
ResultMatrPop |
Выполнить милликоманду отправки результата в формате массива/матрицы |
|
|
28 |
ResultMatrPopMk |
Установить и выполнить милликоманду отправки результата в формате массива/матрицы |
|
|
29 |
ResultProgSet |
Установить миллипрограмму для отправки результата |
|
|
30 |
Start |
Запуск поиска |
|
|
41 |
IndexOffsetSet |
Установка стартового значения индекса при индексации входных строк. Используется в качестве милликоманды при приеме входной строки. (по умолчанию - 1000) |
|
|
42 |
ResultFUContextSet |
Установка контекста ФУ, которое будет принимать результаты поиска |
Предварительная настройка функциональных устройств
ФУ String Source. Данное функциональное устройство является поставщиком входных данных в программу моделирования программы GREP. Устройство производит построчное чтение некоторого заданного текстового файла и пересылка данных (строк) следующему функциональному устройству. Ниже приведен пример программы:
NewFU={Mnemo="StringSource" FUType=FUStringsSource}
…
StringSource.FileSet="eug3.txt"
StringSource.MkSet=RegManager.StringPut
Листинг 5. Пример вызова ФУ StringSource
ФУ Regexp Worker. Для проведения моделирования необходимо создать всего одно ФУ Regexp и провести его настройку. В качестве входных данных устройство принимает строку для поиска, а также поисковый шаблон, построенный по правилам регулярного выражения. После получения этих входных данных устройство произведет поиск искомой строки по шаблону и сформирует массив вхождений. Этот массив ФУ прикрепит в качестве нагрузки ко входной милликоманде и перенаправит её на контекст устройства, определенного в переменной контекста ResultFUContextSet.
После настройки данного ФУ Regexp Manager произведет его «клонирование», т.е. система будет состоять из нескольких одинаково настроенных ФУ Regexp Worker, что обеспечит распараллеливание решаемой задачи. Ниже представлен пример программы:
NewFU={Mnemo="Reg" FUType=FURegexp}
…
Reg.PatternSet="[A-Za-z]+"
Reg.ContextPopMk=RegManager.RegexpFUSet
Листинг 6. Пример вызова ФУ RegexpWorker
ФУ Regexp Manager. Данное устройство выполняет функции инициализации «рабочих» ФУ Regexp Worker, а также функции распредения входных данных (строк) между ФУ Regexp. Перед запуском данного устройства необходимо сначала настроить одно ФУ Regexp, а затем передать ссылку на его контекст устройству Regexp Manager через милликоманду RegexpFUSet. Необходимо также определить количество «клонированных» устройств через милликоманду CountSet. Данная милликоманда не только определит переменную контекста Count, но и создаст и проинициализирует устройства ФУ Regexp, используя предустановленный в переменной RegexpFU контекст оригинального устройства-обработчика. За приём входной строки отвечает милликоманда StringPut (входная строка в нагрузке). После получения всех необходимых данных устройство начинает слать милликоманды (начиная с 1000), номера которых соответствуют индексам входных строк, увеличенных на тысячу (+1000). Т.е., первая строка будет передана некоторому устройству Regexp Worker милликомандой 1000, вторая - 1001, третья - 1002 и т.д. Ниже представлен пример программы.
NewFU={Mnemo="RegManager" FUType=FURegexpManager}
…
Reg.ContextPopMk=RegManager.RegexpFUSet
RegManager.Clone=10
StringSource.MkSet=RegManager.StringPut
Листинг 7. Пример вызова ФУ RegexpManager
Для запуска тестовой задачи бенчмарка GREP на вычислительной системе ОА-архитектуры необходимо выполнить следующую миллипрограмму на ПЯ (ОА-языке):
NewFU={Mnemo="Scheduler" FUType=FUScheduler}
Scheduler.ContextPopMk=MainBus.SchedulerContextSet \\ Настройка ссылки на балансир (планировщик)
NewFU={Mnemo="StringSource" FUType=FUStringsSource}
NewFU={Mnemo="RegManager" FUType=FURegexpManager}
NewFU={Mnemo="Reg" FUType=FURegexp}
NewFU={Mnemo="RegCollector" FUType=FURegexpCollector}
NewFU={Mnemo="Eventser" FUType=FUEventser}
NewFU={Mnemo="Chart" FUType=FUChart}
NewFU={Mnemo="Plot" FUType=FUPlot}
\\ Настройка окна вывода графика
Plot.SeriaCreat
Chart.ParentSet
Chart.Caption="Parallel factor"
Chart.Focus
Plot.SeriaCreat
Chart.ChartPopMk=Plot.ParentSet
Plot.ColorSet=clRed
Plot.PenWidthSet=3
Chart.TitleYSet="Parallel factor"
Chart.TitleXSet="Model time"
Chart.TitleSet="Grep parallel factor"
Eventser.OutProgSet={Eventser.CurrentTimePopMk=Plot.XSet Eventser.CurrentParallelFactorPopMk=Plot.YSet}
Eventser.CurrentTimePointPopMk=Scheduler.TimePointerSet
Eventser.ContextPopMk=Scheduler.EventserContextSet
Scheduler.EventserMkSet=1 \\Милликоманда добавления события для Eventser
Scheduler.NCoresSet=9
Eventser.NEUSet=9
\\ Настройка эталонного ФУ Regexp
Reg.PatternSet="(день|ночь|она?|луна|мне|тебе|[0-9]+|[A-Za-z]+)"
Reg.ContextPopMk=RegManager.RegexpFUSet
RegCollector.ContextPopMk=Reg.ResultFUContextSet
\\ Создание вычислительного поля
Reg.ManualModeSet=true
RegManager.Clone=40
StringSource.FileSet="eug2.txt"
StringSource.MkSet=RegManager.StringPut
RegManager.ManualModeSet=true
\\ Настройка времени планирования вычислений
Scheduler.SheduleTimeSet=3000
\\ Запуск теста
StringSource.Start
Eventser.Start
\\ Вывода результатов тестаConsole.Out="Process time: " Eventser.CurrentTimePointPopMk=Console.OutLn
Console.Out="Process time: " Eventser.CurrentTimePointPopMk=Console.OutLn
Console.Out="Parallel factor: " Eventser.ParallelFactorPopMk=Console.OutLn
Console.Out="Use factor: " Eventser.UseFactorPopMk=Console.OutLn
Листинг 8. Реализация теста Regexp по обработке текстовых данных
На ПЯ также могут быть реализованы и миллипрограммы обработки результатов прогона тестовой задачи на ОА-архитектуры для их последующей визуализации и анализа. Например, миллипрограмма определения зависимости времени выполнения теста Grep от числа ФУ и ИУ будет выглядеть следующим образом.
NewFU={Mnemo="Scheduler" FUType=FUScheduler}
Scheduler.ContextPopMk=MainBus.SchedulerContextSet
NewFU={Mnemo="StringSource" FUType=FUStringsSource}
NewFU={Mnemo="RegManager" FUType=FURegexpManager}
NewFU={Mnemo="Reg" FUType=FURegexp}
NewFU={Mnemo="RegCollector" FUType=FURegexpCollector}
NewFU={Mnemo="Eventser" FUType=FUEventser}
NewFU={Mnemo="File" FUType=FUGatewayFile}
NewFU={Mnemo="Matr" FUType=FUConstMatr}
NewFU={Mnemo="GatewayFile" FUType=FUGatewayFile}
NewFU={Mnemo="Counter" FUType=FUCounter}
NewFU={Mnemo="Counter2" FUType=FUCounter}
Eventser.CurrentTimePointPopMk=Scheduler.TimePointerSet
Eventser.ContextPopMk=Scheduler.EventserContextSet
Scheduler.EventserMkSet=1 \\Милликоманда добавления события для Eventser
Scheduler.SheduleTimeSet=30
Reg.PatternSet="(день|ночь|она?|луна|мне|тебе|[0-9]+|[A-Za-z]+)"
Reg.ContextPopMk=RegManager.RegexpFUSet
RegCollector.ContextPopMk=Reg.ResultFUContextSet
Reg.ManualModeSet=true
RegManager.Clone=10
StringSource.FileSet="eug2.txt"
StringSource.MkSet=RegManager.StringPut
RegManager.ManualModeSet=true
\\ Создание матрицы для вывода результатов теста
Matr.RowSet=51 Matr.ColSet=51
Matr.IndexModeSet=0
Matr.Create
Scheduler.SheduleTimeSet=1000
\\ Цикл для сбора результатов
Counter.ValueSet=50
Counter2.ValueSet=50
Counter.LessEqProgSet={
Scheduler.ModelingReset
Eventser.ModelingReset
Counter2.PopMk=Scheduler.NCoresSet
Counter.PopMk=RegManager.Clone
StringSource.Start Eventser.Start
Counter.PopMk=Matr.RowSet Counter2.PopMk=Matr.ColSet
Eventser.CurrentTimePointPopMk=Matr.CellSet
Counter.Inc
}
Counter2.LessEqProgSet={Counter.Set=1 Counter2.Inc}
Counter2.Set=1
\\ Вывод результатов тестирования в файл
GatewayFile.FileNameSet="RegResult.txt"
GatewayFile.SeparatorSet=";"
GatewayFile.OpenFileWrite
Matr.MatrPopMk=GatewayFile.LnOut
GatewayFile.CloseFile
Листинг 9. Реализация теста Regexp по обработке текстовых данных на ПЯ
4. Проведение тестирования
Все проводимые ниже тесты были проведены для получения характеристик производительности моделируемой системы, описанных в разделе №2. Для каждого теста приведены полученные характеристики, а также различные зависимости некоторых выходных параметров от входных. Графики были получены при помощи среды MatLab.
4.1 Тестовые прогоны на модели ОА-архитектуры dataflow-ВС задач расчета напряженности элетростатического поля
Тестовые программы программы на ПЯ для задачи расчета напряженности в точках электростатического поля осуществлялись при изменении различных входных параметров моделируемой системы:
· Размерность матрицы вычислительных узлов (от 2*2 до 40*40 устройств)
· Расположение и числовое значение электрических зарядов на матрице
· Число исполнительных устройств в вычислительной системе
На графиках ниже приведены зависимости числа задействованных ядер от времени выполнения. Размер моделируемой матрицы - 70*70 вычислительных узлов.
Рисунок 16. N=16, T=9611 т.
Рисунок 17. N=40, T=4115 т.
Рисунок 18. N=64, T=2750 т.
Рисунок 19. N=100, T=2691т.
Также, для тестовых задач расчета напряженности была разработана программа для визуализации электростатического поля. Градации серого цвета обозначают значение напряженности (белый - положительное, черный - отрицательный). Стрелки обозначают направление вектора напряженности.
На рисунке ниже приведен скриншот данной программы.
Рисунок 20, 21. Визуализация расчета напряженности электростатического поля
На рисунках ниже приведен расчет выходных характеристик моделируемой вычислительной системы:
· зависимость модельного времени (T) выполнения теста от числа исполнительных ядер и от числа функциональных устройств
· зависимость среднего коэффициента параллелизма (P) от числа исполнительных ядер и от числа функциональных устройств
· зависимость дисперсии среднего коэффициента параллелизма (D) от числа исполнительных ядер и от числа функциональных устройств
· зависимость коэффициента использования аппаратуры (A) от числа исполнительных ядер и от числа функциональных устройств
Рисунок 22. Зависимость времени выполнения (T) от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 23. Зависимость коэффициента параллелизма P от числа исполнительных (Rd) и виртуальных устройств (Fu).
Производительность зависит только от числа функциональных устройств, растет по корню. Закон квадрата оборудования.
Рисунок 24. Зависимость дисперсии (D) среднего коэффициента параллелизма P от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 25. Зависимость коэффициента использования оборудования (A) от числа исполнительных (Rd) и виртуальных устройств (Fu).
4.2 Тестовые прогоны на модели ОА-архитектуры dataflow-ВС задач бенчмарка GRAPH500 на основе алгоритмов решения теоретико-графовых задач
При прогонах тестовой программы, написанной на ПЯ, для алгоритма бенчмарка Graph500, изменялись значения входных параметров, таких как:
· N - число ИУ суперкомпьютерной системы при моделировании;
· 2M - число вершин графа
· K - число вершин графа, которое обрабатывает одно функциональное устройство
На следующих графиках результаты тестовых прогонов задачи бенчмарка Graph500 при различных значениях параметров N, M и K. Графики показывают зависимость коэффициента параллелизма вычислительной системы от времени выполнения теста.
Рисунок 26 - Результаты моделирования теста Graph500 при N = 100 (максимально 57 ИУ задействовано), T = 13102, D = 228,768176408621.
Рисунок 27 - Результаты моделирования теста Graph500 при N = 50, T = 13110, D = 227,085797409818
По результатам моделирования могут быть построены графики зависимости времени выполнения теста и дисперсии от числа ядер в dataflow-ВС (см. Таблица 29 и Рисунок 86).
Таблица 4. Зависимость времени выполнения и дисперсии теста Graph500 от числа ядер
|
N |
T |
D |
|
|
1 |
221747 |
0 |
|
|
2 |
111097 |
0,004007322 |
|
|
5 |
46383 |
0,592867836 |
|
|
10 |
25890 |
7,814802056 |
|
|
15 |
19586 |
27,15531038 |
|
|
20 |
16642 |
58,18736677 |
|
|
30 |
14162 |
135,1538952 |
|
|
40 |
13302 |
200,9084474 |
|
|
50 |
13110 |
227,0857974 |
|
|
100 |
13102 |
228,7681764 |
Рисунок 28, 29 - Время выполнения и дисперсия от числа задействованных в ВП ИУ для теста Graph500
На рисунках ниже приведен расчет выходных характеристик моделируемой вычислительной системы:
· зависимость модельного времени (T) выполнения теста от числа исполнительных ядер и от числа функциональных устройств
· зависимость среднего коэффициента параллелизма (P) от числа исполнительных ядер и от числа функциональных устройств
· зависимость дисперсии среднего коэффициента параллелизма (D) от числа исполнительных ядер и от числа функциональных устройств
· зависимость коэффициента использования аппаратуры (A) от числа исполнительных ядер и от числа функциональных устройств
Рисунок 30. Зависимость времени выполнения (T) от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 31. Зависимость коэффициента параллелизма P от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 32. Зависимость дисперсии (D) среднего коэффициента параллелизма P от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 33. Зависимость коэффициента использования оборудования (A) от числа исполнительных (Rd) и виртуальных устройств (Fu).
Наиболее оптимальное число ядер для данных параметров моделирования - 10-20 шт. По критерию «время исполнения (T)» оптимальное число - 15. По критерию «дисперсия (D)» - 20. После 20 ИУ время выполнения тестового набора Graph500 изменяется незначительно.
4.3 Тестовые прогоны на модели ОА-архитектуры dataflow-ВС задач бенчмарка GREP - алгоритма сопоставления файловых строк шаблонам команды
Ниже представлены результаты моделирования теста Grep на ОА-архитектуре. Моделирование проводилось при следующих параметрах анализируемого текста:
1) Число знаков - 18000;
2) Число строк - 1000.
Рисунок 34. Зависимость времени выполнения (T) от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 35. Зависимость коэффициента параллелизма P от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 36. Зависимость дисперсии (D) среднего коэффициента параллелизма от числа исполнительных (Rd) и виртуальных устройств (Fu).
Рисунок 37. Зависимость коэффициента использования оборудования (A) от числа исполнительных (Rd) и виртуальных устройств (Fu).
4.4 Анализ результатов тестовых прогонов на модели ОА-архитектуры dataflow-ВС
Запуск тестовых приложений на модели суперкомпьютера потребовал разработки индивидуальных способов реализации dataflow-архитектуры вычислительного процесса, настроенной на решение той или иной вычислительной задачи. В результате проведенных исследований было показано, что для максимально полного использования преимуществ dataflow-организации вычислений в параллельной суперкомпьютерной системе необходимо очень тщательно подходить к выбору «номенклатуры» (типов), «зернистости» (количества и размеров) и «качества» (функционального наполнения) ФУ архитектуры ВС. Набор ФУ ОА-архитектуры суперкомпьютерной системы может достаточно существенно различаться от задачи к задаче, что выдвигает на первый план задачу разработки эффективных методов адаптации архитектуры ВС к решению задач различной природы и топологии.
По имеющимся результатам тестов можно сделать вывод, что главным критерием эффективности системы является максимальное использование вычислительного оборудования, а также максимальное количество параллельно работающих устройств.
В задачах, для решения которых используются сеточные методы, анализируемая область разбивается на отдельные элементы, информационно связанные со своими «соседями». В этом случае для реализации вычислительной задачи на dataflow-ВС ОА-архитектуры каждый узел сетки оформляется в виде отдельного ВФУ, которое осуществляет вычисления и обменивается данными с помощью милликоманд со своими «соседями». По проведенным тестам, можно сделать вывод, что коэффициент использования аппаратуры зависит от числа «волн» вычислений. Иными словами, чем меньше устройств участвует в вычислении одной и той же «волны», тем ниже коэффициент использования аппаратуры.
В задачах, основанных на операциях с графами большой размерности мы также можем наблюдать незначительный прирост производительности, при повышении числа исполнительных устройств (ядер). Производительность теста в задаче вычисления наибольшего (или наименьшего) пути в графе сильно зависит от параметров задачи (число вершин, число связей между графами, число функциональных устройв и т.п.).
Наиболее высокие результаты тестирования видны в задаче поиска по тексту большого объёма. Это объясняется тем, что число «мини-задач», т.е. (число поиска вхождений в одной заданной строке) намного превышает число функциональных устройств. Алгоритм данной задачи построен таким образом, что весь объем текстовых данных (все строки) в самом начале работы программы распределяется между функциональными устройствами, таким образом, у каждого устройства сразу создаётся очередь задач на выполнение. При таком распределении время «простоя» некоторого устройства без задачи минимально, что является причиной высокой производительности ВС в данной задаче.
Для обеспечения максимально эффективной работы dataflow-ВС (с точки зрения использования доступных вычислительных ресурсов и достижения высокой степени параллелизма вычислений) требуется ее адаптация к решению конкретной вычислительной задачи, что подразумевает (по возможности автоматическую) подстройку ВП, представленного множеством ВФУ, под возможности имеющейся вычислительной среды. Критериями качества адаптации суперкомпьютерной ОА-системы к выполнению той или иной прикладной задачи может служить максимальный коэффициент использования оборудования.
Методы адаптации ОА-системы делятся на два класса:
- ручные, когда настройка конфигурации ВС и программы осуществляется программистом и инженером перед запуском ВП, включая выбор нужной топологии ВС, распределение сегментов расчетной сетки по вычислительным узлам, подбор оборудования с наиболее оптимальными характеристиками (число процессорных ядер в вычислительном узле, скорость передачи данных коммуникационным оборудованием и т.п.);
- автоматические, когда автоматическая корректировка вычислений (набор, количество и качество ВФУ) осуществляется непосредственно во время ВП.
При запуске и тестировании имитационной модели dataflow-ВС ОА-архитектуры варьировались следующие параметры ВС:
- количество вычислительных узлов в ВС;
- способ разбиения вычислительной сетки на сегменты
- топология вычислительной сети, объединяющей вычислительные узлы;
- скорость передачи данных по линиям связи;
- количество ИУ на вычислительном узле;
- количество ФУ на вычислительном узле.
При экспериментальных исследованиях критериями эффективности и качества работы ВС служил коэффициент использования оборудования (отношение количества задействованных в вычислениях ИУ к общему количеству ИУ), который должен быть максимальным.
Анализ ручной адаптации вычислительного процесса показал что, для достижения максимальной вычислительной эффективности ОА-системы необходимо соблюдение следующих правил по адаптации ВС к вычислительной задаче:
1. Среднее количество виртуальных функциональных устройств, задействованных в вычислениях, должно быть близко к числу ИУ, т.е. ядер системы. При такой конфигурации ВС тратит минимальное время на планирование вычислений, и ей требуется минимальный объем ОП. В том случае, когда NФУ < NИУ, коэффициент использования аппаратуры будет равен KИА NФУ; и при NФУ > NEU коэффициент использования KИА близок к единице, однако с дальнейшим увеличением числа функциональных устройств убывает. При NФУ = NИУ коэффициент использования оборудования KИА достигает своего максимума и примерно равен единице.
2. Пропускная способность канала (каналов) передачи данных должна быть больше поступающего потока данных из вычислительной сетки. В противном случае на ФУ «Шлюз» (ФУ, обеспечивающее передачу данных между вычислительными узлами) будет образовываться очередь из милликоманд, ожидающих передачу на соседний вычислительный узел. Милликоманды, ожидающие отправления, помещаются в буфер Шлюза и ожидают отправления. Зависимость объема буфера передаваемых милликоманд в ситуации, когда пропускная способность канала меньше поступающего из сегмента потока данных, выражается формулой: VMkBuf (VМК *NFUGateway - U)*Nit*Tit, где NFUGateway - число ФУ, передающих данные через Шлюз, VМК - объем памяти, занимаемый одной милликомандой, U - скорость передачи информации по каналу связи, Nit - номер итерации, Tit- время между итерациями (генерациями вычислительных волн).
3. Для задач с использованием сеточных методов средняя скорость прохождения (UCountWave) вычислительной волны должна быть примерно одинаковой во всех вычислительных узлах системы. Скорость прохождения вычислительной волны - это среднее время, за которое вычислительная волна продвигается по сетке на ФУ вперед (рис. 90). В случае, если в сегменте число требуемых для вычисления ФУ меньше или равно числу ИУ в вычислительном узле, данную величину можно вычислить по формуле: UCountWave=(ТWaveEnd - ТWaveStart)/(Lx+Ly), где ТWaveStart и ТWaveEnd - времена начала и конца вычислительной волны в сегменте сетки, Lx и Ly - размерность вычислительной сетки по x и y. В противном случае на данную величину могут влиять следующие факторы: среднее количество задействованных в вычислительной волне ФУ, количество ИУ в вычислительном узле, период генерации вычислительных волн, пропускная способность Шлюзов, осуществляющих передачу сгенерированных в сегменте данных на другие вычислительные узлы, время планировки вычислений (время выделения вычислительного ядра для ФУ). Для выполнения данного требования оператор и инженер, производящий конфигурацию ВС, должны оптимальным образом осуществить разбивку вычислительной сетки на сегменты и их распределение по вычислительным узлам, подобрать коммуникационное и вычислительное оборудование с наиболее подходящими параметрами.
Анализ результатов исследования методов адаптации суперкомпьютерной системы показал эффективность ручных методов адаптации. Также анализ выявил неэффективность автоматического анализа учета трафика (учета номера итерации) передаваемых через ФУ «Шлюз» милликоманд и эффективность учета номера итерации планировшиком (балансиром) во время планирования вычислений (ФУ, принявшее милликоманду с наименьшим номером итерации, помещается в начало очереди ожидания ресурсов) и эффективность метода информирования Шлюзом Топ-менеджера об опасности переполнения буфера передаваемых сообщений. Эффективность последнего способа снижается при увеличении размерности вычислительной сетки.
dataflow вычислительный алгоритм
Выводы
В диссертации были продемонстрированы преимущества применения dataflow-парадигмы в вычислительных системах. Были приведены различные программные реализации этой парадигмы.
ОА-архитектура, описанная в 1-м разделе, полностью реализует dataflow-подход к построению вычислительных систем. Было проведено математическое и имитационное моделирование данной архитектуры. Программной реализацией данной архитектуры является разработанная на кафедре ВСиС МИЭМ ОА-среда программирования и моделирования.
Были определены характеристики для оценки производительности данной архитектуры, а также разработаны тесты для получения этих характеристик. Тесты были реализованы и запущены в ОА-среде.
По результатам выполнения тестов были сделаны выводы о производительности и оптимальной структуре моделируемой ВС.
Список используемой литературы
1. Салибекян С.М., Панфилов П.Б., Моделирование суперкомпьютерной вычислительной системы объектно-атрибутной архитектуры с управлением потоком данных, Москва, 2012
2. Салибекян С.М., Принципы милликомандной архитектуры как основа построения высокопроизводительных адаптивных вычислительных систем // Автоматизация и современные технологии. 2002. № 5
3. Салибекян С.М., Панфилов П.Б. Перспективная суперкомпьютерная система на основе объектно-атрибутной модели вычислений с управлением потоком данных / Международная конференция «Развитие суперкомпьютерных и грид-технологий в России» в рамках «Второго Московский Суперкомпьютерного форума» Россия, Москва, ВВЦ 26-27 октября 2011 года URL: http://www.hpc-platform.ru/tiki-download_file.php?fileId=82
4. Салибекян С.М., Панфилов П.Б ОА-архитектура построения и моделирования распределенных систем автоматизации // Автоматизация в промышленности. N11, 2010
5. Кельтон В., Лоу. А. Имитационное моделирование. Классика CS. 3-е изд. - СПб.: Питер; Киев: Издательская группа BHV, 2004
6. Data flow computing: theory and practice / edited by John A. Sharp. Ablex Publishing Corp. Norwood, NJ, USA,1992.
7. Модель акторов (http://wiki.tza.su/wiki/Модель_акторов)
8. The Scala Language Specification Version 2.7 (http://www-edlab.cs.umass.edu/cs530/ScalaReference.pdf )
9. Арк.В., Климов, Н.Н.Левченко, А.С.Окунев Перспективы использования потоковой модели вычислений для в условиях иерархических коммутационных сред. URL: http://www.hpc-platform.ru/tiki-download_file.php?fileId=90
10. В. С. Бурцев. Выбор новой системы организации выполнения высокопараллельных вычислительных процессов, примеры возможных архитектурных решений построения суперЭВМ. // Сб. В.С. Бурцев Параллелизм вычислительных процессов и развитие архитектуры суперЭВМ М, 1997. (http://www.computer-museum.ru/books/Burcev_parallelizm.pdf )
11. В. Н. Касьянов, Ю. В. Бирюкова, В. А. Евстигнеев. ФУНКЦИОНАЛЬНЫЙ ЯЗЫК SISAL 3.0 (http://iis.nsc.ru/preprints/articles/pdf/sbor_kas_07_kasyanov_biryukova_evstigneev_sisal.pdf)
12. ALI R. HURSON, KRISHNA M. KAVI. DATAFLOW COMPUTERS: THEIR HISTORY AND FUTURE. (http://www.csrl.unt.edu/~kavi/Research/encyclopedia-dataflow.pdf)
13. Карпов В.Э. Объектно-ориентированное программирование. Часть 1. Язык Смолток. Учебное пособие. - Московский государственный институт электроники и математики. М., 2000 -- 45 с.
14. Питерсон Дж. Теория сетей Петри и моделирование систем: Пер. с англ. - М.
15. Салибекян С.М., Панфилов П.Б ОА-архитектура построения и моделирования распределенных систем автоматизации // Автоматизация в промышленности. N11, 2010.
16. Салибекян С.М., Панфилов П.Б. Объектно-атрибутный подход к созданию интеллектуальных систем. IX Всероссийская научная конференция «Нейрокомпьютеры и их применение 2011». Тезисы доклада, М. 2011. С. 45. URL: http://www.it.mgppu.ru/confnc/tezisy.pdf
17. Салибекян С.М., Панфилов П.Б. Объектно-атрибутный подход к построению интеллектуальных систем // Нейрокомпьютеры: разработки и применение. 2011, №11
18. Салибекян С.М., Панфилов П.Б. Объектно-атрибутная архитектура - новый подход к созданию объектных систем // Информационные технологии. 2012, №2
19. Баканов В.М., Потоковые (Dataflow) вычислители: управление интенсивностью обработки данных, Москва, 2010
20. Graph500 Documentation, http://www.graph500.org/
21. Салибекян С.М., Аминев Д.А., Семин В.Г., Результаты моделирования объектно-атрибутной вычислительной системы, 2012
22. Салибекян С.М., Панфилов П.Б., Хакимуллин Е.Р., Гетерогенные вычислительные системы на основе объектно-атрибутной модели программирования
23. Ю.И. Рыжиков, Имитационное моделирование: Теория и технологии, Альтекс, Москва, 2004 г.
Размещено на Allbest.ru
Подобные документы
Обзор существующих проектных решений, их достоинства и недостатки. Обоснование необходимости разработки информационной системы. Общее описание интерфейса BPwin. Разработка концепции архитектуры построения и платформы реализации. Создание новой модели.
курсовая работа [4,3 M], добавлен 11.09.2014Арифметические команды языка Assembler в архитектуре x86. Организация ветвлений и циклов в программах. Ввод строк с клавиатуры и команды пакетной обработки (строковые команды). Алгоритм вывода на экран в текстовом режиме с использованием средств BIOS.
контрольная работа [18,0 K], добавлен 05.07.2014Обоснование использования виртуальной модели, средства для разработки функциональных модулей. Разработка виртуальной модели "Представление знаний в информационных системах". Разработка алгоритмов построения виртуальной модели предметной области.
дипломная работа [1,4 M], добавлен 12.08.2017Формальная схема и закон функционирования моделируемой вычислительной системы для обработки программ. Составление алгоритма моделирующей программы на языке GPSS и листинга программы для стохастической модели. Верификация программы и анализ результатов.
курсовая работа [347,3 K], добавлен 21.01.2013Общее понятие о файловых системах, их классификация типы, функциональные особенности и условия применения. Методика и этапы установки операционной системы Windows 2000 на виртуальную машину. Форматирование запоминающих устройств в файловую систему NTFS.
курсовая работа [37,8 K], добавлен 09.07.2015Архитектуры вычислительных систем сосредоточенной обработки информации. Архитектуры многопроцессорных вычислительных систем. Классификация и разновидности компьютеров по сферам применения. Особенности функциональной организации персонального компьютера.
контрольная работа [910,2 K], добавлен 11.11.2010Требования к системам дистанционного обучения. Обзор некоторых существующих решений. Выбор и обоснование решения поставленной задачи. Установка общих параметров курса и формирование схемы курса. Создание системы навигации. Разработка основного меню.
научная работа [1,3 M], добавлен 26.04.2009Анализ существующих решений по автоматизации предметной области. Выбор методологии проектирования информационной системы. Сбор и спецификация, анализ, моделирование и аттестация требований. Возможные неисправности и сопровождение информационной системы.
курсовая работа [645,2 K], добавлен 26.05.2015Анализ существующих решений системы поддержки принятия решений для корпоративной сети. Многоагентная система. Разработка концептуальной модели. Структура базы знаний. Разработка модели многоагентной системы на базе сетей Петри. Методика тестирования.
дипломная работа [5,1 M], добавлен 19.01.2017Обоснование выбора языка и среды программирования. Обзор и анализ существующих программных решений. Разработка графического и пользовательского интерфейса. Алгоритм бинарного поиска. Методы добавления, удаления элемента из дерева и вывода на экран.
курсовая работа [1,3 M], добавлен 31.05.2016
