Есть ли быстрый/простой способ сделать это (хотя бы для приблизительной оценки)?
Я сравниваю алгоритмы, и я подумал, что было бы здорово узнать абсолютную скорость, с которой мой компьютер выполняет инструкции и сравнивает это с моим асимптотическим анализом.
Если вы хотите узнать, что может сделать ваш процессор, посмотрите на документацию. Ваш поставщик ЦП определяет задержку и пропускную способность всех инструкций, а также множество других сведений (сколько команд может быть выпущено или выбыто за цикл, задержки в кэше и многое другое). Исходя из этого, вы можете вычислить теоретическую пиковую пропускную способность.
Если вы хотите сделать то, что делает ваш процессор, запустите свой собственный код и оцените его производительность.
Однако имейте в виду, что современные процессоры - это действительно сложные звери, и их производительность зависит от самых разных факторов, и вы очень редко сможете приблизиться к максимальному уровню вашего процессора и понять, почему, или что именно для хранения вашего кода требуется достаточно полное понимание аппаратного обеспечения. (Мое обычное эмпирическое правило состоит в том, что вы делаете очень хорошо, если вы получаете устойчивый 30-40% от теоретического пика FLOPS)
Это типичный случай: "В теории теория и практика одинаковы, на практике это не так".
Современный процессор имеет в них очень сложную логику, а это означает, что ACTUAL количество выполненных операций отличается от того, что вы думаете, просто глядя на код или думая о проблеме [если у вас нет мозга размером с небольшой планете и знать, как работает этот конкретный процессор]. Например, процессор может спекулятивно исполнять инструкции на той или иной стороне ветки, даже если он не совсем добрался до ветки - если это "неправильная" сторона, то она отбросит результаты этих инструкций, но Конечно, для их выполнения потребовалось время.
Инструкции также выполняются не по порядку, а это означает, что трудно точно предсказать, какая команда будет выполняться, когда. Есть некоторые исключения.
Вы получите только (практически близкую) теоретическую пропускную способность, если вы нажимаете данные и инструкции через все доступные исполнительные блоки сразу - это означает наличие правильного сочетания инструкций и, конечно, ВСЕ кода и данных в кэшах,
Итак, теоретически мы могли бы заполнить процессор, полный инструкций, которые его максимизируют, написав очень умный код. На практике это очень быстро переходит в сложную задачу.
Однако речь идет о измерении пропускной способности инструкций и современных процессоров, это очень возможно с помощью правильного дополнительного программного обеспечения. В linux perftool или oprofile для окон есть Intel VTune и AMD Code Analyst. Они позволят вам (при условии наличия достаточных привилегий) получать "счетчики производительности" в процессоре, у которого есть счетчики для "количества инструкций", "числа операций с плавающей запятой", "количества промахов в кеше", "ветки неверно предсказаны" и многие, многие другие измерения производительности процессора. Поэтому, учитывая достаточную продолжительность работы (по крайней мере, несколько секунд, желательно больше), вы можете измерить фактические циклы отсчетов или тактовых импульсов, которые выполняет процессор.
На практике в эти дни эффективное количество инструкций зависит в первую очередь от латентности памяти, которая является основным узким местом в производительности. Ждать данных плохо. Процессоры могут немного устранить эту проблему с помощью таких методов, как кэширование, конвейерная обработка и concurrency, но проблема остается и со временем будет ухудшаться.
Правильная реализация может иметь огромное значение. Вы можете проверить этот вопрос о кэширующем коде.
Современные процессоры являются обработкой команд конвейерной обработки, поэтому константа не существует.
Вы могли бы, однако, зачитать количество тиков ЦП в начале вашего алгоритма и в конце. Я думаю, что это такой низкий уровень, который вы можете получить при таком измерении.
http://en.wikipedia.org/wiki/Time_Stamp_Counter
Примечание. Есть много проблем, почему это не будет на 100% точным, я могу упомянуть несколько, но я уверен, что сообщество сможет добавить в список: -OS предотвращает процесс -cache misses (algo будет работать медленнее в первый раз, быстрее, если он будет запущен впоследствии) - на старых процессорах, тики CPU не являются инвариантными к частоте процессора