Медленная jmp-инструкция

TL: DR: я предполагаю, что заканчиваются записи BTB (целевой буфер ветвления). Конвейерная выборка кода должна предсказывать существование безусловного перехода еще до его декодирования. См. ниже.

Обновление 2021 года: https://blog.cloudflare.com/branch-predictor/ исследует это подробно, используя блок из jmp next_insn в качестве эксперимента. Например, могут иметь значение плотность ветвей и псевдонимы (одинаковое смещение относительно 64-байтовой строки).

Несмотря на то, что ваши jmp не работают, у ЦП нет дополнительных транзисторов для обнаружения этого особого случая. Они обрабатываются так же, как и любые другие jmp, что означает необходимость перезапуска выборки инструкций из нового места, создавая пузырь в конвейере.

Чтобы узнать больше о скачках и их влиянии на конвейерные ЦП, Управляйте опасностями в классическом конвейере RISC должно быть хорошим введением к тому, почему ветвления трудны для конвейерных процессоров. Руководства Агнера Фога объясняют практические последствия, но я думаю, что предполагаю наличие некоторых базовых знаний такого рода.

Ваш процессор Intel Broadwell имеет uop-cache, который кэширует декодированные инструкции (отдельно от кэш-память L1 32kiB).

Размер кэша мопов составляет 32 набора из 8 способов, по 6 мопов на строку, всего 1536 мопов (если каждая строка упакована по 6 мопов; отличная эффективность). 1536 мопс - это между вашими 1000 и 10000 размерами теста. Перед вашим редактированием я предсказал, что отсечка от медленного к быстрому будет примерно 1536 инструкций в вашем цикле. Он вообще не замедляется до тех пор, пока не превысит 1536 инструкций, поэтому я думаю, что мы можем исключить эффекты uop-cache. Это не такой простой вопрос, как я думал. :)

Запуск из uop-cache (небольшой размер кода) вместо декодеров инструкций x86 (большие циклы) означает, что меньше этапов конвейера перед этапом, который распознает jmp инструкции. Таким образом, мы можем ожидать, что пузыри от постоянного потока скачков будут меньше, даже если они предсказаны правильно.

Предполагается, что запуск от декодеров приведет к большему штрафу за неверное предсказание ветвления (например, может быть 20 циклов вместо 15), но это не неверно предсказанные ветвления.

Даже несмотря на то, что ЦП не нужно предсказывать, взято ли ветвление или нет, он по-прежнему использует ресурсы предсказания ветвления, чтобы предсказать, что блок кода содержит взятую ветвь, прежде чем он будет декодирован.

Кэширование того факта, что в определенном блоке кода есть ветвь и его целевой адрес, позволяет интерфейсу начать выборку кода из цели ветвления до фактического декодирования кодировки jmp rel32. Помните, что декодировать инструкции x86 переменной длины сложно: вы не знаете, где начинается одна инструкция, пока не будет декодирована предыдущая. Таким образом, вы не можете просто сопоставить поток инструкций по шаблону, ища безусловные переходы / вызовы, как только он будет получен.

Моя текущая теория заключается в том, что вы замедляетесь, когда у вас заканчиваются записи Branch-target-buffer.

См. Также Какое неверное предсказание ветвления обнаруживает целевой буфер ветвления?, у которого есть хороший ответ и обсуждение в этой ветке Realworldtech.

Один очень важный момент: BTB предсказывает, какой блок будет извлекаться следующим, а не точное место назначения конкретной ветви в блоке выборки. Поэтому вместо того, чтобы прогнозировать цели для всех ветвей в блоке выборки, просто необходимо чтобы предсказать адрес следующей выборки.

Да, пропускная способность памяти может быть узким местом при выполнении таких операций с очень высокой пропускной способностью, как xor-zeroing, но с jmp вы сталкиваетесь с другим узким местом. ЦП успеет извлечь 42 Б из памяти, но это не то, что он делает. Предварительная выборка может легко справиться с 2 байтами за 3 такта, поэтому пропусков I-кеша L1 должно быть почти нулевым.

В вашем xor с / без REX-теста пропускная способность основной памяти могла быть узким местом, если вы тестировали с достаточно большим циклом, который не помещался в кэш L3. Я потребляю 4 * 2 Байт за цикл на процессоре с тактовой частотой ~ 3 ГГц, что примерно соответствует максимальной скорости 25 Гбайт / с DDR3-1600 МГц. Тем не менее, даже кэш L3 будет достаточно быстрым, чтобы не отставать от 4 * 3Б за цикл.

Что интересно, узким местом является BW основной памяти; Сначала я предположил, что декодирование (блоками по 16 байт) будет узким местом для 3-байтовых операций XOR, но я думаю, что они достаточно малы.

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

Для сравнения тактовых циклов используйте perf stat ./a.out. Существуют и другие полезные счетчики производительности, которые необходимы для понимания характеристик производительности.

См. x86-64 Относительная производительность jmp для результатов счетчика производительности из Core2. (8 циклов на jmp) и какая-то неизвестная микроархитектура, где это ~ 10c на jmp.

Подробности характеристик производительности современных ЦП достаточно сложно понять даже в более или менее условиях белого ящика (читая руководство Intel по оптимизации и то, что они опубликовали о внутреннем устройстве ЦП). Вы рано и часто застрянете, если будете настаивать на тестировании черного ящика, когда вы не читаете такие вещи, как статьи arstechnica о новом дизайне процессора, или, может быть, некоторые более подробные вещи, такие как Обзор микроархитектуры Haswell или аналогичную статью о Sandybridge, на которую я ссылался ранее.

Если застревать рано и часто - это нормально, и вам весело, то во что бы то ни стало продолжайте делать то, что делаете. Но людям труднее отвечать на ваши вопросы, если вы не знаете этих деталей, как в этом случае. : / например моя первая версия этого ответа предполагала, что вы прочитали достаточно, чтобы узнать, что такое кеш uop.