Я использую Valgrind + Callgrind для профилирования написанного мной решателя. Как говорится в руководстве пользователя Valgrind, я скомпилировал свой код с опциями отладки для компилятора:
«Без отладочной информации лучшее, что смогут сделать инструменты Valgrind, - это угадать, к какой функции принадлежит тот или иной фрагмент кода, что делает как сообщения об ошибках, так и результаты профилирования практически бесполезными. С -g вы получите сообщения, которые указывают непосредственно на соответствующие строки исходного кода. "
При компиляции с опцией отладки коды работают намного медленнее. Код CFD становится ОЧЕНЬ медленным, даже для небольших случаев, когда компилируется с флагами отладки. Valgrind делает это в 40 раз медленнее (см. Руководство 1 ).
Какие инструменты вы используете для профилирования кода (профилирование, а не тестирование производительности)?
Как долго вы позволяете запускать код (статистика: сколько временных шагов)?
Насколько велики дела (если дело помещается в кеш, решатель работает на несколько порядков быстрее, но тогда я пропущу процессы, связанные с памятью)?
callgrind,cachegrindилиmassif. Многие связывают Valgrind только с инструментом по умолчанию (memcheck). В качестве системы профилирования на основе эмуляции (а не на основе прерываний) вам не нужно долго работать.Ответы:
Вот пример того, как я это делаю.
Я отделяю бенчмаркинг (видя, сколько времени это занимает) от профилирования (определяя, как сделать это быстрее). Не важно, чтобы профилировщик был быстрым. Важно, чтобы он говорил вам, что исправить.
Мне даже не нравится слово «профилирование», потому что оно вызывает в изображении нечто похожее на гистограмму, где для каждой подпрограммы есть полоса затрат, или «узкое место», потому что это означает, что в коде есть только небольшое место, которое необходимо фиксированный. Обе эти вещи подразумевают какое-то время и статистику, для которой, как вы полагаете, важна точность. Не стоит отказываться от понимания точности времени.
Использование метода I является случайной паузой, и есть полный пример и слайд - шоу здесь . Часть мировоззрения «профилировщик-узкое место» заключается в том, что если вы ничего не находите, ничего не найдете, а если вы что-то находите и получаете определенный процент ускорения, вы объявляете победу и выходите. Поклонники профилировщиков почти никогда не говорят, насколько они ускоряются, а реклама показывает только искусственно созданные проблемы, которые легко найти. Случайная пауза находит проблемы, простые они или сложные. Затем решение одной проблемы обнажает другие, поэтому процесс можно повторить, чтобы ускорить процесс.
На моем опыте из многочисленных примеров, вот как это происходит: я могу найти одну проблему (путем случайной паузы) и исправить ее, получив ускорение на несколько процентов, скажем, на 30% или в 1,3 раза. Затем я могу сделать это снова, найти другую проблему и исправить ее, получив еще одно ускорение, может быть, менее 30%, а может и больше. Затем я могу сделать это снова, несколько раз, пока я действительно не смогу найти что-то еще, чтобы исправить. Конечным фактором ускорения является результат работы отдельных факторов, и он может быть удивительно большим - в некоторых случаях на несколько порядков.
ВСТАВЛЕНО: Просто чтобы проиллюстрировать этот последний момент. Там есть подробный пример здесь , с слайд - шоу и все файлы, показывая , как было достигнуто убыстрение 730X в ряде проблемных удалений. Первая версия заняла 2700 микросекунд на единицу работы. Проблема A была удалена, в результате чего время сократилось до 1800, а процент оставшихся проблем увеличился в 1,5 раза (2700/1800). Затем Б был удален. Этот процесс продолжался в течение шести итераций, что привело к ускорению почти на 3 порядка. Но метод профилирования должен быть действительно эффективным, потому что, если какая-либо из этих проблем не будет найдена, то есть если вы достигнете точки, когда вы ошибочно думаете, что больше ничего не может быть сделано, процесс останавливается.
ВСТАВЛЕНО: Проще говоря, вот график общего фактора ускорения, поскольку устраняются последующие проблемы:
Так что для Q1 для бенчмаркинга достаточно простого таймера. Для «профилирования» я использую случайную паузу.
Q2: я даю ему достаточно рабочей нагрузки (или просто зацикливаю), чтобы он работал достаточно долго, чтобы сделать паузу.
Q3: Во что бы то ни стало, создайте реально большую рабочую нагрузку, чтобы не пропустить проблемы с кэшем. Они будут отображаться как примеры в коде, выполняющие выборку из памяти.
источник
pstackиlsstack, но я действительно считаю, что этот процесс больше отладку. Таким образом, даже если лучший отладчик, который я могу использовать, -gdbэто работа. С помощью отладчика вы можете исследовать данные, и это может иметь значение, когда один только стек не скажет вам достаточно.В профайлер бедняка в основном
gdbскрипт , который проб стек вызовов. Вам все еще нужно иметь отладочные символы. Это все еще медленный процесс, но поскольку он не реализует виртуальную машину, выполнение кода на ней часто выполняется быстрееcallgrindи адекватнее задаче.Я работал с физическими анализаторами частиц с небольшим успехом (то есть я продемонстрировал, что в коде нет ужасных горячих точек, и для оптимизации потребуется лучший алгоритм).
источник
Чтобы добавить к доступным отличным ответам, в Rice разработан инструмент, который автоматизирует выборку из стека и поэтому имеет очень мало накладных расходов:
http://hpctoolkit.org/
источник
expиlogповторение одних и тех же аргументов или матричные операции, тратящие все свои варианты декодирования времени. Я настраиваюсь так далеко, как могу, затем включаю -O3.Allinea MAP является коммерчески разработанным и поддерживаемым профилировщиком выборки и, следовательно, - как HPC Toolkit, предложенный в предыдущем ответе - при желании может работать на производственных масштабах.
Этот вид инструмента указывает на узкие места ЦП или плохую связь MPI, но и полный контроль за профилированием всей работы может быть бесценным при обнаружении неожиданных проблем.
Зачастую это приводит к низким показателям производительности, которые находятся за пределами основного ядра кода CFD, в областях, которые не ожидались. Рандомизированная выборка из стека - лучший способ найти их - будь то вручную с помощью GDB или с помощью таких инструментов, как HPC Toolkit и Allinea MAP. Если что-то важно для производительности, оно появится.
источник