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

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

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

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

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

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

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

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

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

CPU clock cycles aren't machine-independent nowadays, even with CPUs that use the same instruction set. The x86 (or whatever) machine code will be sliced and diced in all sorts of different ways. The days when this meant anything are long gone (and, back when CPU cycles meant something, there were so many different CPU types in use that it was machine-dependent anyway).

Not to mention that CPU-bound isn't as clear as it used to be, what with cache misses and all. It used to be that a CPU-bound process was one that was limited only by I/O and such, since a memory access would take a certain number of CPU cycles.

What you're trying to measure is performance, which I take means how fast it runs. In that case, you're probably best off measuring wall-clock time, repeating the calculation enough times that you get significant results. You could create a testing harness that would run through different implementations, so you'd get comparable results.

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

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

Спасибо

Измерение времени выполнения - лучший способ.

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

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

relative_time = measured_time_for_routine / measured_time_for_baseline