Почему 2 числа, : разделены?
Инструкция имеет 2 входа и 2 мопа (неиспользуемый домен), поэтому оба входа не нужны одновременно . например, адрес памяти необходим для загрузки, но входной векторный регистр не требуется, пока загрузка не будет готова.
Поэтому в значении задержки есть 2 отдельных поля.
Нажмите на ссылку с номером задержки в https://uops.info/, чтобы узнать, какой операнд к какому результату и какой задержке.
https://www.uops.info/html-lat/SKL/PCMPEQB_XMM_M128-Measurements.html разрывы это для этой специфической инструкции c для Skylake, которая имеет 2 входа и один выход (в том же операнде, что и один из входов, потому что это версия не VEX. (Забавный факт: это позволяет сохранить микро сливается даже с индексным режимом адресации в HSW и более поздних версиях, в отличие от версии VEX)):
операнд 1 (r / w): регистр XMM
операнд 2 (r): память
- Операнд задержки 1 → 1: 1
- Операнд задержки 2 → 1 (адрес, базовый регистр): ≤8
- Операнд задержки 2 → 1 (память) : ≤5
и ниже, что есть инструкция speci c последовательности, которые использовались для проверки этой инструкции.
В этом подробном разборе результаты тестирования uops.info действительно блестят по сравнению с любыми другими результатами тестирования или опубликованными числами, особенно для многопользовательских инструкций, таких как mul или shr reg, cl , например, для сдвигов задержка от рег или счетчика сдвигов до выхода составляет всего 1 цикл; дополнительные мопы предназначены только для объединения FLAGS.
Переменная задержка: почему ≤8
Задержка пересылки в магазине равна переменная в SnB семейство и генерация адреса / L1d Задержка использования нагрузки также может быть ( Существует ли штраф, если база + смещение находятся на странице, отличной от базы? ). Обратите внимание, что у этого есть операнд источника памяти. Но это , а не , почему задержка указана как ≤ n.
Значения задержки ≤n являются верхним пределом, я думаю. не означает, что задержка от этого операнда может быть столь же низкой, как 1.
Я думаю, что они дают верхнюю границу только в тех случаях, когда они не смогли окончательно Точный тест на определенную нижнюю границу.
Инструкции типа PMOVMSKB (R32, XMM), которые производят свои выходные данные в другом домене, чем их ввод, очень трудно определить. Вам необходимо использовать другие инструкции для перенаправьте вывод обратно во вход, чтобы создать цепочку зависимостей, перенесенную в oop, и сложно спланировать эксперименты, чтобы возложить вину на одну часть цепочки против другой.
Но в отличие от InstLatx64 , люди, стоящие за https://uops.info/, не просто сдались в этих случаях. Их тесты намного лучше, чем ничего!
Например, у магазина / перезагрузки есть некоторая задержка, но как выбрать, какой из них винить магазин в сравнении с нагрузкой? (Разумным выбором было бы указать задержку загрузки в качестве задержки использования нагрузки L1d, но, к сожалению, это , а не , что выбрал Агнер Фог . Его задержки по сравнению с задержками хранилища абсолютно произвольны, например, делится пополам или около того, что приводит к безумно низкой задержке загрузки, которая не является задержкой загрузки: /)
Существуют различные способы получения данных из целочисленных регистров обратно в регистры XMM в качестве входной зависимости для pmovmskb: ALU через movd или pinsrb/w/d/q, или загрузку. Или на процессорах AVX512 через kmov и затем с использованием маскированной инструкции. Ничто из этого не является простым, и вы не можете предположить, что задержка использования нагрузки для нагрузки SIMD будет такой же, как целочисленная загрузка. (Мы знаем, что задержка пересылки в хранилище выше.)
Как и в комментариях @BeeOnRope, uops.info, как правило, повторяет передачу в оба конца, а отображаемая задержка - это значение всего цикла, за вычетом любых известных инструкций заполнения, минус 1 . Например, если вы рассчитываете круговую поездку GP -> SIMD -> GP в 4 цикла (без заполнения), обе эти инструкции будут отображаться как <= 3. </strong>
Получая верхнюю границу для каждого, вы, вероятно, можете предположить, что любая инструкция имеет как минимум 1 тактовую задержку. например, для цепочки pmovmskb -> movd можно предположить, что movd имеет как минимум 1 цикл задержки, поэтому задержка pmovmskb составляет самое большее задержка туда-обратно минус 1. Но на самом деле она, вероятно, меньше.
* Например, 1100 *
https://www.uops.info/html-lat/SKL/DIVPD_XMM_M128-Measurements.html показывает разные «задержки цепи» для разных экспериментов. например, для одного из тестов 1 -> 1, который запускает divpd, а ORPD и ANDPD создают цепочку dep с одним и тем же дивидендом, uops.info перечисляет известную задержку этих дополнительных инструкций в цепочке dep. Это перечисляет это как Задержка цепи: ≥10 . (Теоретически оно может быть выше, если конфликт ресурсов или какой-либо другой эффект приводят к тому, что он не всегда дает результат ровно через 10 циклов после того, как выходные данные divpd были готовы. Цель этих экспериментов состоит в том, чтобы поймать странные эффекты, которые мы, возможно, не ожидали.) «Базовые циклы: 44,0» минус задержка цепочки не менее 10, можно сказать, что задержка divpd составляет не более 34, а остальная часть цепи депо составляет остальные 10 (но, возможно, больше).
(34.0 кажется высоким; возможно, я что-то неправильно истолковываю. Входные данные содержат много значительных битов мантиссы, по сравнению с экспериментом 2, который, я думаю, выполняет 1.0 / 1.0, и ничего больше в l oop, измеряющем 6 задержка цикла от XMM -> XMM как лучший случай.)
Обратите внимание, что я просто говорю о случае xmm -> xmm здесь, а не об их более сложных тестах, которые возвращают вывод XMM как зависимость для адрес или содержимое памяти.