Как правильно протестировать [шаблонную] программу на C++

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

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

Компиляторам разрешено только исключать ветки кода, которых не может быть. Пока он не может исключить необходимость выполнения ветки, он не устранит ее. Пока где-то существует какая-то зависимость данных, код будет там и будет запущен. Компиляторы не слишком умны в оценке того, какие аспекты программы не будут выполняться, и не пытаются их выполнять, потому что это проблема NP и ее трудно вычислить. У них есть несколько простых проверок, например, для if (0), но это все.

Мое скромное мнение состоит в том, что раньше вы, возможно, столкнулись с какой-то другой проблемой, например, с тем, как C / C++ оценивает логические выражения.

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

Чтобы ответить на ваш вопрос о тестировании in vitro: да, сделайте это. Если ваше приложение так критично по времени, сделайте это. С другой стороны, ваше описание намекает на другую проблему: если ваши дельты находятся в интервале времени от 1 до 3 секунд, то это звучит как проблема вычислительной сложности, поскольку рассматриваемый метод должен вызываться очень и очень часто (для несколько пробежек, 1е-3 секунды можно пренебречь).

Проблемная область, которую вы моделируете, кажется ОЧЕНЬ сложной, а наборы данных, вероятно, огромны. Такие вещи всегда интересны. Однако сначала убедитесь, что у вас есть абсолютно правильные структуры данных и алгоритмы, а после этого оптимизируйте все, что захотите. Итак, я бы посоветовал сначала взглянуть на весь контекст. ;-)

Из любопытства, какую задачу вы решаете?

У вас есть большой контроль над оптимизацией вашей компиляции. -O1, -O2 и т. д. - это просто псевдонимы для группы переключателей.

Со страниц руководства

       -O2 turns on all optimization flags specified by -O.  It also turns
       on the following optimization flags: -fthread-jumps -falign-func‐
       tions  -falign-jumps -falign-loops  -falign-labels -fcaller-saves
       -fcrossjumping -fcse-follow-jumps  -fcse-skip-blocks
       -fdelete-null-pointer-checks -fexpensive-optimizations -fgcse
       -fgcse-lm -foptimize-sibling-calls -fpeephole2 -fregmove -fre‐
       order-blocks  -freorder-functions -frerun-cse-after-loop
       -fsched-interblock  -fsched-spec -fschedule-insns  -fsched‐
       ule-insns2 -fstrict-aliasing -fstrict-overflow -ftree-pre
       -ftree-vrp

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

       ...
       Alternatively you can discover which binary optimizations are
       enabled by -O3 by using:

               gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
               gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
               diff /tmp/O2-opts /tmp/O3-opts Φ grep enabled

Как только вы найдете виновника оптимизации, вам не понадобятся файлы cout.

Если это возможно для вас, вы можете попробовать разделить свой код на:

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

В противном случае вы можете указать другой уровень оптимизации (похоже, вы используете gcc ...) для функции тестирования с атрибутом optimize (см. http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes).

Я не знаю, есть ли в GCC аналогичная функция, но с VC++ вы можете использовать:

#pragma optimize

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

Вы можете создать фиктивную функцию в отдельном файле cpp, который ничего не делает, но принимает в качестве аргумента любой тип результата вашего вычисления. Затем вы можете вызвать эту функцию с результатами ваших вычислений, заставив gcc сгенерировать промежуточный код, и единственное наказание - это стоимость вызова функции (которая не должна искажать ваши результаты, если вы не назовете ее много!).

Просто небольшой пример нежелательной оптимизации:

#include <vector>
#include <iostream>

using namespace std;

int main()
{
double coords[500][3];

//perform a simple initialization of all coordinates:
for (int i=0; i<500; ++i)
 {
   coords[i][0] = 3.23;
   coords[i][1] = 1.345;
   coords[i][2] = 123.998;
 }


cout << "hello world !"<< endl;
return 0;
}

Если вы прокомментируете код от «double coords [500] [3]» до конца цикла for, он сгенерирует точно такой же ассемблерный код (только что пробовал с g ++ 4.3.2). Я знаю, что этот пример слишком прост, и мне не удалось показать такое поведение с помощью std :: vector простой структуры «Координаты».

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

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

#include <iostream>

// Mark coords as extern.
// Compiler is now NOT allowed to optimise away coords
// This it can not remove the loop where you initialise it.
// This is because the code could be used by another compilation unit
extern double coords[500][3];
double coords[500][3];

int main()
{

//perform a simple initialization of all coordinates:
for (int i=0; i<500; ++i)
 {
   coords[i][0] = 3.23;
   coords[i][1] = 1.345;
   coords[i][2] = 123.998;
 }


std::cout << "hello world !"<< std::endl;
return 0;
}

при запуске читать из файла. в коде скажите if (input == "x") cout << result_of_benchmark;

Компилятор не сможет исключить вычисление, и если вы убедитесь, что на входе не «x», вы не будете тестировать iostream.

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

StartBenchmarking(); // ie, read a performance counter
for (int i=0; i<500; ++i)
 {
   coords[i][0] = 3.23;
   coords[i][1] = 1.345;
   coords[i][2] = 123.998;
 }
StopBenchmarking(); // what comes after this won't go into the timer

// this is just to force the compiler to use coords
double foo;
for (int j = 0 ; j < 500 ; ++j )
{
  foo += coords[j][0] + coords[j][1] + coords[j][2]; 
}
cout << foo;

В этих случаях мне иногда удается спрятать тест in vitro внутри функции и передать наборы данных теста через указатели летучий. Это сообщает компилятору, что он не должен сворачивать последующие записи в эти указатели (потому что они могут быть вводом-выводом с отображением в память например). Так,

void test1( volatile double *coords )
{
  //perform a simple initialization of all coordinates:
  for (int i=0; i<1500; i+=3)
  {
    coords[i+0] = 3.23;
    coords[i+1] = 1.345;
    coords[i+2] = 123.998;
  }
}

По какой-то причине я еще не понял, что это не всегда работает в MSVC, но часто работает - посмотрите на вывод сборки, чтобы убедиться. Также помните, что летучий помешает некоторым оптимизациям компилятора (он запрещает компилятору сохранять содержимое указателя в регистре и заставляет выполнять запись в программном порядке), так что это заслуживает доверия только в том случае, если вы используете его для окончательной записи данных.

В целом подобное тестирование in vitro очень полезно, если вы помните, что это еще не все. Я обычно тестирую свои новые математические процедуры изолированно, как это, чтобы я мог быстро перебирать только характеристики кэша и конвейера моего алгоритма на согласованных данных.

Разница между подобным профилированием в пробирке и его запуском в «реальном мире» означает, что вы получите сильно различающиеся наборы входных данных (иногда в лучшем случае, иногда в худшем случае, иногда патологически), кеш будет в каком-то неизвестном состоянии при входе функция, и у вас могут быть другие потоки, работающие по шине; так что вы должны запустить несколько тестов для этой функции in vivo, когда вы закончите.

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

template<typename T> void sink(T const& t) {
   volatile T sinkhole = t;
}

Никаких накладных расходов на iostream, только копия, которая должна оставаться в сгенерированном коде. Теперь, если вы собираете результаты большого количества операций, лучше не отбрасывать их один за другим. Эти копии все еще могут добавить некоторые накладные расходы. Вместо этого каким-то образом соберите все результаты в одном энергонезависимом объекте (так что необходимы все индивидуальные результаты), а затем назначьте этот объект результата изменчивому. Например. если все ваши отдельные операции производят строки, вы можете принудительно вычислить, сложив все значения char вместе по модулю 1 << 32. Это почти не добавляет накладных расходов; строки, скорее всего, будут в кеше. Результату добавления впоследствии будет присвоено значение volatile, поэтому фактически должен быть вычислен каждый символ в каждой строке, никаких сокращений не допускается.