Профилирование кода CFD с Callgrind

16

Я использую Valgrind + Callgrind для профилирования написанного мной решателя. Как говорится в руководстве пользователя Valgrind, я скомпилировал свой код с опциями отладки для компилятора:

«Без отладочной информации лучшее, что смогут сделать инструменты Valgrind, - это угадать, к какой функции принадлежит тот или иной фрагмент кода, что делает как сообщения об ошибках, так и результаты профилирования практически бесполезными. С -g вы получите сообщения, которые указывают непосредственно на соответствующие строки исходного кода. "

Valgrind инструкция

При компиляции с опцией отладки коды работают намного медленнее. Код CFD становится ОЧЕНЬ медленным, даже для небольших случаев, когда компилируется с флагами отладки. Valgrind делает это в 40 раз медленнее (см. Руководство 1 ).

  1. Какие инструменты вы используете для профилирования кода (профилирование, а не тестирование производительности)?

  2. Как долго вы позволяете запускать код (статистика: сколько временных шагов)?

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

tmaric
источник
3
Вы можете скомпилировать код с включенными символами отладки и включенной оптимизацией. Тем не менее, 40x через valgrind (который имитирует весь доступ к памяти) не является необоснованным.
Арон Ахмадиа
Спасибо, это то, что я прочитал также ... что я хотел бы знать, это информация о повседневном опыте профилирования (предпочтительно с valgrind): сколько времени нормально ждать отчетов, сколько итераций подсчеты мне нужны, что я могу исключить ... и т.д ...
tmaric
Ваш вопрос также немного широк. Я рекомендую отредактировать ваш вопрос, чтобы сосредоточиться на Q2.1 и Q2.2, так как Q1 - это совершенно другой вопрос (я рад, что вы задаете его отдельно, это хороший вопрос, но сформулируйте его как «Какие инструменты вы бы использовать для решения проблемы X ", где X хорошо описан!), тогда как Q2 сам по себе слишком общий.
Арон Ахмадиа
Вы можете также изменить для имени callgrind, cachegrindили massif. Многие связывают Valgrind только с инструментом по умолчанию ( memcheck). В качестве системы профилирования на основе эмуляции (а не на основе прерываний) вам не нужно долго работать.
Джед Браун
@ Aron & Jed: спасибо за советы, я редактировал вопрос. :)
tmaric

Ответы:

11

Вопрос 1: Какие инструменты вы используете для профилирования кода (профилирование, а не тестирование производительности)?

Q2: Как долго вы позволяете коду работать (статистика: сколько временных шагов)?

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

Вот пример того, как я это делаю.

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

Мне даже не нравится слово «профилирование», потому что оно вызывает в изображении нечто похожее на гистограмму, где для каждой подпрограммы есть полоса затрат, или «узкое место», потому что это означает, что в коде есть только небольшое место, которое необходимо фиксированный. Обе эти вещи подразумевают какое-то время и статистику, для которой, как вы полагаете, важна точность. Не стоит отказываться от понимания точности времени.

Использование метода I является случайной паузой, и есть полный пример и слайд - шоу здесь . Часть мировоззрения «профилировщик-узкое место» заключается в том, что если вы ничего не находите, ничего не найдете, а если вы что-то находите и получаете определенный процент ускорения, вы объявляете победу и выходите. Поклонники профилировщиков почти никогда не говорят, насколько они ускоряются, а реклама показывает только искусственно созданные проблемы, которые легко найти. Случайная пауза находит проблемы, простые они или сложные. Затем решение одной проблемы обнажает другие, поэтому процесс можно повторить, чтобы ускорить процесс.

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

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

Описание устранения нескольких проблем, чтобы получить большое ускорение

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

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

Так что для Q1 для бенчмаркинга достаточно простого таймера. Для «профилирования» я использую случайную паузу.

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

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

Майк Данлавей
источник
Майк, ты предпочитаешь делать случайную паузу в отсутствие визуальной IDE? Можно ли каким-то образом автоматизировать этот процесс?
Мэтью Эммет
@ Мэтью: я понимаю, что есть такие инструменты, как pstack и lsstack, но я действительно считаю, что этот процесс больше отладку. Таким образом, даже если лучший отладчик, который я могу использовать, - gdbэто работа. С помощью отладчика вы можете исследовать данные, и это может иметь значение, когда один только стек не скажет вам достаточно.
Майк Данлавей
9

В профайлер бедняка в основном gdbскрипт , который проб стек вызовов. Вам все еще нужно иметь отладочные символы. Это все еще медленный процесс, но поскольку он не реализует виртуальную машину, выполнение кода на ней часто выполняется быстрее callgrindи адекватнее задаче.

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

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

Чтобы добавить к доступным отличным ответам, в Rice разработан инструмент, который автоматизирует выборку из стека и поэтому имеет очень мало накладных расходов:

http://hpctoolkit.org/

Reid.Atcheson
источник
Это выглядит хорошо, хотя (извините) я надел здесь свою пламенную шляпу. Я не настраиваюсь на оптимизированный компилятором код, потому что трудно увидеть, что происходит в искаженном коде. Вещи, которые я убираю, - это не те вещи, с которыми оптимизатор мог бы иметь дело - например, вызов expи logповторение одних и тех же аргументов или матричные операции, тратящие все свои варианты декодирования времени. Я настраиваюсь так далеко, как могу, затем включаю -O3.
Майк Данлавей
Инструменты - это инструменты, и они полезны только в том случае, если пользователь знает и понимает их ограничения. Я не думаю, что когда-либо найдется «идеальный профилировщик», который полностью исключит пользователя из уравнения в отношении понимания его результатов и умения использовать информацию.
Reid.Atcheson
1

Allinea MAP является коммерчески разработанным и поддерживаемым профилировщиком выборки и, следовательно, - как HPC Toolkit, предложенный в предыдущем ответе - при желании может работать на производственных масштабах.

Этот вид инструмента указывает на узкие места ЦП или плохую связь MPI, но и полный контроль за профилированием всей работы может быть бесценным при обнаружении неожиданных проблем.

Зачастую это приводит к низким показателям производительности, которые находятся за пределами основного ядра кода CFD, в областях, которые не ожидались. Рандомизированная выборка из стека - лучший способ найти их - будь то вручную с помощью GDB или с помощью таких инструментов, как HPC Toolkit и Allinea MAP. Если что-то важно для производительности, оно появится.

Дэвид
источник