Является mov rax,0x12345678; JMP Rax по-прежнему убивает предсказание отрасли?

Question

У меня проблемы с поиском информации, относящейся к двум случаям, описанным выше, и хотя я слышу ваше мнение эксперта.

Во-первых, я знаю, что косвенные jmps наносят ущерб прогнозированию ветвлений, и что даже когда результат косвенности постоянен, он все еще требует буфера обслуживания предсказания и прочего, все по сравнению с абсолютным jmp.

Мой вопрос, если кто-нибудь знает, если:

mov rax, 1234567812345678h;
jmp rax;

Предсказатель ветвления процессора все еще считается косвенным или выполняет математические вычисления в этом случае... Я делаю это потому, что в x64 нет инструкции "jmp absolute 64":/

Во-вторых, в какой степени существует реальная разница между jmp 0x1234 и вызовом 0x1234 (с точки зрения оптимизации процессора (кэш инструкций, prefetcher и его подсказки, прогноз ветвлений))? (vc2012 "Оптимизация скорости" приводит к вызову, "min_size opt" возвращает jmp, "смешанная оптимизация" возвращает jmp для x64, вызов для x86)

Спасибо всем заранее!

Answer 1

Предсказание цели (и ветви) корпорации Intel является одновременно очень сложным и тщательно охраняемым коммерческим секретом. Не обязательно существует один единственный алгоритм, то есть можно ожидать, что механизмы прогнозирования различаются в зависимости от ЦП; Это зависит от количества транзисторов, которые Intel хочет решить для данного процессора. И, конечно, помимо Intel, существуют и другие производители процессоров x86 и x64.

Механизм прогнозирования цели исторической ветви - который использует прошлые прогоны одной и той же инструкции для прогнозирования цели для последующих выполнений - почти наверняка предскажет правильную цель для этой ветви, потому что есть только одна. Таким образом, если эта кодовая последовательность выполняется повторно (например, в цикле), и она некоторое время остается в кеше команд, она, вероятно, будет обрабатываться очень хорошо. (Однако на некоторых процессорах механизм прогнозирования цели перехода может быть нейтрализован с помощью эффекта, аналогичного коллизии строк кэша, если другая ветвь в другом месте вызывает коллизию хеша.)

Вероятно, еще больший вопрос заключается в том, насколько хорошо она обрабатывается, если такая последовательность свободно встречается в коде, недавно загруженном в кэш, что относится к возможностям нецелевого прогнозирования целей процессора. Такое (неисторическое) целевое предсказание ветвления могло бы легко определить местоположение ветвления, учитывая эту кодовую последовательность, хотя это полностью зависит от того, считает ли производитель, что оно достойно недвижимости на кристалле для любого данного процессора. Факторы, принимающие такое решение, включают энергопотребление, компромиссы с другими улучшениями производительности (т. Е. Возможное лучшее использование той же области матрицы) и ожидаемую частоту таких и различных других последовательностей кода.

Answer 2

«Я знаю, что непрямые переходы вредят прогнозированию ветвей»

Нет. Предсказание ветвления и предсказание непрямого перехода — это разные вещи. Более того, непрямые переходы используются в операторах switch на основе таблиц и в интерпретаторах. Это очень распространенные варианты использования, и они проявляются в тестах. Следовательно, Intel и другие потратили много усилий и много транзисторов, улучшающих их производительность. В одной статье (написанной задолго до вопроса!) даже говорилось, что, начиная с Sandy Bridge, вы не должны доверять фольклору , когда дело доходит до предсказания косвенного прыжка. У Intel+AMD есть стимул улучшить эту производительность, и они это сделали.

Теперь, если ваш пример jmp представляет собой холодный код, если он выполняется впервые, его невозможно предсказать, и действительно предсказатель косвенного перехода Skylake будет предсказывать следующую инструкцию после перехода и делать предположения оттуда. Вы можете пресечь эту спекуляцию с помощью UD2, нелегальной инструкции. В любом случае, при втором выполнении jmp (если он все еще находится в BTB) цель перехода будет правильной.

Что касается вашего второго вопроса, эффекты кеша не будут иметь значения. Я предполагаю, что меньшая версия могла бы героически спасти разлив строки кэша, но это все. Предварительная выборка HW предназначена для данных, а не для инструкций.