Я использую Intel VTune Amplifier XE 2011 для анализа производительности моей программы. Я хочу иметь возможность просматривать исходный код в результатах анализа, а в документации сказано, что мне нужно предоставить информацию о символах. К сожалению, в нем не указано, как генерировать эту информацию о символах при компиляции моей программы. В версии VTune для Windows все, что мне нужно было сделать, это предоставить файл «.pdb», который сгенерирует Microsoft Visual Studio. Есть ли аналогичный файл, который я могу создать с помощью g++ для предоставления информации об этом символе?
Как создать информацию о символах для использования с Linux-версией Intel VTune Amplifier?
Ответы (3)
gcc -g <your stuff> должно быть все, что необходимо. Однако я использовал более старую версию.
Параметры командной строки для более новых вещей: здесь
EDIT: этот ответ SO, вероятно, ценнее всего здесь.
person
JimR
schedule
14.01.2011
Да, но замедлит ли это выполнение программы?
- person Dylan Klomparens; 15.01.2011
Нет - это просто делает исполняемый файл немного больше.
- person Paul R; 15.01.2011
Профилирование почти всегда помогает. Чем больше информации вы позволите профилировщику собрать, тем медленнее он будет работать. -g не должен иметь большого эффекта.
- person JimR; 15.01.2011
@JimR: я предположил, что он спрашивал, замедляет ли компиляция с -g работу программы, что, конечно же, не так.
- person Paul R; 15.01.2011
Отлично, буду компилировать с параметром -g.
- person Dylan Klomparens; 15.01.2011
@ Пол Р: Согласен. Я сделал то, что, вероятно, неправильное предположение, когда я ответил. Люди часто удивляются тому, как медленно работает профайлер.
- person JimR; 15.01.2011
@JimR: в основном это проблема инструментированных профилей, таких как gprof et al. Профилировщики выборки, такие как Zoom, Shark и т. д., как правило, лишь незначительно влияют на производительность, если только вы не установите очень низкое значение интервала выборки (например, ‹ 1 мс).
- person Paul R; 15.01.2011
@JimR: Есть twp вещи, которые нужно понять о профилировщиках выборки стека времени настенных часов. 1) Частота дискретизации не обязательно должна быть высокой, потому что большая часть информации, которую вы получаете о проблемах в 10^4 выборках, также содержится в любых 10^2 (или меньше) таких выборках. 2) Несмотря на то, что взятие образца происходит быстро, оно не очень сильно меняет результаты, если оно не является быстрым, потому что оно сообщает о процентах. Пробы беру вручную, и на проц это не влияет.
- person Mike Dunlavey; 15.01.2011
Вы пробовали компилировать с -g ? Обычно это все, что вам нужно для генерации символьных данных для отладчиков, профилировщиков и т. д.
Между прочим, для профилирования в Linux Zoom от RotateRight.com намного удобнее, чем VTune.
person
Paul R
schedule
14.01.2011
++ для Зума. (вставляю ссылку).
- person Mike Dunlavey; 15.01.2011
Самый «классический» способ заставить исполняемый файл содержать отладочную информацию с помощью GCC — указать параметр командной строки «-g», как упоминалось другими авторами. Это не влияет на производительность, поскольку отладочная информация находится в разделах ELF, которые не являются частью кода или сегмента данных. То есть секции .debug* не отображаются в памяти во время обычного выполнения программы, это только время отладки, когда отладчик получает их.
Еще одним полезным соображением для любого разработчика, работающего над производственным программным обеспечением, является использование отдельных файлов отладочной информации. . Это предполагает компиляцию программы с "-g", как описано выше, а затем использование утилиты objcopy для копирования разделов ELF, содержащих отладочную информацию, в отдельный файл и добавления ссылки из исходного двоичного файла в отдельный файл отладочной информации. Это чрезвычайно полезно для возможности хранить отладочную информацию для битов, которые вы предоставили клиенту, чтобы была возможна отладка post-mortem. И, конечно же, для профилирования производительности на релизных битах.
person
Alexey Alexandrov
schedule
17.04.2012
