Как профилировать многопоточное приложение C ++ в Linux?

Изменить: добавлен еще один ответ на профайлер бедняги, который ИМХО лучше для многопоточных приложений.

Взгляните на oprofile. Накладные расходы на профилирование этого инструмента незначительны, и он поддерживает многопоточные приложения - до тех пор, пока вы не хотите профилировать конфликт мьютексов (что является очень важной частью профилирования многопоточных приложений)

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

Взгляните на Valgrind.

Взгляните на Zoom.

Пол Р сказал, взгляните на Zoom. Вы также можете использовать lsstack, который является низкотехнологичным подходом, но удивительно эффективным, по сравнению с gprof.

Добавлено: поскольку вы пояснили, что используете OpenGL на скорости 33 мс, моя предыдущая рекомендация остается в силе. Кроме того, то, что я лично делал в подобных ситуациях, одновременно эффективно и не интуитивно понятно. Просто запустите его с типичной или проблемной рабочей нагрузкой, остановите его вручную и посмотрите, что он делает и почему. Сделайте это несколько раз. Теперь, если он только иногда плохо себя ведет, вы хотели бы остановить его только тогда, когда он плохо себя ведет. Это непросто, но я использовал прерывание от будильника для правильной задержки. Например, если один кадр из 100 занимает более 33 мс, в начале кадра установите таймер на 35 мс, а в конце кадра выключите его. Таким образом, он будет прерываться только тогда, когда код занимает слишком много времени, и покажет вам, почему. Конечно, один образец может пропустить виновный код, но 20 образцов его не пропустят.

Попробуйте современный инструмент профилирования Linux, perf (perf_events): https://perf.wiki.kernel.org/index.php/Tutorial и http://www.brendangregg.com/perf.html:

perf record ./application
# generates profile file perf.data
perf report

Вы можете случайным образом запустить pstack, чтобы узнать стек в заданной точке. Например. 10 или 20 раз. Наиболее типичный стек - это то место, где приложение проводит большую часть времени (согласно опыту, мы можем предположить распределение Парето).

Вы можете объединить эти знания с strace или truss (Solaris) для отслеживания системных вызовов и pmap для печати памяти.

Если приложение работает в выделенной системе, у вас также есть sar для измерения ЦП, памяти, ввода-вывода и т. Д. Для профилирования всей системы.

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

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

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

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

Я пробовал valgrind и gprof. Очень жаль, что ни один из них не работает с многопоточными приложениями. Позже я нашел Intel VTune Amplifier. Хорошо то, что он хорошо справляется с многопоточностью, работает с большинством основных языков, работает в Windows и Linux и имеет множество отличных функций профилирования. Более того, само приложение бесплатное. Однако он работает только с процессорами Intel.