Как операнд адреса влияет на производительность и размер машинного кода?

Question

Начиная с 32-разрядного режима ЦП, для архитектуры x86 доступны расширенные адресные операнды. Можно указать базовый адрес, смещение, индексный регистр и коэффициент масштабирования.

Например, мы хотели бы шагать через список 32-битные целые числа (каждый первые два из массива 32-байтовые длинных структур данных, %rdi как индекс данных, %rbx в качестве указателя базы).

addl $8, %rdi    # skip eight values: advance index by 8 
movl (%rbx, %rdi, 4), %eax # load data: pointer + scaled index 
movl 4(%rbx, %rdi, 4), %edx # load data: pointer + scaled index + displacement 

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

addl $32, %rbx  # skip eight values: move pointer forward by 32 bytes 
movl (%rbx), %eax # load data: pointer 
addl $4, %rbx  # point next value: move pointer forward by 4 bytes 
movl (%rbx), %edx # load data: pointer 

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

Каковы различия в производительности и размере кода между этими двумя подходами? Существуют ли какие-либо рекомендации по использованию расширенных операндов адреса?

Или, спрашивая его с точки зрения программиста C, что быстрее: индексирование массива или арифметика указателя?

---

Есть ли какой-либо монтажный редактор, предназначенный для настройки размера и производительности? Хотелось бы, чтобы я видел размер машинного кода каждой инструкции сборки, время ее выполнения в тактах или графике зависимости. Есть тысячи сборщиков, которые выиграют от такого приложения, поэтому я уверен, что что-то вроде этого уже существует!

Answer 1

Арифметика адресов очень быстрая и должна использоваться всегда, если это возможно.

Но вот что-то, о чем пропустил вопрос.

Сначала вы не можете умножить на 32, используя адресную арифметику - 8 - максимально возможная константа.

Первая версия кода не завершена, так как ей потребуется вторая инструкция, чтобы увеличить значение rbx. Итак, мы имеем следующие два варианта:

inc rbx   
mov eax, [8*rbx+rdi] 

против

add rbx, 8 
mov eax, [rbx] 

Таким образом, скорость обоих вариантов будет то же самое. Размер тот же - 6 байтов.

Итак, какой код лучше, зависит только от контекста программы - если у нас есть регистр, который уже содержит адрес нужен массив ячеек - использование MOV EAX, [RBX]

Если у нас есть регистр, содержащий индекс ячейки и другой, содержащий начальный адрес, затем используйте первый вариант. Таким образом, после завершения алгоритма, мы все равно будем иметь начальный адрес массива в rdi.

Answer 2

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

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

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

Вы также можете скачать исходный код gcc и посмотреть, как действительно крутые программисты оценивают последовательность, чтобы создать максимально возможный код. Однажды вы можете стать одним из них :-)

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