![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
benchmarking
Допустим, у меня есть процедура, вычисляющая некую функцию f(x). Есть модификация, который позволяет эту процедуру ускорить, и надо проверить, насколько именно. Процедура довольно быстрая - скажем, порядка десятков миллисекунд (все цифры условные для примера). Т.е. чтобы ее мерять достаточно уверенно, надо написать бенчмарк, который ее запускает, скажем, 1000 раз и меряет, сколько времени заняло. Тут начинается интересное - бенчмарк дает разброс между, скажем, 10.8 секунды и 10.1 секунды. Какое значение использовать? Можно посчитать среднее, но с другой стороны - если некоторые бенчмарки выполняются за 10.1 секунды, не значит ли это, что именно настолько быстрая эта функция и есть, а значения выше этого - это мусор, вызванный каким-то другими эффектами в системе?
Имеет ли смысл удлинять тест, тестировать не 1000, а 10000, скажем? С одной стороны, относительный разброс становится меньше, с другой - больше вероятности, что во время теста случится что-нибудь, что повлияет на результаты (к сожалению, в современной ОС без значительных усилий трудно знать, не решит ли какой-нибудь процесс прямо сейчас что-нибудь поделать)?
Теперь дальше - меряем улучшеную функцию, получаем разброс, скажем, от 8.9 до 8.2. Можно ли утверждать, что мы ускорили функцию с 10.1 до 8.2 - т.е. практически на 20% - или же надо опять считать средние и сравнивать их?
Я знаю, что обычно принято считать среднее, но не очень понятно, почему именно в этом случае это будет лучше (для ясности - мне надо знать не насколько быстрая сама функция, а насколько конкретная модификация ее ускоряет).
no subject
no subject
Конечно, точно знать я не могу, но если я сделаю достаточно много тестов, то разумное приближение к минимуму у меня будет - поскольку никакая случайная ошибка не может _уменьшить_ время функции.
no subject
no subject
no subject
no subject
1) Абсолютно пустой компъютер, облегченная до минимума операционная система
2) Рестарт после каждого сэмпла
3) Отрубить сеть
4) Отрубить все завязанные на scheduller таски.
И всё равно - фигово обычно получается:( В гугл-сколаре масса статей о том, как ставить подобные эксперименты, очень нетривиальная задача, ИМХО, если нужен корректный результат.
no subject
no subject
Ещё советуют после каждого рестарта выжидать минут по 10-15 чтоб все обязательные сервисы успели подняться. А ещё, в случае сетевого исполнение, надо следить чтоб траффик не прыгал сильно. У нас в лабе рассказывают байку как один длинный ночной эксперимент начал выдавать поразительно интересные результаты:
В воскресенье все работало офигенно, потом, замедлялось до пятницы, а субботу просто нафиг висло. И повторялось с воскресенья. Выяснилось - ночной сетевой бэкап:)
> выжидать минут по 10-15 чтоб все обязательные сервисы у
Re: > выжидать минут по 10-15 чтоб все обязательные сервисы
no subject
остаётся необходимый сетевой доступ, отрубается NFS и прочие потенциально неприятные вещи.
no subject
no subject
Однако я все-таки не совсем понимаю, почему нельзя просто сравнить минимумы в достаточно длинной серии - отрицательных ошибок ведь в данном случае быть не может, т.е. случайные события могут только замедлить.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Так и есть. Запускаешь раз 10 - 20, берешь наименьший результат и всё.
///Теперь дальше - меряем улучшеную функцию, получаем разброс, скажем, от 8.9 до 8.2. Можно ли утверждать, что мы ускорили функцию с 10.1 до 8.2 - т.е. практически на 20% ///
Да, можно. Также прогоняешь тесть раз 10 - 20, берешь минимальный результат - это есть время работы функции. Всё остальное - мусор.