Візуалізація Деякі інші засоби аналізу поведінки паралельних програм: XMPI - графічне середовище запуску та налагодження MPI-програм, входить до складу пакету LAM. HP Pak - набір засобів від Hewlett-Packard для аналізу поведінки багатопоточних програм. TAU (Tuning and Analysis Utilities) - некомерційний набір утиліт аналізу продуктивності програм, написаних на мові C + + і його паралельних варіантах. Включає пакет профілювання TAU Portable Profiling. Carnival Chiron - засіб для оцінки продуктивності багатопроцесорних систем зі спільною пам'яттю. Pangaea GUARD - паралельний відладчик. MPP-Apprentice - засіб в складі Message-Passing Toolkit від SGI. ParaGraph PGPVM2 TraceInvader XPVM - графічний засіб моніторингу PVM-програм.
Докладніше можна прочитати в [8]. 4. Характеристики та методика налагодження DVM-програм 4.1 Основні характеристики продуктивності Можливість розрізняти послідовні і паралельні ділянки програми дозволяє при її виконанні на багатопроцесорної ЕОМ спрогнозувати час, який знадобиться для виконання цієї програми на однопроцесорній ЕОМ. Цей час називається найкориснішим часом. Тим самим з'являється можливість обчислити головну характеристику ефективності паралельного виконання - коефіцієнт ефективності, що дорівнює відношенню корисного часу до загального часу використання процесорів, яке у свою чергу дорівнює добутку часу виконання програми на багатопроцесорної ЕОМ (максимальне значення серед часів виконання програми на всіх використовуваних нею процесорах) на число використовуваних процесорів. Різниця між загальним часом використання процесорів і найкориснішим часом представляє собою втрачений час. Якщо програміст не задоволений коефіцієнтом ефективності виконання своєї програми, то він повинен проаналізувати складові частини втраченого часу і причини їх виникнення. Існують наступні складові втраченого часу: втрати через нестачу паралелізму, що призводить до дублювання обчислень на декількох процесорах (недостатній паралелізм). Дублювання обчислень здійснюється у двох випадках. По-перше, послідовні ділянки програми виконуються усіма процесорами. По-друге, витки деяких паралельних циклів можуть бути за вказівкою програміста повністю або частково розмножені. втрати через виконання міжпроцесорних обмінів (комунікації). втрати через простої тих процесорів, на яких виконання програми завершилося раніше, ніж на інших (простої).
Час виконання міжпроцесорних обмінів, крім часу пересилання даних з одного процесора на інший, може включати в себе і час, який витрачається через те, що операція прийому повідомлення на одному процесорі видана раніше відповідної операції посилки повідомлення на іншому процесорі. Така ситуація називається розсинхронізація процесорів і може бути викликана різними причинами. Оскільки втрати, викликані розсинхронізація процесорів, дуже часто становлять переважну частину часу комунікацій, то важливо надати програмістові інформацію, що дозволяє йому оцінити ці втрати і знайти їх причини. Проте, точне визначення втрат, викликаних розсинхронізація, пов'язано зі значними накладними витратами Якщо яка-небудь з перерахованих операцій видана різними процесорами не одночасно, то при її виконанні виникнуть втрати через рассинхронізациі процесорів. Для оцінки величини таких втрат для кожної колективної операції обчислюються потенційні втрати з-за її неодновременного запуску - час, який було б витрачено усіма процесорами на синхронізацію, якщо б виконання будь-якої колективної операції починалося б з синхронізації процесорів. При цьому накладні витрати на пересилання синхронізаційних повідомлень ігноруються. Для оцінки сумарних потенційних втрат, які можуть виникнути через неодновременного запуску колективних операцій на різних процесорах, служить спеціальна характеристика - синхронізація. Основна причина втрат через рассинхронізациі, на усунення якої повинен бути націлений програміст - розбалансування завантаження процесорів. Розбалансування може виникати через те, що виконуються в паралельному циклі обчислення розподілені між процесорами нерівномірно. Якби при вході в кожен паралельний цикл і при виході з нього відбувалася б синхронізація процесорів (межпроцессорной обмін), то розбалансування завантаження процесорів обов'язково призводила б до втрат із-за рассинхронізациі. Однак, оскільки така синхронізація здійснюється не для всіх циклів, то розбалансування на різних ділянках програми може компенсуватися і реальні втрати можуть бути незначними або взагалі відсутні. Для оцінки можливих втрат через розбалансування програмісту може видаватися деяка узагальнена характеристика - розбалансування. З метою зниження накладних витрат при обчислення цієї характеристики робиться припущення, що синхронізація процесорів буде здійснюватися тільки один раз - по завершенні виконання програми. Тому спочатку для кожного процесора визначається його сумарна обчислювальна завантаження, а потім прогнозується викликається розбалансуванням величина втрат через рассинхронізациі. Проте, оскільки в реальній програмі синхронізація процесорів здійснюється не тільки при завершенні програми, а набагато частіше, то реальні втрати будуть перевершувати цю величину. Реальні втрати через рассинхронізациі будуть ще більш перевершувати величину розбалансування в тому випадку, коли обчислювальна завантаження процесорів сильно змінюється при багаторазовому виконанні одного і того ж паралельного циклу. Розсинхронізація може виникати не тільки через розбалансування, але також через відмінності в часах завершення виконання на різних процесорах однієї і тієї ж колективної операції, викликаних особливостями її реалізації на конкретній паралельної ЕОМ. Для оцінки величини такої потенційної рассинхронізациі програмісту може видаватися спеціальна характеристика - розкид часів завершення колективних операцій. Як і час розбалансування, ця характеристика є інтегральною. Вона досить точно відображає можливі втрати з-за рассинхронізациі в тому випадку, коли різниця часів виконання колективних операцій не є випадковими, а визначаються, наприклад, топологією комунікаційної мережі або функціональною спеціалізацією процесорів (процесор вводу-виводу, процесор-виконавець редукційних операцій, і т . п.). Важливою характеристикою, що відбиває ступінь суміщення міжпроцесорних обмінів з обчисленнями, є час перекриття обмінів обчисленнями. Основні характеристики ефективності є інтегральними характеристиками, що дозволяють оцінити ступінь розпаралелювання програми та основні резерви її підвищення. Однак для дослідження ефективності складних програм одних інтегральних характеристик може виявитися недостатньо. У такому випадку програміст хоче отримати більш детальну інформацію про виконання своєї програми та її окремих частин. 4.2 Методика налагодження ефективності Для аналізу ефективності виконання складних паралельних програм недостатньо мати характеристики виконання всієї програми цілком, а потрібно вміти деталізувати ці характеристики стосовно до окремих частин програми. У системі DVM були реалізовані відповідні кошти, які дозволяють представити виконання програми у вигляді ієрархії інтервалів [докладніше - 6]. Інтервали: Виконання всієї програми цілком розглядається як інтервал самого високого (нульового) рівня. Цей інтервал може включати в себе кілька інтервалів наступного (першого) рівня. Такими інтервалами можуть бути паралельні цикли, послідовні цикли, а також будь-які зазначені програмістом послідовності операторів, виконання яких завжди починається з виконання першого оператора, а закінчується виконанням останнього. Всі описані вище характеристики обчислюються не лише для всієї програми, але і для кожного її інтервалу. При цьому багаторазове виконання інтервалу може розглядатися (з деякою часткою умовності) як виконання на тих же процесорах окремої програми, що складається з розгорнутої послідовності тих операторів інтервалу, які були виконані при реальному проходженні паралельної програми. Фактично ж, характеристики таких багаторазово виконуваних інтервалів накопичуються при кожному їх виконанні. При цьому інтервали, що входять до складу одного й того ж інтервалу більш високого рівня, ідентифікуються ім'ям файлу з вихідним текстом програми та номером рядка в ньому, відповідним початку інтервалу, а також, можливо, деяким приписаним йому програмістом цілочисловим номером. Розбивкою програми на інтервали користувач управляє з її компіляції. Він може поставити такі режими, при яких інтервалами будуть послідовні цикли, які містять в собі паралельні цикли, або всі послідовні цикли взагалі, або зазначені ним у програмі послідовності операторів. 4.3 Рекомендації з аналізу При розробці паралельної програми користувач, як правило, переслідує одну з двох можливих цілей - забезпечити вирішення завдання в прийнятні терміни, або створити програму, здатну ефективно вирішувати на різних паралельних ЕОМ задачі певного класу. У першому випадку, якщо час виконання програми задовольняє користувача, то інші характеристики його можуть вже не цікавитиме. У другому випадку головним критерієм для користувача є коефіцієнт ефективності розпаралелювання. Якщо час виконання або коефіцієнт ефективності не задовольняє користувача, то йому необхідно аналізувати втрачений час і його компоненти. Важливо пам'ятати, що: по-перше, втрачений час (як і коефіцієнт ефективності розпаралелювання) обчислюється, спираючись не на реальний час виконання програми на одному процесорі, а на прогнозоване час. Цей прогноз може відрізнятися від реального часу і в ту, і в інший бік. Реальний час може бути більше прогнозованого через те, що при виконанні програми на одному процесорі одні й ті ж обчислення можуть здійснюватися повільніше, ніж при виконанні на декількох процесорах. Це пояснюється тим, що при зміні обсягу використовуваних при обчисленнях даних міняється швидкість доступу до них через кеш-пам'ять. Оскільки продуктивність сучасних процесорів сильно залежить від ефективності використання кеш-пам'яті, то реальний час може помітно перевищити прогнозоване. Реальний час може бути менше прогнозованого, оскільки при прогнозі враховуються не всі накладні витрати на підтримку виконання паралельної програми. Ці невраховані витрати, наприклад, пошук інформації в системних таблицях при виконанні деяких часто використовуваних функцій (заміряти час виконання яких неможливе без внесення неприйнятних спотворень у виконання програми), можуть значно скоротитися при зменшенні кількості процесорів до одного. У результаті впливу ефективності використання кеш-пам'яті і системних накладних витрат при виконанні програми на різних конфігураціях паралельної ЕОМ будуть видаватися різні значення корисного часу. Тому, якщо є можливість виконати програму на одному процесорі (а вона може вимагати набагато більше оперативної пам'яті, ніж є на одному процесорі), то бажано це зробити для отримання уявлення про відмінності прогнозованих часів від реального часу. По-друге, час виконання паралельної DVM-програми на одному процесорі може значно відрізнятися від часу її виконання як послідовної програми. Це може бути наслідком наступних причин: Доступ до розподілених даних в паралельній програмі відрізняється від доступу до них у послідовній програмі. Додаткові накладні витрати, що з'являються в паралельній програмі, можуть збільшити час її виконання на 10-30 відсотків. Однак у паралельній програмі може бути проведена така оптимізація доступу до даних, яка для деяких програм призведе до прискорення їх виконання у порівнянні з послідовним випадком. Трансформація програми в програму на стандартних мовах Фортран 77 чи Сі може привести до відмінностей в оптимізації програм стандартними компіляторами. У результаті, паралельна програма може виконуватися або повільніше, або швидше. Особливості оптимізації програм сучасними компіляторами істотно (десятки і сотні відсотків) визначають ефективність їх виконання. Деякі накладні витрати на підтримку виконання паралельної програми можуть значно сповільнити її виконання (наприклад, операції запиту і звільнення пам'яті в послідовній програмі можуть перетворитися в паралельній програмі в набагато більш складні операції створення та знищення розподіленого масиву).
Тому, якщо є можливість виконати програму як звичайну послідовну програму на одному процесорі (якщо це не можна зробити на паралельній ЕОМ, то може бути це виявиться можливим на робочій станції), то бажано це зробити. Все це користувачеві необхідно мати на увазі, приступаючи до аналізу втраченого часу і його компонент. Спочатку слід оцінити три компоненти втраченого часу для інтервалу нульового рівня (всієї програми). Найбільш ймовірно, що основна частка втраченого часу припадає на одну з перших двох компонент (недостатній паралелізм чи комунікації). У разі якщо причиною виявився недостатній паралелізм, необхідно уточнити, на яких ділянках він виявлений - послідовних або паралельних. В останньому випадку причина може бути дуже простий - невірне завдання матриці процесорів при запуску програми або невірне розподіл даних і обчислень. Якщо ж недостатній паралелізм виявлений на послідовних ділянках, то причиною цього, швидше за все, є наявність послідовного циклу, виконує великий обсяг обчислень. Усунення цієї причини може потребувати великих зусиль. У тому ж випадку, якщо основною причиною втрат є комунікації, то необхідно, перш за все, звернути увагу на характеристику втрати через рассинхронізациі. Якщо її значення близьке до розмірів втрат через комунікацій, то необхідно розглянути характеристику розбалансування, оскільки саме розбалансування обчислень в паралельному циклі є найбільш вірогідною причиною рассинхронізациі і великих втрат на комунікаціях. Якщо величина розбалансування набагато менше величини синхронізації, то необхідно звернути увагу на величину розкиду часів колективних операцій. Якщо розсинхронізація не є наслідком розкиду часів завершення колективних операцій, то її можливою причиною можуть бути розбалансування деяких паралельних циклів, які на даному інтервалі виконання програми могли взаємно компенсуватися. Тому має сенс перейти до розгляду характеристик розбалансування на інтервалах більш низького рівня. Другий імовірною причиною великих втрат через рассинхронізациі може бути розсинхронізація процесорів, яка виникає при видачі операцій введення-виведення. Це відбувається через те, що основна робота (звернення до функцій вводу-виводу операційної системи) проводиться на процесорі введення-виведення, а інші процесори в цей час чекають отримання від нього даних або інформації про завершення колективної операції. Цю причину втрат легко виявити, звернувши увагу на відповідну компоненту характеристики комунікації - втрати з-за комунікацій при введенні-висновку. Ще однією причиною великих втрат через комунікацій можуть виявитися затримки при запуску колективних операцій в асинхронному режимі, що виникають із-за того, що деякі реалізації MPI не забезпечують поєднання обчислень з обмінами. Можливий і інший підхід до аналізу характеристик, коли спочатку аналізуються коефіцієнти ефективності і втрачений час на різних інтервалах першого рівня, потім другого рівня, і т.д. У результаті визначається критичний ділянку програми, на аналіз характеристик якого і спрямовуються основні зусилля. При цьому необхідно мати на увазі, що причиною втрат на даному інтервалі через рассинхронізациі і простоїв можуть бути розбалансування і розкид часів не тільки на цьому інтервалі, а й на інших, що виконувалися до нього інтервалах. При налагодженні продуктивності програми користувач не обов'язково повинен запускати її з тим великим обсягом обчислень, який характерний для використання програми при вирішенні реальних завдань. Він може обмежити, наприклад, кількість регулярно повторюваних зовнішніх ітерацій до однієї - двох ітерацій. При цьому коефіцієнт ефективності програми, істотно залежить від втрат на тих ділянках програми, які виконуються до початку першої ітерації або після закінчення останньої ітерації, може значно знизитися. Проте користувач може оформити виконання зовнішніх ітерацій у вигляді окремого інтервалу (але при цьому треба враховувати той факт, що виконання першої ітерації може супроводжуватися значними затримками через динамічної подзагрузкі програми з файлової системи) і налагоджувати його продуктивність за тією ж методикою, яка була описана вище стосовно до програми цілком. 5. Засіб аналізу ефективності MPI програм 5.1 Постановка завдання У системі DVM існують розвинені засоби аналізу ефективності виконання паралельної DVM-програми. Ці кошти є більш потужними, ніж ті, які існують для MPI-програм, оскільки багато важливих характеристик виконання MPI-програм (наприклад, співвідношення паралельних і послідовних обчислень) неможливо визначити через відсутність необхідної інформації. Крім того, в даний час при розробці MPI-програм у нас в країні практично не використовуються інструментальні засоби налагодження ефективності. Це викликано наступними основними факторами: - різні засоби вимагають від користувача знання їх власного інтерфейсу (відсутність фактичного стандарту); - відсутністю взагалі будь-яких інструментальних засобів аналізу ефективності на багатьох паралельних ЕОМ. Тому важливо створити такі кошти для отримання характеристик ефективності MPI-програм, які могли б бути доступні користувачам на будь-яких багатопроцесорних ЕОМ. Метою даної дипломної роботи є створення експериментальної системи налагодження ефективності MPI-програм. Вхідними даними для неї будуть траси, створювані DVM-системою для функціональної налагодження MPI-програм. У цих трасах відображені звернення до MPI-функцій і часи їх роботи. Для отримання характеристик, аналогічних тим, які видаються для DVM-програм, від програміста буде потрібна додаткова інформація про те, які обчислення є паралельними, а які послідовними (дубльованими на кожному процесорі). Ці вказівки повинні бути оформлені таким чином, що їх наявність в MPI-програмі не заважало її правильному та ефективному виконанню на тих ЕОМ, де відсутня дана система налагодження ефективності MPI-програм. Таким же чином мають оформлятися і засоби опису тих інтервалів виконання програми, для яких потрібно окремо збирати всі характеристики ефективності. Етапи роботи аналізатора. У роботі аналізатора можна виділити наступні етапи. Етап 1 Обробка трас з усіх процесорів і обчислення для кожного інтервалу і кожного процесора наступних характеристик: Основні характеристики та їх компоненти Коефіцієнт ефективності (Parallelization efficiency) дорівнює відношенню корисного часу до загального часу використання процесорів. Час виконання (Execution time). Число використовуваних процесорів (Processors). Загальний час використання процесорів (Total time) - добуток часу виконання (Execution time) на число використовуваних процесорів (Processors). Корисне час (Productive time) - прогнозоване час виконання на одному процесорі Втрачений час (Lost time). Комунікації (Communication) та всі компоненти. Простої (Idle time). Розбалансування (Load _ Imbalance). Потенційні втрати через синхронізації (Synchronization) та всі компоненти. Потенційні втрати через розкиду часів (Time _ variation) та всі компоненти. Характеристики виконання програми на кожному процесорі Втрачений час (Lost time) - сума його складових - втрат через недостатнє паралелізму (User insufficient _ par), системних втрат через недостатнє паралелізму (Sys insufficient _ par), комунікацій (Communication) і простоїв (Idle time). Простої на даному процесорі (Idle time) - різниця між максимальним часом виконання інтервалу (на якомусь процесорі) і часом його виконання на даному процесорі. Загальний час комунікацій (Communication). Реальні втрати через рассинхронізациі (Real synchronization). Потенційні втрати через розкиду часів (Variation). Розбалансування (Load _ imbalance) обчислюється як різниця між максимальним процесорним часом (CPU + MPI) і відповідним часом на даному процесорі. Час виконання інтервалу (Execution _ time). Корисне процесорний час (User CPU_time). Корисне системний час (MPI time). Число використовуваних процесорів для даного інтервалу (Processors). Часи комунікацій для всіх типів колективних операцій Реальні втрати через рассинхронізациі для всіх типів колективних операцій. Потенційні втрати через рассинхронізациі для всіх типів колективних операцій. Потенційні втрати через розкиду часів для всіх типів колективних операцій. Етап 2 Підготовка текстового формату обчислених характеристик. Таке уявлення спрощує первинний аналіз характеристик при запуску паралельної програми на віддаленій ЕОМ. Етап 3 Візуалізація результатів аналізу ефективності. Підсистема візуалізації повинна забезпечити графічне представлення обчислених характеристик ефективності і допомогти користувачу їх досліджувати - дозволити з різним ступенем подробиці переглядати історію виконання програми і пояснювати, як були обчислені ті чи інші характеристики. 5.3 Пристрій аналізатора Отже, аналізатор складається з трьох основних компонентів. Перша - збір інформації по трасі. Друга - аналіз зібраних даних. Третя - візуалізація. 5.3.1 Збір траси При кожному запуску паралельної програми в режимі трасування, створюється група файлів з інформацією про всі ключові події в трасі. Тут є часи і параметри всіх подій, які мали місце при виконанні програми. До цих даних є можливість доступу через спеціальні функції інтерфейсу. Також можна отримати інформацію для різного роду допоміжних таблиць (імена використовуваних функцій, вихідних файлів і т.п.). Далі отримані дані надходять на вхід модулям аналізу та збору характеристик. 5.3.2 Аналіз Відповідно до описаної в пункті 4.2 методикою, вся програма буде розбита на систему інтервалів, точніше дерево інтервалів. Коренем дерева буде вся програма, вона вважається інтервалом нульового рівня. Далі відповідно до вкладеністю інтервали першого рівня і т.д. Як вказати межі інтервалів? Для цього використовуються пара функцій MPI_Send () і MPI _ Recv () для вказівки початку інтервалу, і така ж пара для зазначення його закінчення. При цьому здійснювати або отримувати повідомлення відбуваються самому собі і від самого себе (мається на увазі, що в якості номера відправника / одержувача використовується номер самого процесу). Крім того, тег повідомлення має наступний вигляд: TAG = 0 x (aa) (id) (aa / bb). Тег є чотирибайтових цілим числом. Перший байт у «нашого» тега - це 0 xaa. Це дозволяє відрізнити його від звичайних посилок / прийомів повідомлень. Останній байт може бути 0 xaa - символізує початок інтервалу, 0 xbb - кінець інтервалу. Усередині спеціальний ідентифікатор інтервалу (2 байти), його можна використовувати, наприклад, для того, щоб окремо виділити ітерації циклу. Такий спосіб виділення був обраний тому, що: він завжди потрапляє в трасування (деякі спеціальні функції начебто MPI _ Pcontrol () в поточній версії трасувальника не потрапляють). займає відносно небагато часу (близько 100 тиків процесора). простий у використанні і не вимагає додаткових коштів, крім стандартних MPI-функцій.
Таким чином, програміст може додати до свого код кордону цікавлять його областей програми (у нашій термінології інтервали). Далі за цим тегам серед усіх подій будуть знайдені ті, які є межами інтервалів і будуть визначені їх ідентифікатори. Для цього вводиться спеціальний клас: class Margin { public: Margin (bool, unsigned long, int, unsigned int, int); friend bool operator <(const Margin & s1, const Margin & s2) bool enter_leave; unsigned long time; int identity; unsigned int proc; unsigned int scl; }; І функція: vector <Margin> * createMargins (void); яка і обчислює => визначає необхідні кордону разом з усіма параметрами. Після визначення меж, створюється структура дерево, в якій зберігаються всі дані про всі інтервалах. Коротко про використовувані структурах даних. Створено спеціальний клас tree: class tree { public: static int Intervallevel; / / current interval level static int IntervalID; / / current interval ID long index; int level; / / Interval level int EXE_count; int source_line; string source_file; int ID; / / Characteristics for every interval unsigned long Exec_time; unsigned long Productive_time; double Efficiency; unsigned long CPU_time; unsigned long MPI_time; unsigned long Lost_time; unsigned long Comm_time; unsigned long SendRecv_time; unsigned long CollectiveAll_time; unsigned long Idle_time; unsigned long AllToAll_time; unsigned long Time_variation; unsigned long Potent_sync; unsigned long T_start; vector <pair <unsigned long,unsigned int>> * cmp_pairs; / / For intelval's tree tree * parent_interval; int count; vector <tree *> nested_intervals; vector <Processors> Procs; }; Цей клас містить інформацію про всі характеристики даного інтервалу, описаних у 5.2. Крім того, в ньому є інформація про батьківський вузлі дерева, а також про всі «листках-нащадків». У цьому класі в якості допоміжного використовується клас Processors. class Processors { public: unsigned long enter_time; unsigned long leave_time; unsigned int number; unsigned long MPI_time; unsigned long SendRecv_time; unsigned long CollectiveAll_time; unsigned long Idle_time; unsigned long AllToAll_time; unsigned long CPU_time; unsigned long Comm_time; unsigned long Time_variation; unsigned long Potent_sync; unsigned long T_start; }; У цьому класі містяться елементарні складові всіх компонентів, зібрані на кожному інтервалі кожного процесора. Далі, після визначення меж інтервалів, відбувається створення дерева інтервалів. У цьому дереві і буде зберігатися інформація про всі інтервалах. Клас tree включає методи, які і збирають інформацію зі структур, зібраних на трасі. Перша група характеристик збирається у функції Leave (int line, char * file, long index, unsigned int proc, unsigned long time). MPI_time Використовуємо - getMPITimebyProc (); SendRecv_time - getSendRecvCommunicationTimebyProc (); CollectiveAll_time - getCollectiveAllByProc (); AllToAll_time - getAllToAllByProc (); Potent_sync - getPotentSyncByProc (); Time_variation - getTimeVariationByProc (); T_start - getNonBlockedTimebyProc ();
Обчислення характеристик. getMPITimebyProc () - Відбувається підсумовування інтервалів часу, зайнятих під MPI-функції (інтервали виходять як різниця між часом виходу і входу в MPI-функцію). getSendRecvCommunicationTimebyProc () - Відбувається підсумовування інтервалів часу, що обчислюються як різниця часу виходу з функції прийому повідомлення і часу входу у функцію посилки повідомлення. getPotentSyncByProc () - Обчислюється по-різному для операцій одиночних посилок / прийомів повідомлень і колективних операцій. Сюди входять всі випадки, коли Recv був виданий раніше Send 'а. Ці «затримки» як раз і сумуються. Для колективних же операцій підсумовується час «затримки» старту операції на деяких процесорах. getTimeVariationByProc () - Обчислюється час, рассинхронізациі закінчення колективній операції. getNonBlockedTimebyProc () - Обчислюється аналогічно getMPITimebyProc (), тільки підсумовуються часи роботи тільки не блокують операцій. Всі ці характеристики збираються на кожному процесорі для даного інтервалу. Прототип всіх функцій однаковий: getFunction (unsigned long enter_time, unsigned long leave_time, unsigned int proc). Зібрані «елементарні» характеристики, потім збираються в більш загальні по всьому інтервалу. Перша використовувана для цього функція - це функція Integrate (). У цій функції збираються наступні характеристики: Всі вони вже є характеристиками всього інтервалу. Далі відбувається обчислення вже не загальних, а порівняльних характеристик. Знаючи всі ці компоненти на кожному процесорі для інтервалу, ми знаходимо процесори з максимальним, мінімальним значенням за часом, а також середнє значення всіх характеристик. Після функції Integrate () обчислюється корисний час calculateProductive (), потім час запуску - calculateExecution (), ефективність розпаралелювання - efficiency (), і, нарешті, втрачений час - calculateLost (). На цьому збір та аналіз інформації закінчуються. Наступний етап, це генерація відповідних текстових видач. Ці видачі представляють собою текстовий файл і мають такий вигляд (Приклад). Приклад. Текстовий файл з підсумковими характеристиками. Interval (LineNumber = 153 SourceFile = exch.c) Level = 0 EXE_Count = 1 --- Main Characteristics --- Parallelization Efficiency 0.978833 Execution Time 2.079975 Processors 4 Total Time 8.319900 Productive Time 8.143794 (CPU MPI) MPI час на одному процесорі вважається корисним, а на інших - втраченим Lost Time 0.176106 --- MPI Time 0.173490 --- Idle Time 0.002616 Communication Time 0.076563 ***** SendRecv Time 0.013295 ***** CollectiveAll Time 0.063268 ***** AllToAll Time 0.000000 Potential Sync. 0.068763 Time Variation 0.001790 Time of Start 0.000000 --- Comparative Characteristics --- Tmin Nproc Tmax Nproc Tmid Lost Time 0.033087 3 0.060057 0 0.044026 Idle Time 0.000000 1 0.000898 0 0.000654 Comm. Time 0.006597 3 0.034854 0 0.019140 MPI Time 0.032259 3 0.059159 0 0.043372 Potential Sync. 0.001800 0 0.029369 3 0.017190 Time variation 0.000161 1 0.000607 3 0.000447 Time of Start 0.000000 0 0.000000 0 0.000000 Для кожного інтервалу видається наступна інформація: ім'я файлу з вихідним текстом MPI-програми та номер першого оператора інтервалу в ньому (SourceFile, LineNumber); номер рівня вкладеності (Level); кількість входів (і виходів) в інтервал (EXE _ Count); основні характеристики виконання та їх компоненти (Main characteristics); мінімальні, максимальні і середні значення характеристик виконання програми на кожному процесорі (Comparative characteristics);
При видачі характеристик їх компоненти розташовуються в тій же рядку (праворуч у дужках), або в наступному рядку (праворуч від символів "*" або "-"). Інформація про мінімальні, максимальних і середніх значеннях характеристик оформлена в таблицю. Також є інформація про всі характеристики на кожному процесорі. Візуалізація
Наступним етапом після того, як всі необхідні характеристики зібрані, є етап візуалізації. Цей етап необхідний, так як хоча текстовий файл містить всю необхідну інформацію, при великому числі інтервалів користуватися ним не дуже зручно. Здається доцільним, що, так як інтервали "відображалися" логічно у вигляді дерева, то і візуалізувати їх потрібно у вигляді дерева. Було обрано форма відображення, аналогічна деревоподібної організації файлової структури даних на дисках. Відповідно, кожен інтервал доступний з свого батька, інтервали нижніх рівнів відображаються правіше. Також при натисканні на інтервал, в текстове поле виводиться інформація про всі характеристики саме цього інтервалу. Це значно полегшує пошук необхідної для аналізу галузі. 
Рис.6. Вікно програми аналізу. Також корисним для уявлення загальної картини запуску є упорядкований за часом список подій. При цьому використовується так званий (TimeLine), всі події відображаються на лінії певним кольором відповідно до часу, коли вони відбулися. Це дозволяє відслідковувати не просто потрібну область, а точно цікавить подія. Використовуючи механізм Tooltip 'ів, користувач отримує можливість дізнатися тип події (призначений для користувача (UserCode) або MPI) та назва функції (для MPI - функцій).
Рис.7. TimeLine Довідатися про це можна за кольором лінії з подією. Список кольорів описаний в Додатку 2. Висновок У даній роботі досліджувалися можливості аналізу ефективності MPI-програм. Було розроблено власне програмне засіб, що використовує підходи, що застосовуються в DVM-системі. Приблизний обсяг програми на С + + в рядках коду = 6500 рядків. Програма відтестовано на тестах, що поставляються з MPI - реалізаціями, а також з тестами NAS (NPB 2.3), з додаванням описаних вище директив для меж інтервалу. У процесі дипломної роботи були: Проаналізовано сучасні засоби аналізу паралельних програм. Вивчено алгоритми аналізу та збору характеристик. Реалізовано програмний засіб з наступними можливостями: Відображення виконання програми у вигляді дерева інтервалів Збір і відображення характеристик обраного інтервалу. Видача загальної інформації про всі інтервалах в текстовий файл. Показ time - line.
Висновки: Налагодження ефективності паралельних програм - процес дуже складний і трудомісткий Розвинені засоби аналізу ефективності можуть істотно прискорити цей процес. Необхідна грамотна - наочна візуалізація результатів. Для досягнення ефективності паралельної програми доводиться багато разів змінювати програму, іноді кардинально змінюючи схему її розпаралелювання. Тому важливо використовувати високорівневі засоби розробки паралельних програм Необхідно враховувати різні ефекти, пов'язані з нестабільністю поведінки паралельних програм.
Надалі планується вести роботу в напрямку інтелектуалізації системи. Бажано отримання автоматичних рад користувачеві-програмісту щодо поліпшення ефективності програми. Це допоможе спростити рішення традиційних складнощів, що виникають на шляху налагодження паралельної програми. Додаток 1 Структура програми. Модуль main - виклик процедур збору інформації, аналізу і генерації результату. Compute - обчислення все необхідних характеристик траси. Для цього використовується модуль tree, який відповідає за формування дерева з даними про шуканих характеристиках. Модуль determine дозволяє знаходити і виділяти інтервали у вихідному коді і в трасі програми. Модуль visual займається графічним відображенням отриманих даних і складається і timeline - Події в трасі, і characteristics - Дерево інтервалів з відображеними характеристиками. Додаток 2 Використовувані кольори на TimeLine: 1. Колективні операції: MPI _ Barrier, MPI _ Bcast, MPI _ Gather, MPI _ Gatherv, MPI _ Scatter, MPI _ Scatterv, MPI _ Allgather, MPI _ Allgatherv, MPI _ Alltoall, MPI _ Alltoallv, MPI _ Reduce, MPI _ Allreduce, MPI _ Reduce _ scatter, MPI _ Scan чорний 2. Операції посилки MPI _ Send, MPI _ Bsend, MPI _ Ssend, MPI _ Rsend темно-зелений 3. Неблокуючим операції посилки MPI _ Isend, MPI _ Ibsend, MPI _ Issend, MPI _ Irsend світло-зелений 4. Операції отримання / очікування / посилки-отримання з блокуванням MPI _ Recv, MPI _ Wait, MPI _ Waitany, MPI _ Waitall, MPI _ Waitsome, MPI _ Probe, MPI _ Sendrecv, MPI _ Sendrecv _ replace темно-синій 5. Операції отримання / перевірки без блокування MPI_Irecv, MPI_Test, MPI_Testany, MPI_Testall, MPI_Testsome, MPI_Iprobe блакитний 6. Інші (маловикористовувані) операції MPI_Request_free, MPI_Cancel, MPI_Test_cancelled, MPI_Send_init, MPI_Bsend_init, MPI_Ssend_init, MPI_Rsend_init, MPI_Recv_init, MPI_Start, MPI_Startall світло-сірий 7. Користувальницький код світло-рожевий
Додати в блог або на сайт
Цей текст може містити помилки.
Програмування, комп'ютери, інформатика і кібернетика | Диплом
180.1кб. | скачати
Схожі роботи:
Паралельні обчислення з використанням MPI
Аналіз антивірусних програм
Етапи розробки програм Тестування та налагодження Документування програм
Порівняльний аналіз сучасних антивірусних програм
Основи розпаралелювання програм їх динамічний аналіз
Аналіз програм державного співфінансування пенсій
Аналіз соціальних програм по соціальному захисту населення
Аналіз соціальних програм по соціальному захисту населення
Аналіз програм ігрового мовлення каналу МУЗ-ТВ
| 