Задержка инструкций процессора на процессорах x86 и x64

24264
ST3

Я ищу какую-то таблицу или что-то подобное, что может помочь мне рассчитать эффективность кода сборки.

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

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

10
Можно так же на SO: http://stackoverflow.com/questions/692718/how-to-find-cpu-cycle-for-an-assembly-instruction Ciro Santilli 新疆改造中心 六四事件 法轮功 9 лет назад 0

3 ответа на вопрос

9
Jon Brauer

In general, each of these operations takes a single clock cycle as well to execute if the arguments are in registers at the various stages of the pipeline.

What do you mean by latency? How many cycles an operation spends in the ALU?

You might find this table useful: http://www.agner.org/optimize/instruction_tables.pdf

Since modern processors are super scalar and can execute out of order, you can often get total instructions per cycle that exceed 1. The arguments for the macro command are the most important, but the operation also matters since divides take longer than XOR (<1 cycle latency).

Many x86 instructions can take multiple cycles to complete some stages if they are complex (REP commands or worse MWAIT for example).

Умножение целых чисел составляет как минимум 3c задержки на всех последних процессорах x86 (и выше на некоторых старых процессорах). На многих процессорах он полностью конвейеризован, поэтому пропускная способность равна 1 за такт, но этого можно достичь только при наличии трех независимых умножений в полете. (Умножение FP на Haswell составляет 5 с задержкой, 0,5 с пропускной способностью, поэтому вам нужно 10 в полете для насыщения пропускной способности). Деление (`div` и` idiv`) еще хуже: оно микрокодируется и имеет * намного * большую задержку, чем `add` или` shr`, и даже не полностью конвейеризовано ни на одном процессоре. Все это прямо из таблиц инструкций Агнера Фога, так что хорошо, что вы связали это. Peter Cordes 6 лет назад 2
См. Также [Почему этот код C ++ быстрее, чем моя рукописная сборка для проверки гипотезы Коллатца?] (Https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my рукописная сборка для тестирования the collat ​​/ 40355466 # 40355466), чтобы узнать больше об оптимизации asm. Peter Cordes 6 лет назад 0
7
Brian Knoblauch

Calculating the efficiency of assembly code is not the best way to go in these days of Out of Order Execution Super Scalar pipelines. It'll vary by processor type. It'll vary on instructions both before and after (you can add extra code and have it run faster sometimes!). Some operations (division notably) can have a range of execution times even on older more predictable chips. Actually timing of lots of iterations is the only way to go.

Я знаю это, но мне это нужно не в реальном проекте, а в одном виде - программном проекте _fun_. ST3 10 лет назад 0
Нужно ли вам это по-настоящему или для удовольствия, не меняет ответ для этой линейки процессоров. Вы рассматривали возможность перехода на более детерминированный процессор, такой как чип Propeller? Brian Knoblauch 10 лет назад 0
Даже со скаляром неправильные прогнозы веток реализации и ошибки в кеше могут привести к изменению времени выполнения. Paul A. Clayton 10 лет назад 3
Для чисто связанных с процессором вещей (без ошибок кэша, без ошибок ветвления) поведение процессора понимается достаточно подробно, так что статический анализ часто может почти точно предсказать, сколько циклов за итерацию цикл займет на конкретном процессоре (например, Intel Haswell). например, см. [этот SO-ответ] (https://stackoverflow.com/questions/28875325/gcc-optimization-flag-o3-makes-code-slower-then-o2), где, глядя на сгенерированный компилятором asm, позвольте мне объяснить, почему ветвистая версия работала почти в 1,5 раза быстрее, чем CMOV-версия на процессоре Sandybridge OP, но гораздо ближе на моем Skylake. Peter Cordes 6 лет назад 0
* Если * вы пишете asm вручную по соображениям производительности, то на самом деле полезно искать узкие места задержки и пропускной способности на процессорах Intel и AMD. Хотя это сложно, и иногда то, что оптимально для AMD, не то, что оптимально для Intel. Peter Cordes 6 лет назад 0
3
UmNyobe

You can find information on intel cpu at intel software developer manuals. For instance the latency is 1 cycle for an integer addition and 3 cycles for an integer multiplication.

I don't know about multiplication, but I expect addition to always take one cycle.

Один цикл, за исключением случаев, когда он «свободен» (параллельно, когда конвейеры выстроены правильно) или занимает больше времени из-за отсутствия кэша. :-) Brian Knoblauch 10 лет назад 0
В настоящее время (2018 г.) эта информация доступна в Приложении C под названием «Задержка команд и пропускная способность» документа 248966 «Справочное руководство по оптимизации архитектур Intel® 64 и IA-32», также доступного на странице, указанной в ответе. stefanct 6 лет назад 0