Как получить точный показатель эффективности?

Question

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

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

Мы уже исключаем затраты на установку из соображений синхронизации, то есть из самого кода C++ мы захватываем время непосредственно перед и после выполнения критичных по времени частей, вместо того, чтобы делать время всей программы на уровне ОС. Мы также делаем усреднение и исключение извне. Проблема заключается в том, что изменчивость также имеет долгосрочные тенденции, поэтому мы получаем жесткую кластеризацию времени для репликации сразу после друг друга, но через час или два время существенно отличаются. (К сожалению, распространение теста в течение нескольких часов не представляется возможным.) Тесты также выполняются на выделенной машине, пока на нем не выполняется «ничего».

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

Есть ли у кого-нибудь идея, откуда эта вариация, и как ее удалить? Тестирование выполняется на выделенной машине, поэтому возможно изменение настроек операционной системы.

(Как указано тэгами, это программа C++ работает на x86 системе Linux, если это поможет прояснить вещи.)

Edit: Ответ на комментарии

Наша текущая схема синхронизации заключается в использовании функцию clock() из стандартной библиотеки C, рассматривая разницу в возвращаемом значении от/до функции, которую мы хотим проверить.

Код, который мы тестируем, должен быть детерминированным и не должен включать тяжелый IO.

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

Answer 1

Я удивлен, что вы дошли до 5%.

Если вы не можете избавиться от всех ненужных вещей, запущенных в вашей системе, вы получите большие вариации. Это на верхнем уровне.

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

Является ли ваша система изолированной? Например, ваши измерения могут отличаться, если ваша система подключена к сети.

Использует ли ваша программа внешние ресурсы? Например, жесткий диск. Если программа записывает на жесткий диск, диск не будет детерминированным. Файлы и части файлов могут перемещаться по диску. Привод может стать фрагментированным. Эта фрагментация может привести к отклонениям в ваших измерениях.

Память операционной системы может быть фрагментирована. Кроме того, память исполняемого файла может стать фрагментированной. Фрагментация может добавить к дисперсии.