Параметры компиляции для целей профилирования

Какой хороший набор параметров компилятора можно включить / выключить, чтобы повысить точность моего эксперимента по профилированию?

Меня больше всего интересуют эти компиляторы: gcc / g ++ / icc и эти инструменты профилирования: Intel Vtune, Linux Perf и Oprofile. ОС Linux.

Известно, что включение оптимизаций (встраивание функций, преобразования циклов и т. Д.) Может изменить порядок инструкций, что может привести к отображению запутанной информации (если она не является неверной) в профилировщике / отладчике. Однако, если я отключу эти оптимизации, я буду профилировать (а позже оптимизировать) код, который был «недостаточно оптимизирован» ... Итак, каковы лучшие практики при компиляции для профилирования?


person JohnTortugo    schedule 03.02.2014    source источник
comment
Вы можете просто скомпилировать с gcc -pg и использовать gprof. Но профилирование всегда сильно мешает профилированному коду. Прочтите о heisenbugs. Кроме того, какое приложение вы пытаетесь оптимизировать и почему?   -  person Basile Starynkevitch    schedule 04.02.2014
comment
-pg - единственное, что мне нужно сделать, чтобы получить точную информацию о профилировании с помощью упомянутых мною инструментов? Я не ограничен каким-то конкретным видом программы.   -  person JohnTortugo    schedule 04.02.2014
comment
ИМХО точное профилирование - это оксюморон. Профилирование всегда мешает. Вы должны это принять.   -  person Basile Starynkevitch    schedule 04.02.2014
comment
Идея о том, что целью профилирования является получение точных измерений, возникла из ничего. Предположим, вы их получите. Что вы с ними делаете, даже если они точны? Они скажут вам, как сделать это быстрее? Если цель состоит в том, чтобы сделать код быстрее, вам нужно что-то, что подсказывает вам, что нужно исправить, а не то, что дает вам трехзначную точность чего-то или другого.   -  person Mike Dunlavey    schedule 04.02.2014
comment
Я не говорил, что хочу числовую точность. Я почти уверен, что вы, ребята, уже отладили некоторый оптимизированный код и заметили, что порядок ваших инструкций был изменен ... многие профилировщики (например, VTune) вводят в заблуждение такие преобразования. Поиск точных аннотаций кода - это не что-то из другого мира.   -  person JohnTortugo    schedule 04.02.2014
comment
@John: И я не могу понять, почему принято считать, что вы должны профилировать только код, оптимизированный для компилятора. Все, что это делает, - это затрудняет поиск проблем, и если код вызывает много системных функций, он даже не ускоряет код настолько, чтобы заботиться о нем! Я противник, но я и многие другие люди используют этот метод, и мы получаем реальные результаты, а не пустые пожелания.   -  person Mike Dunlavey    schedule 04.02.2014


Ответы (1)


Все инструменты профилирования полагаются на отладочную информацию, созданную компилятором во время сборки. Пока отладочная информация фиксирует эти оптимизации (особенно встраивание), инструмент профилирования сможет сопоставить ее с правильным исходным местоположением. Для ICC при построении кода с включенной оптимизацией используйте параметр компилятора «-debug inline-debug-info». Таким образом, если ваша функция встроена, она гарантирует, что вызовет оптимизацию как на сайте вызова, так и на сайте вызываемого абонента (где функция определена). Ниже приведен простой пример, иллюстрирующий то же самое:

#include <iostream>
#include <tbb/tbb.h>
#include <tbb/parallel_for.h>
#include <cstdlib>
using namespace std;
using namespace tbb;
long len = 0;
float *__restrict__ a;
float *__restrict__ b;
float *__restrict__ c;
class Test {
public:
    void operator()( const blocked_range<size_t>& x ) const {
        for (long i=x.begin(); i!=x.end(); ++i ) {
            c[i] = (a[i] * b[i]) + b[i];
        }
    }
};
int main(int argc, char* argv[]) {
    cout << atol(argv[1]) << endl;
   len = atol(argv[1]);
    a = new float[len];
    b = new float[len];
    c = new float[len];
    parallel_for(blocked_range<size_t>(0,len, 100), Test() );
    return 0;
}

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

$ icpc testdebug.cc -c -vec-report2 -O3
tbb/parallel_for.h(127): (col. 22) remark: loop was not vectorized: unsupported loop structure
tbb/parallel_for.h(127): (col. 22) remark: LOOP WAS VECTORIZED
tbb/parallel_for.h(127): (col. 22) remark: loop was not vectorized: unsupported loop structure
tbb/parallel_for.h(127): (col. 22) remark: LOOP WAS VECTORIZED
tbb/parallel_for.h(127): (col. 22) remark: loop was not vectorized: nonstandard loop is not a vectorization candidate
tbb/parallel_for.h(127): (col. 22) remark: loop was not vectorized: nonstandard loop is not a vectorization candidate
tbb/partitioner.h(164): (col. 9) remark: loop was not vectorized: existence of vector dependence

В приведенном выше отчете мы видим два сообщения «LOOP WAS VECTORIZED», но они отображаются в заголовок TBB parallel_for.h. Нет отчета, соответствующего функтору, который есть в нашей программе. Так как функтор вызывается внутри блока parallel_for, определение функции встроено в parallel_for.h

Чтобы получить эту информацию, используйте параметр компилятора -debug inline-debug-info во время сборки, и сгенерированный отчет векторизации будет выглядеть, как показано ниже:

$ icpc testdebug.cc -c -vec-report2 -O3 -debug inline-debug-info
tbb/partitioner.h(171): (col. 9) remark: loop was not vectorized: unsupported loop structure
testdebug.cc(14): (col. 37) remark: LOOP WAS VECTORIZED
tbb/partitioner.h(164): (col. 9) remark: loop was not vectorized: unsupported loop structure
testdebug.cc(14): (col. 37) remark: LOOP WAS VECTORIZED
tbb/partitioner.h(245): (col. 33) remark: loop was not vectorized: nonstandard loop is not a vectorization candidate
tbb/partitioner.h(265): (col. 52) remark: loop was not vectorized: nonstandard loop is not a vectorization candidate
tbb/partitioner.h(164): (col. 9) remark: loop was not vectorized: existence of vector dependence

Из приведенного выше отчета ясно, что «ПЕТЛЯ БЫЛА ВЕКТОРИЗОВАНА» на testdebug.cc (14).

person Anoop - Intel    schedule 06.05.2014