Оцените одну функцию
Как вы оцениваете функцию? Глядя на результаты Callgrind, я обнаружил, что моя программа проводит много времени в pow, Поскольку мне не нужна полная рабочая точность, я подумал, что мог бы создать справочную таблицу и использовать линейную интерполяцию между точками в таблице. Чтобы иметь возможность оценить подход с использованием таблицы поиска, мне нужно измерить время. Итак, я сделал это:
#ifdef __WAND__
target[name[test2.exe] type[application] platform[;Windows]]
target[name[test2] type[application]]
#endif
#include <herbs/main/main.h>
#include <herbs/tictoc/tictoc.h>
#include <herbs/array_fixedsize/array_fixedsize.h>
#include <random>
#include <cstdio>
#include <cmath>
class GetRand
{
public:
GetRand(double min,double max):U(min,max){}
bool operator()(double* val,size_t n,size_t N)
{
*val=U(randsource);
return 1;
}
private:
std::mt19937 randsource;
std::uniform_real_distribution<double> U;
};
int MAIN(int argc,charsys_t* argv[])
{
Herbs::ArrayFixedsize<double> vals(1024*1024*128,GetRand(-4,4));
const size_t N=16;
auto n=N;
while(n)
{
double start=0;
auto ptr=vals.begin();
{
Herbs::TicToc timestamp(start);
while(ptr!=vals.end())
{
pow(2,*ptr);
++ptr;
}
}
// I have set cpu-freq to 1.6 GHz using cpufreq-set
printf("%.15g\t",1.6e9*start/vals.length());
--n;
}
return 0;
}
При запуске этой программы выход составляет около 2,25 циклов за итерацию. Это кажется очень низким, так как реализация pow кажется (это callgrind дал мне __ieee754_pow).
Цикл тестирования в сборке выглядит так при компиляции для GNU / Linux на x86-64:
call _ZN5Herbs6TicTocC1ERd@PLT
movq %r14, %rbx
.p2align 4,,10
.p2align 3
.L28:
vmovsd (%rbx), %xmm1
vucomisd .LC6(%rip), %xmm1
jb .L25
vmovsd .LC7(%rip), %xmm0
call pow@PLT
.L25:
addq $8, %rbx
cmpq %r12, %rbx
jne .L28
movq %rbp, %rdi
call _ZN5Herbs6TicTocD1Ev@PLT
По крайней мере powназывается. Могу ли я доверять выводу или есть какая-то черная магия, которая устраняет вещи?
Решение
Есть несколько вещей, которые вы должны учитывать при тестировании функций.
1) Убедитесь, что отсутствие кеша не оказывает существенного влияния на результаты. В вашем случае вы перебираете большой массив данных, где вы получаете тонны промахов кеша. Вместо этого используйте меньший массив, который легко помещается в кэш L1 и проходит по нему несколько раз.
2) Убедитесь, что у вас есть побочные эффекты от вызовов функций, которые вы профилируете, что компилятор не может оптимизировать эти вызовы. В вашем случае компилятор не выполняет хорошую работу по оптимизации, так как pow() звонки не оптимизируются, даже если побочные эффекты отсутствуют. Предпочитайте использовать целочисленные побочные эффекты, чтобы избежать аномалий в производительности с плавающей запятой (например, необработанный метод float для uint32 и добавление их вместо того, чтобы выполнять сложение с помощью float).
3) Разверните ваши циклы несколько раз, чтобы уменьшить накладные расходы. В настоящее время вы выполняете только один pow на цикл, где цикл добавляет относительно большие накладные расходы для этого простого вызова функции.
4) Профиль с полной оптимизацией и включенным встраиванием.
5) Выполните профилирование несколько раз, чтобы другие процессы не влияли на ваши результаты. Выберите лучший результат для сравнения (то есть наименьшее количество помех от других процессов).
Другие решения