Как я могу профилировать код C++, работающий в Linux?

Я предполагаю, что вы используете GCC. Стандартное решение - профилировать с помощью гпроф.

Обязательно добавьте -pg в компиляцию перед профилированием:

cc -o myprog myprog.c utils.c -g -pg

Я еще не пробовал, но слышал хорошие отзывы о google-perftools. Однозначно стоит попробовать.

Связанный вопрос здесь.

Несколько других модных словечек, если gprof не выполняет эту работу за вас: Валгринд, Intel VTune, Sun DTrace.

Вы можете использовать Валгринд со следующими параметрами

valgrind --tool=callgrind ./(Your binary)

Будет создан файл с именем callgrind.out.x. Затем вы можете использовать инструмент kcachegrind, чтобы прочитать этот файл. Это даст вам графический анализ вещей с результатами, например, сколько строк стоит.

Я бы использовал Valgrind и Callgrind в качестве основы для своего набора инструментов профилирования. Важно знать, что Valgrind - это, по сути, виртуальная машина:

(wikipedia) Valgrind is in essence a virtual machine using just-in-time (JIT) compilation techniques, including dynamic recompilation. Nothing from the original program ever gets run directly on the host processor. Instead, Valgrind first translates the program into a temporary, simpler form called Intermediate Representation (IR), which is a processor-neutral, SSA-based form. After the conversion, a tool (see below) is free to do whatever transformations it would like on the IR, before Valgrind translates the IR back into machine code and lets the host processor run it.

Callgrind - это профилировщик, построенный на этом. Главное преимущество в том, что вам не нужно запускать приложение часами, чтобы получить надежный результат. Даже одной секунды запуска достаточно, чтобы получить твердые и надежные результаты, потому что Callgrind является профилировщиком не исследующий.

Еще один инструмент, созданный на основе Valgrind, - это Massif. Я использую его для профилирования использования памяти кучи. Отлично работает. Что он делает, так это то, что он дает вам снимки использования памяти - подробную информацию, ЧТО занимает КАКОЙ процент памяти, и КТО поместил ее туда. Такая информация доступна в разные моменты времени работы приложения.

Новые ядра (например, последние ядра Ubuntu) поставляются с новыми инструментами perf (apt-get install linux-tools) AKA perf_events.

Они поставляются с классическими профилировщиками выборки (справочная страница), а также потрясающим график!

Важно то, что этими инструментами может быть профилирование системы, а не просто профилирование процессов - они могут показывать взаимодействие между потоками, процессами и ядром и позволять вам понять планирование и зависимости ввода-вывода между процессами.

Это ответ на Ответ Назгоба Gprof.

Я использую Gprof последние пару дней и уже обнаружил три существенных ограничения, одно из которых я нигде еще не видел (пока):

1. Он не работает должным образом с многопоточным кодом, если вы не используете обходной путь

2. График вызовов запутывается указателями на функции. Пример: у меня есть функция под названием multithread(), которая позволяет мне многопоточно выполнять указанную функцию по указанному массиву (оба передаются как аргументы). Однако Gprof рассматривает все вызовы multithread() как эквивалентные для целей вычисления времени, проведенного у детей. Поскольку некоторые функции, которые я передаю multithread(), занимают намного больше времени, чем другие, мои графики вызовов в основном бесполезны. (Тем, кто задается вопросом, является ли здесь проблема многопоточности: нет, multithread() может опционально, и в данном случае действительно выполнял все операции последовательно только в вызывающем потоке).

3. В здесь сказано, что «... цифры количества вызовов получены путем подсчета, а не выборки. Они полностью точны ...». Тем не менее, я обнаружил, что мой график вызовов дает мне 5345859132 + 784984078 в качестве статистики вызовов для моей наиболее вызываемой функции, где первое число должно быть прямым вызовом, а второе - рекурсивным вызовом (которые все исходят от него самого). Поскольку это означало, что у меня есть ошибка, я вставил длинные (64-битные) счетчики в код и повторил то же самое. Мои подсчеты: 5345859132 прямых и 78094395406 саморекурсивных вызовов. Здесь много цифр, поэтому я отмечу, что рекурсивные вызовы, которые я измеряю, составляют 78 миллиардов по сравнению с 784 миллионами у Gprof: множитель в 100 разный. Оба прогона были однопоточными и неоптимизированным кодом, один компилировал -g, а другой - -pg.

Это был GNU Gprof (GNU Binutils для Debian) 2.18.0.20080103, работающий под 64-битным Debian Lenny, если это кому-то поможет.

Ответ на вопрос о запуске valgrind --tool=callgrind не будет полным без некоторых опций. Обычно мы не хотим профилировать 10 минут медленного запуска под Valgrind и хотим профилировать нашу программу, когда она выполняет какую-то задачу.

Вот что я рекомендую. Сначала запустите программу:

valgrind --tool=callgrind --dump-instr=yes -v --instr-atstart=no ./binary > tmp

Теперь, когда он работает, и мы хотим начать профилирование, мы должны запустить его в другом окне:

callgrind_control -i on

Это включает профилирование. Чтобы выключить его и остановить всю задачу, мы можем использовать:

callgrind_control -k

Теперь у нас есть несколько файлов с именем callgrind.out. * В текущем каталоге. Чтобы увидеть результаты профилирования, используйте:

kcachegrind callgrind.out.*

Я рекомендую в следующем окне щелкнуть заголовок столбца «Я», иначе он показывает, что «main ()» - это наиболее трудоемкая задача. «Я» показывает, сколько времени занимала каждая функция, а не иждивенцы.

Вот два метода, которые я использую для ускорения кода:

Для приложений с привязкой к ЦП:

1. Используйте профилировщик в режиме DEBUG для выявления сомнительных частей вашего кода.
2. Затем переключитесь в режим RELEASE и закомментируйте сомнительные участки кода (ничего не заглушите), пока не увидите изменения в производительности.

Для приложений с привязкой к вводу-выводу:

1. Используйте профилировщик в режиме RELEASE, чтобы определить сомнительные части вашего кода.

N.B.

Если у вас нет профилировщика, используйте профилировщик бедняков. Нажмите паузу во время отладки вашего приложения. Большинство пакетов разработчика разбиваются на сборку с закомментированными номерами строк. По статистике, вы попадете в регион, который потребляет большую часть циклов вашего процессора.

Для ЦП причина профилирования в режиме ОТЛАЖИВАТЬ заключается в том, что если вы попробуете профилирование в режиме РЕЛИЗ, компилятор будет сокращать математические вычисления, векторизовать циклы и встроенные функции, что имеет тенденцию превращать ваш код в неразрешимый беспорядок при его сборке. Неподписываемый беспорядок означает, что ваш профилировщик не сможет четко определить, что занимает так много времени, потому что сборка может не соответствовать исходному коду при оптимизации.. Если вам нужна производительность (например, чувствительная к времени) режима РЕЛИЗ, отключите функции отладчика по мере необходимости, чтобы поддерживать работоспособную производительность.

Для привязки к вводу-выводу профилировщик все еще может идентифицировать операции ввода-вывода в режиме РЕЛИЗ, потому что операции ввода-вывода либо связаны извне с общей библиотекой (большую часть времени), либо, в худшем случае, приведут к сис- теме вектор прерывания вызова (который также легко идентифицируется профилировщиком).

Используйте Valgrind, callgrind и kcachegrind:

valgrind --tool=callgrind ./(Your binary)

генерирует callgrind.out.x. Прочтите это с помощью kcachegrind.

Используйте gprof (add -pg):

cc -o myprog myprog.c utils.c -g -pg 

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

Используйте google-perftools:

Использует временную выборку, выявляются узкие места ввода-вывода и процессора.

Intel VTune - лучший (бесплатно для образовательных целей).

Другие: AMD Codeanalyst (поскольку заменен на AMD CodeXL), OProfile, инструменты perf (apt-get install linux-tools)

Для однопоточных программ вы можете использовать игпроф, The Ignominous Profiler: https://igprof.org/.

Это профилировщик выборки, аналогичный ... длинному ... ответу Майка Данлэйви, который в подарок обернет результаты в просматриваемое дерево стека вызовов, аннотированное временем или памятью, потраченной на каждую функцию, либо кумулятивно, либо за функцию.

Также стоит упомянуть

1. HPCToolkit (http://hpctoolkit.org/) - с открытым исходным кодом, работает для параллельных программ и имеет графический интерфейс, с помощью которого можно просматривать результаты несколькими способами.
2. Intel VTune (https://software.intel.com/en-us/vtune) - Если у вас есть компиляторы Intel, это очень хорошо
3. TAU (http://www.cs.uoregon.edu/research/tau/home.php)

Я использовал HPCToolkit и VTune, и они очень эффективны для поиска длинного столба в палатке и не нуждаются в перекомпиляции кода (за исключением того, что вам нужно использовать сборку типа -g -O или RelWithDebInfo в CMake для получения значимого вывода) . Я слышал, что TAU похожи по возможностям.

Вы можете использовать библиотеку iprof:

https://gitlab.com/Neurochrom/iprof

https://github.com/Neurochrom/iprof

Он кроссплатформенный и позволяет не измерять производительность вашего приложения также в режиме реального времени. Вы даже можете связать это с живым графиком. Полный отказ от ответственности: я являюсь автором.

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

Он написан на C++ и должен быть адаптирован к вашим потребностям. К сожалению, я не могу поделиться кодом, только концепциями. Вы используете «большой» буфер volatile, содержащий временные метки и идентификатор события, который вы можете выгрузить после смерти или после остановки системы регистрации (и выгрузить это, например, в файл).

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

Вы настраиваете количество генерируемых событий, чтобы сосредоточиться исключительно на том, что вы хотите. Это очень помогло нам в решении проблем с планированием при потреблении необходимого количества ЦП, исходя из количества регистрируемых событий в секунду.

Вам нужно 3 файла:

toolname.hpp // interface
toolname.cpp // code
tool_events_id.hpp // Events ID

Идея состоит в том, чтобы определять события в tool_events_id.hpp следующим образом:

// EVENT_NAME                         ID      BEGIN_END BG_COLOR NAME
#define SOCK_PDU_RECV_D               0x0301  //@D00301 BGEEAAAA # TX_PDU_Recv
#define SOCK_PDU_RECV_F               0x0302  //@F00301 BGEEAAAA # TX_PDU_Recv

Вы также определяете несколько функций в toolname.hpp:

#define LOG_LEVEL_ERROR 0
#define LOG_LEVEL_WARN 1
// ...

void init(void);
void probe(id,payload);
// etc

Где бы вы ни находились в коде, вы можете использовать:

toolname<LOG_LEVEL>::log(EVENT_NAME,VALUE);

Функция probe использует несколько сборочных линий для получения метки времени часов как можно скорее, а затем устанавливает запись в буфере. У нас также есть атомарное приращение, чтобы безопасно найти индекс, где хранить событие журнала. Конечно буфер круглый.

Надеюсь, идея не запуталась из-за отсутствия образца кода.

Вы можете использовать структуру ведения журнала, такую ​​как loguru, поскольку она включает временные метки и общее время безотказной работы, которые можно удобно использовать для профилирования:

Поскольку никто не упомянул Arm MAP, я бы добавил его, поскольку лично я успешно использовал Map для профилирования научной программы на C++.

Arm MAP - это профилировщик для параллельных, многопоточных или однопоточных кодов C, C++, Fortran и F90. Он обеспечивает углубленный анализ и определение узких мест в строке источника. В отличие от большинства профилировщиков, он предназначен для профилирования потоков pthread, OpenMP или MPI для параллельного и многопоточного кода.

MAP - коммерческое программное обеспечение.

На самом деле немного удивлен, что не многие упомянули о гугл / эталон, в то время как немного громоздко закрепить конкретную область кода, особенно если база кода немного большая, однако я нашел это действительно полезным при использовании в сочетании с callgrind

ИМХО, ключевым моментом здесь является определение того, что вызывает узкое место. Однако я сначала попробую ответить на следующие вопросы и выберу инструмент на основе этого

1. мой алгоритм правильный?
2. есть ли замки, которые оказались узкими местами?
3. есть ли конкретный раздел кода, который является виновником?
4. как насчет ввода-вывода, обработанного и оптимизированного?

valgrind с комбинацией callrind и kcachegrind должен дать достойную оценку по вышеперечисленным пунктам, и как только будет установлено, что есть проблемы с некоторым разделом кода, я бы посоветовал сделать микротест google benchmark - хорошее место для начала.

Используйте флаг -pg при компиляции и компоновке кода и запустите исполняемый файл. Пока эта программа выполняется, данные профилирования собираются в файле a.out.
. Существует два разных типа профилирования

1- Плоское профилирование:
запустив команду gprog --flat-profile a.out, вы получите следующие данные
- какой процент от общего времени был потрачен на выполнение функции,
- сколько секунд было потрачено на выполнение функции, включая и исключая вызовы подфункций,
- количество звонков,
- среднее время одного звонка.

2- графическое профилирование используйте команду gprof --graph a.out, чтобы получить следующие данные для каждой функции, которая включает
- В каждом разделе одна функция отмечена порядковым номером. - Над функцией находится список функций, которые вызывают функцию .
- Ниже функции есть список функций, которые вызываются функцией .

Чтобы получить больше информации, вы можете посмотреть https://sourceware.org/binutils/docs-2.32/gprof/

использовать программное обеспечение для отладки как определить, где код работает медленно?

просто подумайте, что у вас есть препятствие, пока вы в движении, тогда ваша скорость уменьшится

как это нежелательное перераспределение циклов, переполнение буфера, поиск, утечки памяти и т. д. операции потребляют больше мощности выполнения, что отрицательно сказывается на производительности кода, Не забудьте добавить -pg в компиляцию перед профилированием:

g++ your_prg.cpp -pg или cc my_program.cpp -g -pg в соответствии с вашим компилятором

еще не пробовал, но слышал хорошие отзывы о google-perftools. Однозначно стоит попробовать.

valgrind --tool=callgrind ./(Your binary)

Будет создан файл с именем gmon.out или callgrind.out.x. Затем вы можете использовать kcachegrind или инструмент отладчика для чтения этого файла. Это даст вам графический анализ вещей с результатами, например, сколько строк стоит.

я думаю так