Прав ли я в том, что первые две инструкции MOV занимают только 2 (они обе перемещают память для регистрации) цикла ЦП? Я думал, что вызов виртуального метода был медленнее, чем это? На странице 178 таблицы задержки команд указано, что задержка этого вызова составляет 2 цикла ЦП (я так думаю?).
Нет, 2 цикла ЦП только с минимальной задержкой.
Давайте проверим таблицы Агнера http://www.agner.org/optimize/instruction_tables.pdf
Целочисленные инструкции.
Инструкция Операнды uops слитый домен uops nonused domain (p015 p0 p1 p5 p23 p4) Задержка Взаимная пропускная способность Комментарии
Inst Oper fus p23 p4 Latency Rec.
MOV r32/64,m32/64 1 1 2 0.5
Чтобы узнать время, когда инструкция даст свой результат, используйте столбец «Задержка». И задержка составляет 2 цикла для каждого mov, и указано только минимальное значение (проверьте текст в «Объяснение заголовков столбцов» - «Задержка - это задержка, которую инструкция генерирует в цепочке зависимостей. Числа являются минимальными значениями. Отсутствует кеш , несовпадение, ... может значительно увеличить счетчик часов. ")
Если у вас много разных полиморфных вызовов, необходимая для них память может не кэшироваться. Нам известны задержки кеширования и памяти из различных обзоров, и все они были измерены с помощью длинная цепочка зависимых MOVs, например mov eax, [eax]; mov eax, [eax]; mov eax, [eax]; .... Значения для Ivy: попадание в L1 = 4 цикла, попадание в L2 = 11 циклов, попадание в L3 = 30-40 циклов, промах в кеш-памяти и доступ к памяти = 32 цикла + 60 нс (на 3 ГГц с 3 циклами на нс> 200 циклы). Нет даже простого случая, чтобы получить задержку в 2 цикла (что ближе к ALU, чем L1? Только буфер загрузки с 72 записями для переупорядоченных загрузок?), И не будет шансов получить задержку в 2 цикла на втором mov (его операнде является результатом первого мова, поэтому нет ничего, что могло бы выполнить не по порядку перед удалением первого мова).
В таблицах http://instlatx64.atw.hu/, ссылки на которые есть на Ссылки Агнера есть отчет для Айви InstLatX64 для Intel Core i7-3770K, 3700 МГц, созданный с помощью aida_bench64.dll
27 AMD64: MOV r64, [m64] L: 1,14 нс = 4,0c T: 0,14 нс = 0,50c
И эта таблица показывает реальную задержку (L) для попадания в кэш L1, 4 цикла.
Те же данные (4c для L1, ~ 12c для L2, 26-31c для L3) в 64-ia-32-architecture-optimisation-manual.pdf стр. 46 раздел« 2.2.5.1 Обзор операций загрузки и сохранения ", Таблица" 2-10 Порядок поиска и задержка загрузки "
Так что, согласно буклету Fog, вышеупомянутый ASM требует 6 циклов ЦП, я ничего не понял неправильно?
В лучшем случае, когда первая загрузка была выполнена раньше с Out-of-order = 2 цикла на критическом пути; второе попадание нагрузки в L1 = 4 цикла на критическом пути; 2 цикла на исполнение call; BTB (прогнозирование цели ветвления / косвенная цель ветвления) было успешным, что более вероятно, когда с одного адреса вызова вы всегда переходите к одной и той же цели (или к небольшому количеству целей с периодическими шаблонами) - у вас будет 8 циклов для подтверждения эта ветвь была предсказана правильно, что может быть частично скрыто OoO выполнением целевой функции.
Если какая-либо нагрузка отсутствует в L1 / L2, вы должны добавить соответствующую задержку кэша. Если L3 отсутствует, добавьте 200 циклов.
Если BTB пропустит, у вас будет как минимум 15 штрафных циклов (см. Microarchitecture.pdf Агнера , стр. 27 «3.7 Предсказание переходов в Intel Sandy Bridge и Ivy Brindge; штраф за неправильное предсказание») - для кэшированных мопов; больше для цели в L1i. Вы можете прочитать о более старых BTB на той же странице microarchitecture.pdf, стр. 25 «3.5 Прогнозирование переходов в PM и Core2; Распознавание образов для непрямых переходов и вызовов» и «Организация BTB .. для непрямых переходов и непрямых вызовов».
Очень полезный документ взят из Intel: "Справочное руководство по оптимизации архитектур Intel® 64 и IA-32" 64-ia-32-architecture-optimisation-manual.pdf. В нем есть как предложения по настройке, так и информация о счетчиках производительности, которые помогут вам получить реальные задержки и частоту пропусков для вашего кода (см. Раздел B.6.3.2 «Виртуальные таблицы и косвенные вызовы»).
person
osgx
schedule
15.03.2014
