Как измерить производительность независимо от используемой машины

Question

У меня была рутина, которая работала хорошо. Однако я должен был изменить это. Изменение улучшило точность процедуры, но ухудшило производительность.

Процедура состоит из множества математических вычислений и, вероятно, связана с процессором (мне все еще нужно провести более тщательное тестирование, но я уверен на 99%). Он написан на C ++ (компилятор Borland C ++ 6).

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

Тогда я столкнулся с этой темой: Методы измерения производительности приложений - Переполнение стека . Мне понравилась идея измерения через MFlops.

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

По моему мнению, измерение обеих сторон (времени выполнения и MFlops) - это путь, но я хотел бы услышать от экспертов по стекопотокам, что вы думаете, ребята.

Как можно измерить производительность процедуры, известной как связь с процессором?

Answer 1

Циклы тактовой частоты процессора тоже не так много значат, если ваше приложение связано с памятью. На более быстром процессоре вы просто потратите больше циклов процессора в ожидании того же промаха кэша. (Математические приложения, вероятно, не связаны с вводом / выводом).

Другая проблема заключается в том, что количество тактов для определенной последовательности команд будет по-прежнему варьироваться в зависимости от архитектуры (и даже в случае Intel Core1 / Core2). Таким образом, в качестве абсолютного показателя производительности тактовые циклы на одном процессоре вряд ли являются улучшением.

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

Answer 2

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

Я бы предположил, что при измерении отсутствует точка.

Что вам действительно нужно сделать, это найти операторы или инструкции (не функции) 1), которые отвечают за значительную долю времени настенных часов, и 2) что вы можете найти способ оптимизировать.

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

Этот является очень хорошим способом найти их, и этот является примером его использования.

Answer 3

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

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

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

Answer 4

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

Answer 5

Вы можете измерить количество аппаратных счетчиков ЦП, профили VTune Intel довольно хороши в этом. он покажет вам подробную информацию, основанную на счетчиках ЦП (инструкции по выбытию, ошибки кэширования, неправильное предсказание ветвлений), и также сопоставит это с каждым оператором в ваших функциях, поэтому у вас будет довольно хорошее представление о том, что требует наибольшей стоимости.

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

Спасибо

Answer 6

Время выполнения измерения - путь.

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

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

relative_time = measured_time_for_routine / measured_time_for_baseline