Профілювання коду CFD за допомогою Callgrind


16

Я використовую Valgrind + Callgrind для профілактики, яку я написав. Як зазначено в посібнику користувача Valgrind, я скомпілював свій код із параметрами налагодження для компілятора:

"Без інформації про налагодження найкращі інструменти Valgrind зможуть зробити - здогадатися, до якої функції належить певний код, що робить повідомлення про помилки та вихід профілів майже марними. З -g, ви отримаєте повідомлення, які вказують безпосередньо на відповідні рядки вихідного коду. "

Посібник Valgrind

При компіляції з налагодженням параметри коди працюють набагато повільніше. Код CFD стає дійсно повільним, навіть для невеликих випадків, коли його компілюють з налагодженнями прапорів. Valgrind робить його на 40 разів повільніше (див. Посібник 1 ).

  1. Які інструменти ви використовуєте для кодування профілю (профілювання, а не тестування)?

  2. Як довго ви дозволяєте коду працювати (статистика: скільки кроків часу)?

  3. Наскільки великі випадки (якщо справа вписується в кеш, вирішувач набирає порядку на швидкість, але тоді я пропущу процеси, пов'язані з пам'яттю)?


3
Ви можете компілювати код із увімкненими як символами налагодження, так і оптимізацією. І все-таки 40x через valgrind (який моделює весь доступ до пам'яті) не є розумним.
Арон Ахмадія

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

Ваше запитання також трохи широке. Рекомендую відредагувати своє питання до того, щоб зосередитись на Q2.1 та Q2.2, оскільки Q1 - це зовсім інше питання (я радий, що ви його задали окремо, це добре, але висловлюйте це як "Які інструменти ви б використовувати для вирішення задачі X ", де X добре описано!), тоді як Q2 сам по собі занадто загальний.
Арон Ахмадія

Ви можете також змінити для імені callgrind, cachegrindабо massif. Багато людей асоціюють Valgrind лише з інструментом за замовчуванням ( memcheck). Оскільки система профілювання на основі емуляції (а не на основі переривань) вам не потрібно запускати тривалий час.
Джед Браун

@Aron & Jed: дякую за поради, я відредагував це питання. :)
tmaric

Відповіді:


11

Q1: Які інструменти ви використовуєте для кодування профілю (профілювання, а не тестування)?

Q2: Як довго ви дозволяєте коду працювати (статистика: скільки кроків часу)?

Q3: Наскільки великі випадки (якщо справа вміщується в кеш-пам'яті, вирішувач набирає порядку на швидкість, але тоді я пропущу процеси, пов'язані з пам'яттю)?

Ось приклад того, як я це роблю.

Я відокремлюю тестування (бачачи, скільки часу потрібно) від профілювання (визначаючи, як зробити це швидше). Не важливо, щоб профілер був швидким. Важливо, щоб він підказував, що виправити.

Мені навіть не подобається слово "профілювання", тому що воно створює зображення щось на зразок гістограми, де є планка витрат на кожну процедуру, або "вузьке місце", тому що це означає, що в коді просто небагато місця. фіксований. Обидва ці речі передбачають певний час та статистику, для якої ви вважаєте, що точність важлива. Не варто відмовлятися від розуміння точності виконання часу.

Використання методу I є випадковою паузою, і є повний приклад і слайд - шоу тут . Частина світогляду профілера-вузького місця полягає в тому, що якщо ти нічого не знайдеш, нічого не знайдеш, і якщо ти щось знайдеш і отримаєш певний відсотковий прискорення, ти оголошуєш перемогу та кидаєш. Фанати Profiler майже ніколи не говорять про те, яку швидкість вони отримують, а реклама показує лише штучно надумані проблеми, розроблені так, щоб їх було легко знайти. Випадкова пауза знаходить проблеми, легкі вони чи важкі. Потім виправлення однієї проблеми викриває інші, тому процес можна повторити, щоб отримати складні прискорення.

На моєму досвіді з численних прикладів, ось як це відбувається: я можу знайти одну проблему (випадковою паузою) і виправити її, отримавши прискорення на деякий відсоток, скажімо, на 30% або 1,3х. Тоді я можу це зробити ще раз, знайти іншу проблему і виправити її, отримавши іншу швидкість, можливо менше 30%, а може і більше. Тоді я можу це зробити ще раз, кілька разів, поки справді не зможу знайти нічого іншого, щоб виправити. Кінцевим коефіцієнтом прискорення є діючий продукт окремих факторів, і він може бути дивовижно великим - порядки величини в деяких випадках.

ВСТАВЛЕНО: Просто для ілюстрації цієї останньої точки. Ось детальний приклад тут : слайд-шоу та всі файли, що показують, як було досягнуто прискорення 730x у серії усунення проблем. Перша версія займала 2700 мікросекунд на одиницю роботи. Проблема А була усунена, скоротивши час до 1800, і збільшив відсоток решти проблем у 1,5 рази (2700/1800). Потім Б видалили. Цей процес тривав через шість ітерацій, в результаті чого прискорилося майже 3 порядки. Але техніка профілювання повинна бути дійсно ефективною, оскільки якщо будь-яка з цих проблем не знайдена, тобто якщо ви потрапили в точку, коли ви неправильно вважаєте, нічого більше зробити не можна, процес зупиняється.

Опис усунення декількох проблем, щоб отримати велику швидкість

ВСТАВЛЕНО: Якщо говорити іншим способом, ось графік загального коефіцієнта прискорення, оскільки усуваються послідовні проблеми:

введіть тут опис зображення

Так що для Q1 для порівняльного оцінювання достатньо простого таймера. Для "профілювання" я використовую випадкові паузи.

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

Q3: Очевидно, надайте йому реально велику завантаженість, щоб ви не пропустили проблем із кешем. Вони відображатимуться як зразки в коді, що робить витяг пам'яті.


Майк, чи маєш ти перевагу, як робити випадкові паузи за відсутності візуального IDE? Чи можна певним чином автоматизувати цей процес?
Меттью Емметт

@Matthew: Я розумію , що є такі інструменти , як pstackі lsstack, але я дійсно вважаю , що це процес більше спільного з налагодженням. Тож навіть якщо найкращий налагоджувач, який я можу винести gdb, це виконає роботу. За допомогою налагоджувача ви можете вивчити дані, і це може змінити значення, коли стек сам по собі не каже вам достатньо.
Майк Данлаве

9

У профайлер бідняка в основному gdbскрипт , який проб стек викликів. Вам все одно знадобляться налагоджувальні символи. Він все ще повільний, але оскільки він не реалізує віртуальну машину, запуск коду на ньому часто швидше callgrindі адекватне завдання.

Я працював на аналізаторах фізики частинок зі скромним успіхом (тобто я продемонстрував, що код не мав жахливих гарячих точок, і оптимізація вимагала кращого алгоритму).


1
+ Відсутність доказів не є свідченням відсутності :) Те, що повинен робити цей бідолашник, - це брати менше слідів і не руйнувати їх, але дозволяти вам їх бачити. Людське око набагато краще виявляє корисні зразки, ніж прості оцінки часу функціонування, і якщо ви побачите щось, що ви могли б покращити лише на двох зразках, це допоможе значно. Частка X, яку вона збереже, - це бета-розподіл у режимі 2 / N, де N - кількість досліджених вами слідів, а коефіцієнт швидкості становитиме 1 / (1-X), який може бути великим.
Майк Данлаве

2

Щоб додати до доступних чудових відповідей, у Rice розроблений інструмент, який автоматизує вибірку стеків і, отже, має дуже невеликі накладні витрати:

http://hpctoolkit.org/


Це виглядає приємно, хоча (вибачте) я надягнув сюди свій вогняний капелюх. Я не налаштовуюсь на оптимізований компілятором код, тому що важко зрозуміти, що відбувається в розробленому коді. Те, що я обрізаю, - це не те, чим оптимізатор міг би займатися - наприклад, дзвінки expта logнеодноразові аргументи, або матричні операції, витрачаючи весь час на декодування варіантів. Налаштовую наскільки я можу, потім включаю -O3.
Майк Данлаве

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

1

Allinea MAP - це комерційно розроблений та підтримуваний пробірник вибірки, а отже, як і HPC Toolkit, запропонований у попередній відповіді, - може працювати на виробничих роботах за бажанням.

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

Найчастіше можуть бути фрукти з низьким рівнем дії, які знаходяться за межами основного ядра коду CFD, в тих областях, які не очікували. Рандомізований вибірковий вибір стеків - найкращий спосіб їх знайти вручну за допомогою GDB або за допомогою таких інструментів, як HPC Toolkit та Allinea MAP. Якщо щось важливе для виконання, воно з’явиться.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.