Представление результатов в исходном коде (Source View)
Данное представление отображает исходный код профилируемой программы. Для поддержки этой функциональности необходимо указать профилировщику путь к исходникам программы. Программа должна быть скомпилирована с отладочной информацией (debug information), либо необходимо указать путь к файлу, содержащему таблицу символов (symbol information). Информация о символах нужна профилировщику для отображения имен функций в отчете по модулям (modules report), окне статического анализа кода (static code analysis window) и окне исходного кода (source window). VTune пытается найти отладочную информацию в библиотечном файле. Если отладочная информация не найдена, профилировщик запросит файл, содержащий требуемые данные. VTune может работать со следующими типами символьной информации:
Символьные таблицы COFF – формата в объектных файлах.
Интегрированная отладочная информация Microsoft( NB09, NB11), Borland(FB09, FB0A), IBM Visual Age C++ (NB04), Watcom (DWARF 2), Novell (NB05)
pdb- файлы (program database files), генерируемые Microsoft Visual C++.
dbg-файлы (debug files), распространяемые вместе с SDK и DDK Microsoft или созданные утилитой rebase.exe.
sym-файлы, распространяемые с SDK и DDK Microsoft и Novell.
map-файлы сборщика (linker’a)
hdr-файлы, создаваемые утилитой exehdr.exe от Microsoft.
dmp-файлы, создаваемые утилитой dumpbin.exe доступной после установки Microsoft Visual C++.
W3 и W4 файлы, распространяемые с VxD.
В представлении исходного кода отображается исходный код функции, блока или «узкого места» (hotspot). Также отображаются номер строчки и смещение для каждой операции. Данное представление позволяет:
Посмотреть процент времени, который был затрачен на выполнение каждой строчки кода или количество выборок, собранных во время профилирования TBS или EBS.
Для режима EBS посмотреть индикаторы производительности (performance indicators).
Количество вызовов функции и время, затраченное на выполнение функции для режима графа вызовов (Call Graph Profiling).
Произвести статический анализ кода и посмотреть дизассемблированный код.
Произвести динамический анализ кода и вывести результаты для инструкций языка высокого уровня, инструкций ассемблера или работать с совмещенным представлениеем исходного кода и ассемблерных инструкций.
Вызвать модуль “Code Coach” и получить «совет» по оптимизации кода для языков C, C++, Fortran или Java.
Вызвать модуль “Assembly Coach” для оптимизации ассемблерных инструкций.
При интерпретации данных необходимо учитывать, что цифры, отображаемые рядом с инструкцией, могут относиться ко всему циклу или данному блоку, а не к инструкции, рядом с которой они отображаются. Такой эффект обусловлен оптимизациями выполнения инструкций в современных процессорах. В общем случае, если инструкция была совмещена (paired) на процессоре Pentium или Pentium MMX, значение выборки следует относить к инструкции непосредственно перед ней. Если же инструкция совмещена не была, то значение может относиться к инструкции, расположенной через одну инструкцию от данной. Чтобы получить более точные данные по времени выполнения, нужно выполнить динамический анализ ассемблерных инструкций (dynamic assembly analysis). Из-за явления «запаздывания событий» («event skid») аритектура Intel-процессоров позволяет инструкции завершиться перед тем, как управление будет передано VTune для того, чтобы сделать выборку адреса инструкции. К тому времени, как инструкция закончила свое выполнение, счетчик инструкций CS:IP получает новое значение и «указывает» на инструкцию, которая только будет выполняться. В результате профилировщик относит сделанную выборку к инструкции, которая только еще будет выполнена, а не к той инструкции, выполнение которой только что завершилось. Таким образом, время, отображаемое рядом с инструкцией в ассемблерном листинге, относится как минимум к предыдущей инструкции. В следующих ситуациях время следует относить к еще более «ранним» инструкциям:
Инструкция, которая выполнялась, была «совмещена» (paired) со следующей инструкцией. Такое случается только на порцессорах Pentium и Pentium MMX.
Выполнявшаяся инструкция является jump или call инструкцией, вызывающей ветвление алгоритма.
Из-за описанного явления на процессорах семейства P6 в режиме EBS отображаемые данные следует относить к инструкциям, расположенным на 5-10 инструкций от той, радом с которой эти данные отображаются. Рассмотрим пример. На Pentium процессоре можно получить следующие результаты:
29.96% for( i = 0; i < count; i++ )
4.70% numlist[N(i)]++;
В данном случае 29.96%времени выполняется группа инструкций, в которую транслируется кодnumlist[N(i)]++. Если просмотреть совмещенный листинг исходного и ассемблерного кода, то можно заметить, что после группы инструкций «numlist» следует инструкцияjump, передающая управление на начало цикла. На процессореIntel486 другая картина:
4.70% for( i = 0; i < count; i++ )
29.96% numlist[N(i)]++;
Это обусловлено тем фактом, что инструкции в конце цикла не были совмещены (paired) и значениеCS:IP было близко к адресу инструкции, которая выполнялась29.96% времени, достаточно близко, чтобы профилировщик соотнес полученные данные с операторомnumlist[N(i)]++, а не сfor.
Рассматривая пример test_cyc, необходимо отметить, что данные VTune достаточно достоверны для одинаковых по смыслу участков кода, но записанных разнами способами, что отличает данный профилировщик в выгодную сторону от TurboProfiler фирмы Borland:
