разница между Бенчмаркинг и профилирование

Question

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

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

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

Кто-то сказали here:

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

Еще один сказал here о профилировании:

профилирования означает разные вещи в разное время. Иногда это означает измерение производительности. Иногда это означает диагностику утечек памяти. Иногда это означает получение видимости в многопоточных или других низкоуровневых действиях.

Итак, эти методы концептуально отличаются или просто не являются черными и белыми?

Answer 1

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

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

---

Профилирование не предназначено для сравнения разных вещей: это понимание поведения программы. Результатом профиля может быть таблица времени, затраченная на каждую функцию, или even per instruction with a sampling profiler. Вы можете сказать, что это профиль, не являющийся эталоном, потому что нет смысла говорить, что «эта функция заняла наименьшее время, поэтому мы сохраним ее и перестанем использовать остальные».

Прочитайте статью Википедии, чтобы узнать больше об этом: https://en.wikipedia.org/wiki/Profiling_(computer_programming)

Вы используете профиль, чтобы выяснить, где нужно оптимизировать. Ускорение на 10% в функции, в которой ваша программа тратит 99% своего времени, более ценна, чем 100% -ное ускорение в любой другой функции. Еще лучше, когда вы можете улучшить свой дизайн на высоком уровне, поэтому дорогостоящая функция называется меньше, а также просто делает ее быстрее.

---

Microbenchmarking является специфической формой сравнительного анализа. Это означает, что вы тестируете одну супер-специфическую вещь, чтобы измерить только то, что в изоляции, не общая производительность всего, что действительно полезно.

Результаты Пример microbenchmark:

• Intel Haswell's L1 cache load-use latency is 4 cycles.
• Эта версия memcpy достигает 80% пропускной способности другой версии.

• mov eax, ecx has 0c latency on Haswell, but mov ecx, ecx has 1c latency. (mov-exception работает только между разными регистрами на Intel). См. Эту ссылку для полного источника asm статического исполняемого файла, а результат счетчика производительности - от запуска его с помощью нескольких разных тел цикла, чтобы продемонстрировать отмену mov.

  Использование счетчиков производительности процессора для измерения того, как работает микро-тест, является хорошим способом проведения экспериментов, чтобы узнать, как работают ЦП внутри. См. Также How exactly do partial registers on Haswell/Skylake perform? Writing AL seems to have a false dependency on RAX, and AH is inconsistent. В этом случае вы профилируете свой микро-бенчмарк, чтобы узнать, что заставляет его работать с такой скоростью. (Часто вас больше интересуют счетчики perf, такие как uops_executed, чем вы находитесь в фактическом времени или такте цикла тактирования, например, чтобы протестировать микро-fusion/un-lamination, не требуя создания цикла, где это фактически влияет на циклы на итерацию.)

Примера немикрокапсулированных результаты тесты:

• сжатие этой коллекции 100MB файлов заняло 23 секунд с 7-Zip (с определенными параметрами и аппаратным обеспечением).
• компиляция ядра Linux заняла 99 секунд на некоторой аппаратной/программной комбинации.

См. Также https://en.wikipedia.org/wiki/Benchmark_(computing)#Types_of_benchmarks.

Микро-бенчмаркинг - это особый случай бенчмаркинга. Если вы все сделаете правильно, в нем рассказывается, какие операции дороги и дешевы, что помогает вам при оптимизации. Если вы сделаете это неправильно, вы, вероятно, даже не измерили то, что вы намеревались измерить вообще. например вы написали несколько C для тестирования циклов и циклов, но компилятор сделал разные коды по разным причинам, и ваши результаты не имеют смысла. (Различные способы выразить ту же логику почти никогда не имеют значения с современными оптимизирующими компиляторами, не тратьте время на это.) Микро-бенчмаркинг трудный.

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

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

Answer 2

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

Профилирование является основным средством измерения и анализа, когда потребляется время . Профилирование влечет за собой два шага: измерение задач и время , прошедшее, и агрегирование и сортировка результатов, чтобы важные задачи пузырились вверх. - High performance MySQL

Что я понимаю: тест является мерой знать ваше приложение в то время как профилирования является мерой для улучшения вашего приложения.

Answer 3

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

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

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

Есть другие вещи помимо функций или строк кода, которые могут занять время. Это того, что делает программа, но это не единственные описания.

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

Например, описание образца может быть:

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

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

• Программа вызывает функцию F с определенными аргументами и ранее вызывала ее с теми же аргументами, давая тот же результат. Это говорит о том, что можно просто вспомнить предыдущий результат.

• Программа вызывает функцию G, которая в процессе вызова функции H просто расшифровывает флаги параметров аргумента G. Программист знает, что эти флаги всегда одинаковы, предполагая, что специальная версия G сохранит это время.

• и т.д. и т.п.

Те возможные описания. Если они учитывают F процентов времени, то есть вероятность того, что каждый образец будет соответствовать этому описанию. Упрощенное описание:

• Строка или строка кода X отображается на Q процентов образцов стека. То есть измеренный процент включительно.
• Рутина D появляется сразу над обычным E на R процентов образцов стека. Это число можно поместить на дугу графика вызовов от D до E.
• Последовательность стека main-> A-> B-> C-> D-> E - последовательность, которая появляется на наибольшем числе выборок. Это «горячий путь».
• Обычная процедура, которая чаще всего появляется в нижней части стеков, - это Т. Это «горячая точка».

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

Это принцип, лежащий в основе random pausing, а статистическое обоснование - here.