Способи візуалізації даних про події в пошуку питань щодо ефективності

Я намагаюся оптимізувати MPI-додаток із сильно асинхронною схемою зв'язку. Кожен ранг має перелік речей, які потрібно обчислити, і надсилає повідомлення за необхідності, якщо входи або виходи знаходяться в іншому рангу. Крім того, кожен ранг є потоковим (наразі з однією комунікаційною ниткою та 5 робітниками).

Я інструментував код з таймерами навколо різних критичних частин коду, що дає мені список трійки (початок, кінець, тип) для кожного потоку. Накреслений очевидним чином, з часом, як горизонтальна вісь, ранг і нитка як вертикальна, і колір, що вказує, що кожна нитка зараз робить, я отримую подібне зображення для 16 рангів з 6 нитками / рангом:

Моє запитання: які ще способи візуалізації цих даних можуть допомогти вирішити проблеми з ефективністю? Хтось має улюблений тип сюжету, який він використовує під час профілювання асинхронних програм?

Цей набір даних обмежений тим, що він не знає структури потоку даних, але я хотів би отримати якомога більше інформації про нього, перш ніж намагатися зібрати щось складніше.

Незжаті зображення тут в разі , якщо хто -то хоче , щоб озирнутися (це не вдалося завантажити через нормальний маршрут). На жаль, Firefox не приймає його, хоча я вважаю, що він дійсний, можливо, тому що він занадто великий.

Я витрачаю багато часу на написання та налагодження паралельного коду як із спільною та / або розподіленою пам’яттю, але не знаючи вашої конкретної проблеми, я можу лише сказати вам, що для мене найкраще працює.

Знаючи, які процедури займають скільки часу, це важлива річ, якщо ви дивитесь на обчислювальну ефективність, але якщо ви переживаєте за паралельну ефективність, то вам слід більше турбуватися про те, що робить ваш код, коли він не робить жодних обчислень. Як би хвилюватися, що роблять діти, коли занадто тихо ...

Оскільки ви використовуєте гібридний підхід із розділеною / розподіленою пам'яттю, я думаю, що ваш код в заготовках або очікує на MPI-виклик, або на змінну mutex / умова. Ви також можете зафіксувати ці дзвінки в таймерах, і це дасть вам кращу картину того, що сповільнює вас, наприклад, якщо це завжди однаково або завжди те саме, MPI_REDUCEщо ваші потоки застрягають.

Одне програмне забезпечення, яке я використовую досить часто, - це Intel Vtune Amplifier XE . Він має приємну схему / опцію побудови, яка візуалізує паралельність потоку. Програма намалює сюжет, дуже подібний до вашого, але коли нитка чекає на мютекс або змінну умови, вона намалює діагональну лінію з потоку очікування, у той момент, коли вона почала очікувати, до потоку, який фактично випустив мютекс або сигналізував стан, якого він чекав, під час звільнення / сигналізації. Це може бути дуже безладним, але це робить вузькі місця негайно.

Нарешті, я також збираю групові статистичні дані, наприклад, для кожного мутексу / сигналу / MPI-дзвінка, які були середні та максимальні терміни очікування? Яка гістограма зібраних термінів очікування? Незважаючи на те, що сюжет дає хороший огляд, він може стати досить безладним, коли йдеться про дрібні деталі.

Нарешті, одне питання, яке не варто недооцінювати: як ви збираєте таймінги? Ваш таймер недостатньо нав'язливий, щоб не впливати на ваш код? Я використовую кількість інструкцій процесора, коли це можливо, тобто RDTSCдля x86 архітектур. Зазвичай це просто додає одну інструкцію до вашого коду.

Іноді можна отримати альтернативне уявлення про проблеми продуктивності за допомогою аналізу ресурсів високого рівня: Чи є відповідне вузьке місце, наприклад, пропускна здатність пам'яті? Чи кожен робочий потік виконує однакову кількість роботи? Ці дані можуть бути легко зібрані за допомогою likwid-perfctr з набору інструментів LIKWID з проекту коду LIKWID Google . Якщо профіль такий, що існує багато різних гарячих точок, вам може знадобитися вирішувати їх по черзі. Також можуть виникати різні проблеми, залежно від кількості потоків / процесів.

Коли у мене виникають проблеми в мережі сильно асинхронних процесів, керованих повідомленнями або подіями, я використовую метод, який непростий, але ефективний. Він передбачав отримання часописних журналів процесів, об'єднання їх у загальну часову шкалу та відстеження прогресу деяких повідомлень під час запуску діяльності, запускаючи подальші повідомлення. Я шукаю - це затримка між часом отримання повідомлення та моментом його дії та розумінням причини затримки. Коли проблема знайдена, вона виправляється, і процес повторюється. Таким чином, ви можете отримати справді задоволення від продуктивності.

Важливо бачити, чим це відрізняється від підходів, де ви вимірюєте, вимірюєте, вимірюєте. Єдине, що можна точно сказати тобі, - це не дивитись. Справжня настройка продуктивності вимагає уважного вивчення деталей з часової точки зору. Те, що ви шукаєте, не там, де витрачається час, а там, де він витрачається без потреби.

Удачі.