Я генерирую некоторые коды операций динамически в JIT-компиляторе и ищу рекомендации по выравниванию кодов операций.

1) Я читал комментарии, которые вкратце "рекомендуют" выравнивание, добавляя nops после звонков.

2) Я также читал об использовании nop для оптимизации последовательностей для параллелизма.

3) Я читал, что выравнивание операций хорошо для производительности "кеша".

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

Я замечаю, что компиляторы обычно запускают нечетную байтовую инструкцию сразу после любой предыдущей последовательности инструкций. Таким образом, в большинстве случаев компилятор не проявляет особой заботы. Я вижу "nop" здесь или там, но обычно кажется, что nop используется редко, если вообще используется. Насколько критично выравнивание кода операции? Можете ли вы предоставить ссылки на кейсы, которые я действительно могу использовать для реализации? Спасибо.

4
codenheim 21 Мар 2010 в 05:56
В качестве отдельного ответа я принял решение DigitalRoss, но оба были хорошими. Ссылка, которую предоставил Мартин, оказалась наиболее полезной из всех (настоящая золотая жила) и ответила на немало моих последующих вопросов сегодня вечером. Спасибо вам обоим.
 – 
codenheim
21 Мар 2010 в 08:29

2 ответа

Лучший ответ

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

Современные процессоры переведут ваши операции ISA в микрооперации в любом случае. Это может сделать классические методы выравнивания менее важными, поскольку, по-видимому, транскодер микроопераций будет пропускать nops и изменять как размер, так и выравнивание секретных истинных машинных операций.

Однако к тому же оптимизация, основанная на основных принципах, не должна причинить почти никакого вреда.

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

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

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

5
DigitalRoss 21 Мар 2010 в 20:03
1
+1 Спасибо за еще один хороший ответ. Да, я только что читал о микрооперациях и переупорядочивании по ссылкам Мартина.
 – 
codenheim
21 Мар 2010 в 08:25

Лучшим источником всех этих микрооптимизаций является руководства по оптимизации x86 от Agner Fog. В этих документах должно быть все, что вам нужно, и еще немного. :)

Одна вещь, о которой я могу думать, - это выровнять цикл так, чтобы код цикла не пересекал границу строки кеша, то есть цикл имеет размер <64 байтов и начинается с адреса, кратного 64. Тогда весь цикл будет помещаться в один кеш line и оставьте больше строк кеша для других вещей. Я сомневаюсь, что это будет иметь значение в реальной программе, независимо от того, насколько «горячим» окажется этот конкретный цикл.

4
Martin 21 Мар 2010 в 06:13