Оптимизированный профиль C ++ / C кода

Question

У меня есть некоторый сильно сшитый код на C ++, с которым я работаю. Я могу скомпилировать и профилировать с помощью инструментов AMD и спать в режиме отладки. Однако без оптимизации большая часть времени проводилась в шаблонном коде и STL. Благодаря оптимизированной компиляции все инструменты профиля, которые я знаю, производят мусорную информацию. Кто-нибудь знает хороший способ профилировать оптимизированный нативный код

PS1: Код, который я пишу, также сильно шаблонизирован. Большая часть времени, проведенного в неоптимизированном коде, будет оптимизирована. Я говорю о том, что 96-97% времени выполнения тратится в шаблонном коде без оптимизации. Это повредит точности профилирования. И да, я могу изменить много шаблонного кода или, по крайней мере, какая часть шаблонного кода создает больше проблем, и я могу добиться большего в этих местах.

Answer 1

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

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

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

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

Answer 2

Что вы подразумеваете под "мусорной информацией"?

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

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

Answer 3

Когда @kriss говорит

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

это именно то, что я собирался сказать.

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

Я не ищу такой код, измеряя время. Если избыточное время составляет, скажем, 20%, то я делаю случайную паузу несколько раз. Как только я вижу что-то, что может быть улучшено на 2 или более образцах, я обнаружил это. Это странный метод, но он ничего не пропускает. Я измеряю общее время до и после, чтобы посмотреть, сколько я сэкономил. Это можно сделать несколько раз, пока вы не сможете найти что-то, что можно исправить. (Кстати, если вы используете Linux, Zoom - более автоматизированный способ сделать это.)

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