Parallel distributed implementation of parallel processing simulation
Prombles in programming 2014; 1: 40-48
Gespeichert in:
| Datum: | 2025 |
|---|---|
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | Ukrainian |
| Veröffentlicht: |
Інститут програмних систем НАН України
2025
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/729 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: | |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-729 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/fa/83447113f58061b87293eb60bbea20fa.pdf |
| spelling |
pp_isofts_kiev_ua-article-7292025-04-09T22:38:00Z Parallel distributed implementation of parallel processing simulation Паралельна розподілена реалізація моделювання паралельних обчислень Doroshenko, A.Yu. Gninyuk, M.V. UDC 004.424 УДК 004.424 Prombles in programming 2014; 1: 40-48 Запропонована паралельна реалізація для раніше створеного інструментарію моделювання гетерогенних паралельних обчислювальних систем, побудованого на основі фреймворку GridSim. Проведена перевірка та первинне дослідження цієї реалізації на прикладі однієї прикладної задачі.Prombles in programming 2014; 1: 40-48 Інститут програмних систем НАН України 2025-04-09 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/729 PROBLEMS IN PROGRAMMING; No 1 (2014); 40-48 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2014); 40-48 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2014); 40-48 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/729/781 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-04-09T22:38:00Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 004.424 |
| spellingShingle |
UDC 004.424 Doroshenko, A.Yu. Gninyuk, M.V. Parallel distributed implementation of parallel processing simulation |
| topic_facet |
UDC 004.424 УДК 004.424 |
| format |
Article |
| author |
Doroshenko, A.Yu. Gninyuk, M.V. |
| author_facet |
Doroshenko, A.Yu. Gninyuk, M.V. |
| author_sort |
Doroshenko, A.Yu. |
| title |
Parallel distributed implementation of parallel processing simulation |
| title_short |
Parallel distributed implementation of parallel processing simulation |
| title_full |
Parallel distributed implementation of parallel processing simulation |
| title_fullStr |
Parallel distributed implementation of parallel processing simulation |
| title_full_unstemmed |
Parallel distributed implementation of parallel processing simulation |
| title_sort |
parallel distributed implementation of parallel processing simulation |
| title_alt |
Паралельна розподілена реалізація моделювання паралельних обчислень |
| description |
Prombles in programming 2014; 1: 40-48 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/729 |
| work_keys_str_mv |
AT doroshenkoayu paralleldistributedimplementationofparallelprocessingsimulation AT gninyukmv paralleldistributedimplementationofparallelprocessingsimulation AT doroshenkoayu paralelʹnarozpodílenarealízacíâmodelûvannâparalelʹnihobčislenʹ AT gninyukmv paralelʹnarozpodílenarealízacíâmodelûvannâparalelʹnihobčislenʹ |
| first_indexed |
2025-07-17T10:08:45Z |
| last_indexed |
2025-07-17T10:08:45Z |
| _version_ |
1837888360516943872 |
| fulltext |
Інструментальні засоби і середовища програмування
© А.Ю. Дорошенко, М.В. Гнинюк, 2014
40 ISSN 1727-4907. Проблеми програмування. 2014. № 1
УДК 004.424
А.Ю. Дорошенко, М.В. Гнинюк
ПАРАЛЕЛЬНА РОЗПОДІЛЕНА РЕАЛІЗАЦІЯ
МОДЕЛЮВАННЯ ПАРАЛЕЛЬНИХ ОБЧИСЛЕНЬ
Запропонована паралельна реалізація для раніше створеного інструментарію моделювання гетероген-
них паралельних обчислювальних систем, побудованого на основі фреймворку GridSim. Проведена пе-
ревірка та первинне дослідження цієї реалізації на прикладі однієї прикладної задачі.
Вступ
Сьогодні паралельні обчислювальні
системи все більше використовуються як в
наукових, так і в промислових застосуван-
нях. Вони дозволяють ефективно викорис-
товувати існуючі різнорідні паралельні
ресурси та вирішувати задачі великих об-
сягів, які не можуть бути вирішені на ок-
ремих паралельних комплексах. Проте
Grid-системи є складними як для ство-
рення та конфігурування, так і для програ-
мування. При цьому підбір найбільш оп-
тимальних конфігурацій як для структури
самого Grid-середовища, так і для задач,
що виконуються на ньому, недоцільно
здійснювати на реальних системах через
великі витрати та необхідність координації
різних учасників Grid-проектів. Тому акту-
альною є задача моделювання, яка дозво-
ляє без витрат на створення, підтримку та
використання реальної Grid-системи про-
вести на моделі необхідні експерименти,
результати яких не будуть суттєво відріз-
нятися від оригіналу.
Слід зазначити, що актуальною є
проблема моделювання саме гетерогенних
Grid-систем, що включають до свого скла-
ду центральні процесори (CPU), а також як
графічні прискорювачі (відеоадаптери,
GPU) через їх високу продуктивність
останніх, їх доступність за ціною і енерго-
ефективність. Одним з популярних засобів
моделювання паралельних систем (класте-
рів, Grid-систем), окремі вузли яких мають
гетерогенний характер і містять як CPU,
так і GPU-компоненти, є фреймворк
GridSim [1]. Паралельна система з CPU +
GPU за допомогою сутностей GridSim мо-
же бути представлена у вигляді ресурсу з
двома ЕОМ: перша ЕОМ визначає кіль-
кість ядер CPU та їх рейтинг, друга – кіль-
кість ядер GPU та їх рейтинг. Ядра CPU та
GPU моделюються у вигляді обчислюва-
льних елементів (PE). Моделювання CPU і
GPU-компонентів з використанням базо-
вих сутностей GridSim дозволить надалі
спростити включення розробленої моделі в
більш складні конфігурації гетерогенних
систем, зокрема кластери і Grid-системи з
GPU-вузлами.
У роботі [2] запропонована архітек-
тура гнучкого і розширюваного середови-
ща моделювання гетерогенних Grid-систем
gpusim на базі Java-фреймворку GridSim.
Особливістю системи є такий підхід до
опису гетерогенної паралельної системи,
при якому CPU і GPU-компоненти розгля-
даються як окремі вузли віртуального
Grid-середовища. Описано прототип ін-
струментальної системи для моделювання,
заснований на використанні запропонова-
ної архітектури, а також механізм налаш-
тування системи на параметри конкретної
паралельної системи за рахунок автомати-
зованого підбору параметрів моделі. Екс-
перименти показали достатню точність
побудованої моделі для великих розмірів
вхідних даних та ефективність застосуван-
ня системи моделювання. В роботі [3] ці
дослідження продовжені на прикладі відо-
мої прикладної задачі гравітаційної взає-
модії N тіл, де було поставлено більш
складне питання про пошук оптимального
значення параметрf конфігурації обчислю-
вальної системи для отримання більш ефе-
ктивної програми.
В даній роботі виконано наступний
Інструментальні засоби і середовища програмування
41
крок у розвитку інструментарію моделю-
вання у напрямку підвищення ефективнос-
ті цього інструментарію за рахунок ство-
рення його паралельної розподіленої реа-
лізації. Матеріал статті організований на-
ступним чином. У розділі 1 розглянуто
основні засади імітаційного моделювання,
наведено огляд існуючих рішень для мо-
делювання Grid-систем та обгрунтована
необхідність розробки інструментарію
gpusim. У розділі 2 описана архітектура
інструментарію gpusim та його паралельна
розподілена реалізація. У розділах 3 та 4
розглядається застосування паралельної
версії інструментарію gpusim для моделю-
вання конкретної прикладної задачі (блоч-
ний алгоритм множення матриць. Роботу
завершують висновки та напрямки пода-
льшої роботи.
1. Засоби імітаційного
моделювання
Імітаційне моделювання є най-
більш потужним, а іноді і єдиним мето-
дом дослідження динамічної поведінки
складних систем [4]. Імітаційна модель
відтворює поведінку модельованої систе-
ми у часі, для якого використовуються
три категорії часу: фізична, модельна і
процесорна. Фізичний час стосується
системи, що моделюється, модельний –
відтворення фізичного часу в моделі, а
процесорним часом називається час ви-
конання імітаційної моделі на комп’ю-
тері. Співвідношення фізичного і модель-
ного часу визначається специфікою сис-
теми і задається величиною діапазону
фізичного часу, прийнятого за одиницю
модельного часу.
Змістом імітаційного моделювання
є просування модельного часу і виконання
подій, пов’язаних з певними його значен-
нями, а основним завданням імітаційного
моделювання є правильне відображення
порядку подій у системі, що моделюється,
на порядок виконання подій у моделі.
Моделювання складних систем мо-
же вимагати значних витрат процесорного
часу. Тому важливим завданням системи
імітаційного моделювання є зменшення
процесорного часу, наприклад, за рахунок
паралельного виконання подій на мульти-
процесорній техніці. Хоча у деяких прик-
ладних галузях, навпаки, може виникнути
потреба у штучному збільшення процесо-
рного часу, наприклад, для моделей тре-
нажерів з метою наблизити віртуальне се-
редовище, що генерується комп'ютером,
до реального.
У даній роботі розглядається задача
мінімізації часу імітаційного моделювання
виконання Grid-програм на відеографічних
процесорах за рахунок розпаралелювання
програми моделювання.
На сьогоднішній день розроблено
чимало інструментальних засобів моде-
лювання Grid-систем. Серед них імітацій-
ні моделі використовуються для більш
точних вимірів продуктивності Grid-
систем при конкретних значеннях параме-
трів. Вони дозволяють отримати довільну
точність моделювання за рахунок враху-
вання всіх необхідних деталей. Але на
практиці потрібно досягати балансу між
точністю моделювання та обчислюваль-
ною складністю.
Серед існуючих рішень можна ви-
ділити імітаційну модель, розроблену для
дослідження ефективності методів плану-
вання ресурсів для різних інтенсивностей
потоків завдань у Grid [5] і її програмну
реалізацію GRID_Scheduler_Model. Моде-
люється гомогенна Grid-система, і для під-
тримки гетерогенних Grid модель потребує
доопрацювання, а розширюваність у реалі-
зації не передбачена.
На даний момент існує кілька ін-
струментаріїв (фреймворків), які дозволя-
ють розробнику на їх основі створити
свою модель Grid і проводити на ній екс-
перименти. Огляд і порівняльний аналіз
найбільш функціональних та стабільних
фреймворків MicroGrid, OptorSim,
SimGrid, GridSim, Bricks наведено в [6, 7].
На підставі порівняння можна зробити
висновок, що найбільш зручним і функці-
ональним є GridSim [1], фреймворк для
мови програмування Java.
Окремим питанням є моделювання
часу виконання задач на GPU, зокрема такі
аспекти їх функціонування запропоновано
детальну аналітичну модель як час вико-
нання та споживання енергії [8, 9], а також
Інструментальні засоби і середовища програмування
42
порівняння продуктивності CPU та GPU
[10, 11]. Застосування таких засобів моде-
лювання дозволяє досягти великої точнос-
ті моделювання, але потребують значних
ресурсів для виконання моделі. До того ж
вони не передбачають вбудовування у мо-
делі Grid-середовища.
У роботах [2, 3] запропоновані спе-
ціалізовані засоби імітаційного моделю-
вання gpusim, засновані на інструментарії
GridSim і спрямовані на моделювання ро-
боти GPU з метою визначення оптималь-
них значень параметрів прикладних задач,
що забезпечують найбільше прискорення
виконання цих задач на GPU. Для збіль-
шення ефективності використання таких
засобів актуальною задачею є розпарале-
лювання програм самого імітаційного мо-
делювання, що і є метою даної роботи.
2. Розподілено – паралельна
система моделювання gpusim
2.1. Основні концепції фреймвор-
ку Hazelcast. Hazelcast – це платформа з
відкритим програмним кодом для Java, яка
використовується для побудови кластерів
та масштабованого розподілу даних. Серед
властивостей платформи основними є такі:
велика швидкість – тисячі опе-
рацій на секунду;
відмовостійкість – без втрати
данних після аварій;
динамічне масштабування – по
мірі додавання нових серверів;
легке використання – досить
додати у свій проект один jar файл.
Завдяки розподіленості структур
даних, можливості розподіленого кешу-
вання, гнучкості кешування та інтеграції з
функціями Spring та Hibernate Hazelcast
перетворюється на систему промислового
використання у як платформа для ство-
рення кластерів.
2.2. Можливості Hazelcast. Основ-
ні можливості Hazelcast у частині розподі-
леної паралельної обробки включають та-
кі:
розподілені функції java.util.
(Queue, Set, List, Map та інші);
розподілена підтримка індексу-
вання та запитів;
підтримка транзакцій шифру-
вання на рівні сокетів для безпеки класте-
рів;
віддалений доступ до кластера
для Java-клієнтів;
динамічне розширення кластера
та динамічний перерозподіл після падіння
одного з вузлів кластера.
2.3. Коли застосовувати Hazel-
cast? Hazelcast застосовують, коли потріб-
но вирішити такі задачі:
організація обміну дани-
ми/станом серед багатьох серверів та ке-
шування даних (розподілений кеш);
кластеризація за стосунку та за-
безпечення захищенної комунікації між
серверами;
спільне використання даних у
пам’яті;
розподіл завантаження на бага-
то серверів та паралельне виконання задач;
забезпечення відмово-стійкого
управління даними.
2.4. Архітектура розподіленої па-
ралельної системи моделювання. У пер-
шій версії системи моделювання gpusim
[2] реалізовано послідовну процедуру си-
муляції задачі на GPU за допомогою засо-
бів GridSim [1]. Послідовна версія виконує
всі симуляційні задачі повністю, проте це
може займати досить тривалий час, особ-
ливо при збільшенні кількості симуляцій
та рівня складності задачі, тому вирішено
зробити gpusim розподілено-паралельною
системою.
На сьогодні всі процесори, що ви-
користовуються у вузлах мультипроцесо-
рних систем, є багатоядерними і викону-
ють задачі паралельно, що дає змогу при-
скорити виконання програм. Але отри-
мання приросту продуктивності за раху-
нок паралельності є обмеженим фізични-
ми можливостями конкретного ком-
п’ютера на якому виконується симуляція.
Тому вирішено зробити gpusim розподі-
лено-паралельним. Це дає досліднику мо-
жливість нарощувати обчислювальну по-
Інструментальні засоби і середовища програмування
43
тужність шляхом об’єднання комп’ютерів
у кластер.
Кластер містить декілька окремих
обчислювальних машин, що використову-
ються спільно і працюють як одна система
для вирішення тих чи інших задач, напри-
клад, для підвищення продуктивності, за-
безпечення надійності, спрощення, адміні-
стрування тощо. Обчислювальний кластер
потрібен для збільшення швидкості обра-
хунків за допомогою паралельних обчис-
лень.
Для організації кластера використо-
вується згадана вище система Hazelcast. На
даному етапі розроблено три застосунки у
вигляді jar файлів:
GpuSimV2.jar, GpuSimClusterInstance.jar та
GpuSimClusterClient.jar.
Симулятор GpuSimV2 – це оболо-
нка на мові програмування Java над фрей-
мворком GridSim, основною задачею якої є
налаштування GridSim на основі даних
конфігураційного файлу, запуск симуляції,
збір і вивід статистики у файл.
Cluster Instance – являє собою за-
стосунок, що запускається на комп’ютері,
який має стати частиною кластера. Про-
грама шукає інші члени у мережі та приє-
днується до кластера.
Cluster Client – застосунок, який
стає частиною кластера та запускає симу-
ляцію на утвореному кластері, шляхом
розділення симуляцій поміж членами кла-
стера.
2.5. Реалізація розроблених засто-
сунків. Для збільшення швидкодії процесу
симуляції, запропонована розподілено-
паралельна система.
Роглянемо побудову елементів
GpuSimClusterInstance та GpuSimCluster-
Client.
Екземпляр кластера GpuSim-
ClusterInstance – це компонент, який до-
зволяє перетворити комп’ютери, які
з’єднані між собою локальною мережею,
на кластер. Для цього треба запустити
GpuSimClusterInstance таким чином:
java –classpath GpuSimClusterInstance.jar
com.mgnyniuk.base.Main
У результаті запуску декількох ек-
землярів буде утворений кластер:
Members [2] {
Member [192.168.100.37]:5701
Member [192.168.100.37]:5702 this
}
GpuSimClusterInstance складається з таких
пакетів:
com.mgnyniuk.base
com.mgnyniuk.parallel
До пакета com.mgnyniuk.base на-
лежить клас Main, який має метод
main(String[] args), який запускає кластер
та його конфігурує:
public static void main(String[] args) {
Config cfg = new Config();
cfg.setProperty("hazelcast.icmp.timeout",
"2000000000");
HazelcastInstance hz =
=Hazelcast.newHazelcastInstance(cfg);
outputMap = hz.getMap("outputMap");
}
За допомогою конфігурації ми мо-
жемо задавати різні параметри для налаш-
тування кластера. OutputMap – це структу-
ра даних для зберігання результатів симу-
ляції у кластері.
До пакета com.mgnyniuk.parallel на-
лежать класи, які відповідають за парале-
льну функціональність системи та
ConfigurationUtil, який включає такі засоби
для роботи з конфігураціями, як серіаліза-
ція конфігурацій та десеріалізація резуль-
татів та збереження у OutputMap.
Основним класом у паралельній
частині є Runner, який також використо-
вує функціональність, яка з’явилась у Java
1.5 і підримується в Hazelcast – Executor
framework. Це дозволяє асинхронно вико-
нувати поставлені задачі та виконувати
іншу роботу водночас. Є також можли-
вість керувати часом виконання задачі, а
саме:
задача виконується вчасно,
отримується результат та продовжується
робота;
Інструментальні засоби і середовища програмування
44
якщо задача виконується біль-
ше часу ніж очікувалось, то є можливість
скасувати її та продовжити роботу.
Клас Runner реалізує інтерфейси
Callable<Boolean> та Serializable.
public Boolean call() throws IOException {
ConfigurationUtil.deserializeConfigs(gridSim
ConfigList, startIndex);
ThreadListener threadListener = new
ThreadListener();
for (int j = 0; j <
< overallProcessesQuantity/partProcessesQua
ntity; j++) {
for (int i = startIndex; i < startIndex +
+ partProcessesQuantity; i++) {
NotifyingThread notifyingThread = new
WorkerThread("GpuSimV2.jar",
String.format(CONFIG, (i + j *
partProcessesQuantity)),
String.format(OUTPUT, (i + j *
partProcessesQuantity)));
notifyingThread.addListener(threadListener);
notifyingThread.start();
}
while
(threadListener.quantityOfEndedThreads ! =
= partProcessesQuantity) {
System.out.print(threadListener.quantityOfEn
dedThreads);
continue;
}
threadListener.quantityOfEndedThreads = 0;
}
ConfigurationUtil.loadOutputs(startIndex,part
ProcessesQuantity);
return true;
}
Метод call() викликається при ви-
конанні симуляції на кожному члені клас-
тера. Він виконує такі функції:
серіалізація отриманих конфі-
гурацій;
виконання розпаралелювання
симуляцій шляхом запуску кожного
GpuSimV2.jar у новому потоці, який
створює для кожного працюючого
GpuSimV2.jar свій процес операційної
системи. Система може створювати “пор-
ції” паралельних потоків, розмір яких
визначається змінною partProcessesQuan-
tity. Це дає змогу оптимально використо-
вувати обчислювальну потужність ком-
п’ютера який виконує задачу симуляції.
Після закінчення “порції”, якщо не опра-
цьовані всі конфігурації, то запускається
нова і т. д., тоді коли симуляція закінчу-
ється, то файли отримані з GpuSimV2
десеріалізуються та зберігаються в output-
Map. В outputMap свої результати склада-
ються всі учасники кластера.
Клієнт та екземпляр кластера
GpuSimClusterClient – це компонент,
який запускає симуляцію на кластері та
стає складовою кластера.
GpuSimClusterClient запускається
таким чином:
java –classpath GpuSimClusterClient.jar
com.mgnyniuk.base.Main
GpuSimClusterClient складається
аналогічно до GpuSimClusterClient з паке-
тів com.mgnyniuk.base та
com.mgnyniuk.parallel.
Склад пакетів є таким самим, як
і у GpuSimClusterInstance. Відрізнаються
тільки реалізацією метода main(String[]
args), більш широкою функціональністью
ConfigurationUtil та доповненним мето-
дом call() класу Runner для обробки до-
даткових симуляцій, які залишаються від
ділення задачі на встановлені “порції”
паралельних потоків. ConfigurationUtil та-
кож відповідає за підготовку конфігура-
цій для симуляцій запропонованої задачі
на GPU.
Метод main(String[] args), є відпові-
дальним за запуск симуляції на Gridі.
Метод виконує такі дії:
визначає кількість членів клас-
тера;
розділяє задачі для членів клас-
тера і вказує кількість паралельних потоків
на які ділити задачі та ініціює їх обробку;
після закінчення обробки десе-
Інструментальні засоби і середовища програмування
45
ріалізує outputMap та зберігає результати;
вимірює час виконання симуля-
цій на кластері.
3. Моделювання задачі множення
матриць
3.1. Задача множення матриць
блочним алгоритмом. Для перевірки
точності та актуальності розробленого
середовища моделювання гетерогенних
Grid-систем обрана задача множення
матриць за допомогою блочного алго-
ритму [12].
Результатом множення матриці A
розмірністю nm й матриці B розмірнос-
ті ln є матриця C розмірності lm ,
кожен елемент якої обчислюється наступ-
ним чином:
1
0
n
k
kjikij bac , mi ,..,0 , lj ,..,0 .
Цей алгоритм вимагає lnm опе-
рацій множення й додавання елементів
матриць. При множенні квадратних мат-
риць розмірності nn кількість виконаних
операцій має порядок )( 3nO . Оскільки для
обчислення одного елемента результуючої
матриці потрібні тільки відповідні рядок та
стовпець матриць, що множаться, цей ал-
горитм природно розділяється на незалеж-
ні потоки обчислень.
Якщо ми множимо дві квадратні
матриці розмірністю nn , то результуюча
матриця C буде тієї самої розмірності, що
й вхідні матриці A і B . Спочатку матриця
C розбивається на прямокутні блоки роз-
мірністю pk . Кожен з цих блоків обчис-
люється незалежно окремою задачею, для
чого потрібно передати блок матриці A
розмірністю kn й відповідний блок мат-
риці B розмірністю np .
Перевагою такого алгоритму є те,
що задачу можна розбивати на довільну
кількість підзадач, а не тільки на квадра-
тні блоки. Також відсутність будь-яких
залежностей між підзадачами дозволяє
ефективно виконувати обчислення у ви-
падку коли кількість наявних процесо-
рів значно менша за кількість підблоків –
у такому випадку підзадачі отримують
нові блоки «за готовністю». Недоліком є
додаткові витрати пам’яті, які виника-
ють при частковому дублюванні вхідних
даних для різних підзадач. Загальна
кількість операцій не відрізняється від
послідовного алгоритму й має порядок
)( 3nO .
В роботі [14] також побудовано ем-
піричну модель часу виконання блочного
алгоритму на GPU. Ця модель має наступ-
ний характер:
2 3
. .gpu st global ld globalT N T N T ,
де .ld globalT та .st globalT – параметри, що
визначають час завантаження та збережен-
ня даних при роботі з глобальною пам'ят-
тю GPU. Ці параметри є частиною опису
моделі і мають підбиратись для конкрет-
них обчислювальних вузлів експеримента-
льним шляхом.
3.2. Експериментальний модуль
множення матриць блочним алгорит-
мом. На основі емпіричної моделі часу
виконання задачі множення матриць на
GPU [14] розроблені генератор експериме-
нтів симулятора і обробник статистики, що
входять до складу експериментального
модуля MatrixMultiply. Вхідні параметри
генератора – розмір блоку, мінімальний і
максимальний розмір матриці, а також
інкремент розміру матриці. Оброблювач
статистики отримує вихідні дані симуля-
тора, перетворює їх для наочного відобра-
ження кінцевому користувачу, а також
порівнює час кожної з симуляцій з резуль-
татами експерименту на реальній парале-
льній системі.
Генератор має ряд попередньо
встановлених параметрів, що не відносять-
ся безпосередньо до експерименту, але
впливають на час симуляції:
кількість обчислювальних еле-
ментів CPU і GPU, а також їх рейтинги в
одиницях MIPS (million instructions per
second):
cpuMachinePECount,
cpuMaсhinePERating,
gpuMaсhinePECount,
Інструментальні засоби і середовища програмування
46
gpuMaсhinePERating;
пропускна здатність підклю-
чення між ресурсами і розподільниками
завдань: resourceBaudRate, linkBaudRate;
вартість використання ресурсів
Grid – resourceCostPerSec;
вартість операцій роботи із
пам’яттю – це завантаження та збереження
даних:
loadOperationCost,
saveOperationCost.
Дані параметри залежать від внут-
рішньої структури Grid-системи, відповід-
ної моделі, і для проведення подальших
досліджень з моделлю, необхідно знайти їх
точні значення за допомогою модуля оп-
тимізації констант.
4. Тестування розподілено –
паралельної версії gpusim та
аналіз отриманих результатів
4.1. Проведення тестування системи.
Для проведення тестування системи вирі-
шено використати наявні ресурси, а саме:
4 комп’ютери, які мають по 4 ядра кожний
однакової обчислювальної потужності.
Тестування проводилось на 256 симуляці-
ях, що є стандартними налаштуваннями
для GpuSim першої версії. Виконано 5 ви-
мірів часу виконання симуляції:
послідовно,
паралельно на 4 ядрах.
паралельно на 8 ядрах,
паралельно на 12 ядрах,
паралельно на 16 ядрах.
Симуляції, які виконувались на 1, 4,
8 та 16 ядрах паралельно запускались пар-
тіями по 16 потоків для оптимального ви-
користання ресурсів, на 12 ядрах, так як це
3 комп’ютери, то розмір партій дорівнював
17, остання симуляція (256 – та) додатково
виконана на останньому доданому члені
кластеру – клієнті.
4.2. Аналіз отриманих результатів.
Отримані результати приводяться в табл. 1.
Таблиця 1
P T , с
1 161.812
4 69.749
8 44.978
12 33.627
16 24.36
де P – кількість ядер, а T – час виконання
процесу симуляції для 256 конфігурацій.
На базі отриманих результатів побудо-
вано графік залежності часу виконання від
кількості задіяних ядер, який показано на
рис. 1.
Рис. 1. Графік залежності TP
З графіка видно істотне прискорен-
ня виконання симуляцій.
Також досліджено залежність прис-
корення зміни часу виконання від кількос-
ті ядер. Прискорення обчислюється за фо-
рмулою:
pp TTS 1 .
За допомогою даної формули отри-
мано табл. 2.
Таблиця 2
P pS
1 1
4 2.319918565
8 3.59758104
12 4.811966574
16 6.642528736
Інструментальні засоби і середовища програмування
47
За табл. 2 побудовано графік, на
якому показано, що прискорення набли-
жається до ідеального випадку PS p
(рис. 2)
Рис. 2. Графік залежності PS p
Висновки
У роботі запропонована архітектура
розподілено-паралельної версії GpuSim.
Одною з головних задач побудови наступ-
ної версії є зменшення часу виконання си-
муляцій. Для досягнення цієї цілі побудо-
вано нову архітектуру для системи моде-
лювання gpusim.
На цей момент розроблено “ядро”
розподілено-паралельної системи, яке
перевірено на прикладі задачі множення
матриць блочним алгоритмом. Отримані
результати, які наведені вище, показу-
ють, що приріст швидкодії є істотним та
прискорення наближається до графік лі-
нійної залежності PS p , що підвере-
джує ефективність обраної архітектури та
реалізації. Одним з головних надбань да-
ного рішення є те, що дослідник може
нарощувати ресурси для обчислень за сво-
їм бажанням, різної конфігурації та поту-
жності, що дає змогу досягати бажаної
швидкодії системи.
На базі розробленого “ядра” буде
розроблений інтерфейс для виконання
симуляцій, а також для конфігурування
роботи розподілено – паралельної систе-
ми.
1. GridSim. A Grid Simulation Toolkit for
Resource Modelling and Application
Scheduling for Parallel and Distributed
Computing [Электроний ресурс]. – Режим
доступу: http://www.buyya.com/gridsim/. –
01.11.2013 р.
2. Оконський І.В., Дорошенко А.Ю., Жереб
К.А. Інструментальні засоби моделювання
гетерогенних середовищ заснованих на
відеографічних прискорювачах // Пробле-
ми програмування. – 2013. – № 1. –
С. 107–115.
3. Дорошенко А.Ю., Оконський І.В., Жереб
К.А. та ін. Використання засобів моделю-
вання для визначення оптимальних пара-
метрів виконання програм на відеографіч-
них прискорювачах // Проблеми програму-
вання. – 2013. – № 2. – С. 23–31.
4. Лоу А.М., Кельтон А.Д. Имитационное
моделирование. – СПб: Издательская
группа BHV, 2004. – 847 с.
5. Минухин С.В., Знахур С.В. Исследование
эффективности методов планирования ре-
сурсов для различных интенсивностей по-
токов заданий в Грид // Радіоелектронні і
комп’ютерні системи. – 2012. – № 1 (53). –
С. 165–171.
6. Петренко А.І. Комп’ютерне моделювання
грід-систем // Электроника и связь. – 2010.
– № 5. – С. 40–48.
7. Кореньков В.В., Нечаевский А.В. Пакеты
моделирования DATAGRID // Системный
анализ в науке и образовании. – 2009. –
№ 1. – С. 1–15.
8. Baghsorkhi S.S., Delahaye M., Patel S.J., et
al. An adaptive performance modeling tool
for GPU architectures // SIGPLAN Not. –
2010. – Vol. 45, N 5. – P. 105–114.
9. Hong S., Kim H. An integrated GPU power
and performance model // SIGARCH
Comput. Archit. News. – 2010. – Vol. 38,
N 3. – P. 280–289.
10. Kerr A., Diamos G., Yalamanchili S.
Modeling GPU-CPU workloads and systems
// Proceedings of the 3rd Workshop on
General-Purpose Computation on Graphics
Processing Units. – 2010.– P. 31–42.
11. Kerr A., Diamos G., Yalamanchili S. A
characterization and analysis of PTX kernels
// IEEE International Symposium on
Workload Characterization (IISWC 2009). –
2009. – P. 3 –12.
12. Жереб К.А., Ігнатенко О.П. Моделювання
задачі множення матриць для відеографіч-
них прискорювачів // Матеріали конферен-
ції "Високопродуктивні обчислення"
(HPC-UA 2012). Київ, 08 –10 жовтня 2012.
– С. 174–181.
13. Qt Developer Network [Электроний ресурс].
– Режим доступу: http://qt-project.org/. –
01.11.2012 г.
Інструментальні засоби і середовища програмування
48
14. Intel Core i7-3770k Processor [Электроний
ресурс]. – Режим доступу:
http://ark.intel.com/products/65523. –
01.11.2012 г.
15. GeForce GTX 650 Specifications [Электро-
ний ресурс]. – Режим доступу:
http://www.geforce.com/hardware/desktop-
gpus/geforce-gtx-650/specifications . –
01.11.2012 г.
16. Hazelcast Documentation [Электроний ре-
сурс]. – Режим доступу:
http://www.hazelcast.com/docs/3.1/manual/si
ngle_html/#
Одержано 16.07.2013
Про авторів:
Дорошенко Анатолій Юхимович,
доктор фізико-математичних наук,
професор, завідувач відділу теорії
комп’ютерних обчислень Інституту
програмних систем НАН України,
професор кафедри автоматики і управлін-
ня в технічних системах НТУУ “КПІ”,
Гнинюк Максим Володимирович,
студент факультету інформатики та
обчислювальної техніки,
кафедри автоматики і управління
в технічних системах НТУУ “КПІ”.
Місце роботи авторів:
Національний технічний
університет України "КПІ"
03056, Київ-56,
проспект Перемоги, 37
Тел.: (044) 236 7989
Інститут програмних систем
НАН України,
03680, Київ-187,
проспект Академіка Глушкова, 40.
Тел.: (044) 526 1538.
E-mail: dor@isofts.kiev.ua
mgnyniuk@gmail.com
mailto:dor@isofts.kiev.ua
mailto:mgnyniuk@gmail.com
|