Ветви микрокодов, по-видимому, особенные.
Семейства Intel P6 и SnB не поддерживают динамическое предсказание для ветвей микрокодов , согласно описанию Энди Глью оригинального P6 ( Что делает установкаREP делать? ).Учитывая аналогичную производительность команд rep -строк семейства SnB, я предполагаю, что этот факт PPro применим даже к самым последним процессорам Skylake / CoffeeLake 1 .
Но естьштраф за неправильное предсказание ветви микрокода, поэтому они статически (?) предсказаны .(Вот почему rep movsb стоимость запуска идет с шагом 5 циклов для низких / средних / высоких значений в ECX и выравнивается по сравнению со смещением.)
Микрокодированная инструкция занимает всю строку сама по себев кеше моп. Когда он достигает передней части IDQ, он переходит к этапу выпуска / переименования до тех пор, пока не завершится выдача микрокодов. (См. Также Как микрокоды выполняются во время цикла инструкций? для получения дополнительной информации.подробности и некоторые свидетельства из описаний событий perf, таких как idq.dsb_uops, которые показывают, что IDQ может принимать новые мопы из кэша мопов , в то время как этап чтения / переименования читает из микрокод-секвенсора.)
Для команд rep -строки, я думаю, что каждая итерация цикла должна на самом деле выдавать через интерфейс, а не просто цикл внутри , и повторно использовать эти мопы.Так что это включает в себя обратную связь от OoO back-end, чтобы узнать, когда инструкция завершена.
Я не знаю подробностей того, что происходит, когда выпуск / переименование переключается на чтение мопов с MS-ROMвместо IDQ.
Несмотря на то, что у каждого мопа нет собственного RIP (являющегося частью одной микрокодированной инструкции), я бы предположил, что механизм обнаружения неверных предсказаний ветвлений работает аналогично обычным ветвям.
rep movs Время установки некоторых процессоров, по-видимому, составляет 5 циклов, в зависимости от того, какой это случай (маленький или большой, выравнивание и т. Д.).Если они получены из ошибочного прогноза ветви микрокода, это может означать, что штраф за неправильный прогноз представляет собой фиксированное число циклов, если только это не частный случай rep movs.Может быть, потому, что серверная часть OoO может идти в ногу с интерфейсом?А чтение с MS-ROM сокращает путь даже больше, чем чтение из кэша UOP, делая таким образом низкий штраф за промах.
Было бы интересно провести некоторые эксперименты, чтобы выяснить, насколько возможен OoO exec.вокруг rep movsb, например, с двумя цепочками зависимых imul инструкций, чтобы увидеть, если (частично) сериализует их как lfence.Мы надеемся, что нет, но чтобы достичь ILP, последующие imul мопы должны были бы выпустить, не дожидаясь, пока не истечет серверная часть.
Я провел здесь некоторые эксперименты на Skylake (i7-6700k).Предварительный результат: размеры копий 95 байтов и меньше дешевы и скрыты задержкой цепочек IMUL, но в основном они полностью перекрываются. Копии размером 96 байт или более истощают RS, сериализуя две цепочки IMUL. Не имеет значения, является ли rep movsb с RCX = 95 против 96 или rep movsd с RCX = 23 против24. См. Обсуждение в комментариях для более краткого изложения моих выводов;если я найду время, я опубликую более подробную информацию.
Поведение «дренирует RS» измерялось с rs_events.empty_end:u, даже становящимся 1 на rep movsb вместо ~ 0,003.other_assists.any:u было ноль, так что это не «помощь», или, по крайней мере, не считается как единица.
Возможно, что бы ни включал UOP, он обнаруживает неправильный прогноз только при выходе на пенсию, если ветви микрокода не поддерживают быстрое восстановлениечерез BoB?Порог в 96 байт, вероятно, является отсечкой для некоторой альтернативной стратегии.RCX = 0 также истощает RS, предположительно потому, что это также особый случай.
Было бы интересно проверить с rep scas (который не поддерживает быстрые строки, а просто медленный и тупой микрокод.)
Патент Intel на быстрые строки 1994 года описывает реализацию в P6. У него нет IDQ (поэтому имеет смысл, что современные процессоры, которые имеют буферы между этапами и кэш-памятью uop, будут иметь некоторые изменения), но механизм, который они описывают для избежания ветвей, аккуратен и, возможно, все еще используется для современной ERMSB: Первые n итерации копирования являются предикатными мопами для серверной части, поэтому они могут быть выполнены безоговорочно. Существует также моп, который заставляет серверную часть отправлять свое значение ECX в секвенсор микрокода, который использует его для точного ввода нужного количества дополнительных итераций копирования после этого. Только копирование мопов (и, возможно, обновления ESI, EDI и ECX, или, может быть, это происходит только при прерывании или исключении), а не мопы ветвей микрокода.
Это начальное n число мопов против подачи после чтения RCX могло быть 96-байтовым порогом, который я видел; с 10 * 573 * (с 4 до 5).
https://eprint.iacr.org/2016/086.pdf предполагает, что микрокод может вызывать помощь в некоторых случаях, что может быть современным механизмом для больших размеров копий и объясняет слив RS (и, очевидно, ROB), потому что это срабатывает только тогда, когда uop имеет значение commit (удалено), поэтому это похоже на ветку без быстрого восстановления.
Исполнительные блоки могут выдавать помощь или сигнализировать о неисправности, связывая код события с результатом микрооперации. Когда микрооперация зафиксирована (§ 2.10), код события заставляет планировщик с нарушением порядка уничтожить все микрооперации, которые находятся в полете в ROB. Код события передается в секвенсор микрокодов, который считывает микрооперации в соответствующем обработчике событий "
Разница между этим и патентом P6 заключается в том, что этот запрос на помощь может произойти после того, как уже были выпущены некоторые не микрокодовые мопы из более поздних инструкций, в ожидании завершения микрокодированной инструкции только с первой партией мопов. Или, если это не последний моп в пакете из микрокода, его можно использовать как ветку для выбора другой стратегии.
Но именно поэтому он должен смывать РОБ.
Мое впечатление о патенте P6 состоит в том, что обратная связь с MS происходит до того, как будут выпущены мопы из более поздних инструкций, во время, когда в случае необходимости будет выпущено больше мопов MS. Если я не прав, то, возможно, это уже тот же механизм, который все еще описан в статье 2016 года.
Обычно, когда ветвь ошибочно предсказывает, что она берется, тогда, когда инструкция удаляется ,
Intel, поскольку Nehalem имеет «быстрое восстановление», запускающее восстановление, когда неправильно предсказанная ветвь выполняет , не ожидая, пока она достигнет выхода на пенсию как исключение.
Это точка, в которой ветвь Order-Order-Buffer находится поверх обычного состояния удаления ROB, что позволяет вам откатываться, когда любой другой тип неожиданного события становится не спекулятивным. ( Что именно происходит, когда процессор Skylake неверно предсказывает ветвь? )
Сноска 1 : Предполагается, что IceLake имеет функцию "быстрого короткого повторения", которая может быть другим механизмом обработки строк rep, а не изменением микрокода. например может быть, машина состояния HW, как Энди упоминает, что он хотел бы спроектировать в первую очередь.
У меня нет никакой информации о характеристиках производительности, но как только мы узнаем что-то, мы сможем сделать некоторые предположения о новой реализации.