Как следует определять типы [u] int_fastN_t для x86_64, с ABI для x32 или без него?

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

Обычно нет необходимости расширять 32-битные при загрузке их в 64-битные регистры. Хотя в этом случае ЦП автоматически расширяет значения нулями, обычно это дает только преимущество, поскольку позволяет избежать частичных остановок регистров. То, что загружается в верхнюю часть регистра, менее важно, чем то, что изменяется весь регистр. Содержимое верхней части регистра не имеет значения, потому что, когда они используются для хранения 32-битных типов, они обычно используются только с 32-битными инструкциями, которые работают только с нижней 32-битной частью регистра.

Несоответствие между размерами типов int_fast32_t при использовании ABI x32 и x86-64, вероятно, лучше всего оправдано тем фактом, что указатели имеют ширину 64 бита. Всякий раз, когда к указателю добавляется 32-битное целое число, его необходимо расширять, что делает это более вероятным при использовании x86-64 ABI.

Еще один фактор, который следует учитывать, заключается в том, что весь смысл x32 ABI заключается в повышении производительности за счет использования меньших типов. Любое приложение, которое выигрывает от меньшего размера указателей и связанных типов, должно также выиграть от int_fast32_t меньшего размера.

Я скомпилировал следующий пример кода, чтобы проверить сгенерированный код на простую сумму с разными целочисленными типами:

#include <stdint.h>

typedef int16_t INT;
//typedef int32_t INT;
//typedef int64_t INT;

INT foo()
{
    volatile INT a = 1, b = 2;
    return a + b;
}

А затем я разобрал код, сгенерированный для каждого из целочисленных типов. Команда компиляции gcc -Ofast -mx32 -c test.c. Обратите внимание, что в полном 64-битном режиме сгенерированный код будет почти таким же, потому что в моем коде нет указателей (только %rsp вместо %esp).

С int16_t он излучает:

00000000 <foo>:
   0:   b8 01 00 00 00          mov    $0x1,%eax
   5:   ba 02 00 00 00          mov    $0x2,%edx
   a:   67 66 89 44 24 fc       mov    %ax,-0x4(%esp)
  10:   67 66 89 54 24 fe       mov    %dx,-0x2(%esp)
  16:   67 0f b7 54 24 fc       movzwl -0x4(%esp),%edx
  1c:   67 0f b7 44 24 fe       movzwl -0x2(%esp),%eax
  22:   01 d0                   add    %edx,%eax
  24:   c3                      retq   

С int32_t:

00000000 <foo>:
   0:   67 c7 44 24 f8 01 00 00 00  movl   $0x1,-0x8(%esp)
   9:   67 c7 44 24 fc 02 00 00 00  movl   $0x2,-0x4(%esp)
  12:   67 8b 54 24 f8              mov    -0x8(%esp),%edx
  17:   67 8b 44 24 fc              mov    -0x4(%esp),%eax
  1c:   01 d0                       add    %edx,%eax
  1e:   c3                          retq   

И с int64_t:

00000000 <foo>:
   0:   67 48 c7 44 24 f0 01 00 00 00   movq   $0x1,-0x10(%esp)
   a:   67 48 c7 44 24 f8 02 00 00 00   movq   $0x2,-0x8(%esp)
  14:   67 48 8b 54 24 f0               mov    -0x10(%esp),%rdx
  1a:   67 48 8b 44 24 f8               mov    -0x8(%esp),%rax
  20:   48 01 d0                        add    %rdx,%rax
  23:   c3                              retq   

Я не утверждаю, что точно знаю, почему компилятор сгенерировал именно этот код (может быть, ключевое слово volatile в сочетании с целочисленным типом не регистрового размера - не лучший выбор?). Но из этого сгенерированного кода мы можем сделать следующие выводы:

1. Самый медленный тип - int16_t. Для перемещения значений требуются дополнительные инструкции.
2. Самый быстрый тип - int32_t. Хотя 32-разрядная и 64-разрядная версии имеют одинаковое количество инструкций, 32-разрядный код короче в байтах, поэтому он будет более удобен для кеширования, а значит, быстрее.

Итак, естественным выбором для быстрых типов будет:

1. Для int_fast16_t выберите int32_t.
2. Для int_fast32_t выберите int32_t.
3. Для int_fast64_t выберите int64_t (что еще).

Жесткий. Давайте просто возьмем int_fast8_t. Если разработчик использует большой массив для хранения множества 8-битных целых чисел со знаком, тогда int8_t будет самым быстрым из-за кеширования. Я бы сказал, что использование больших массивов int_fast8_t, вероятно, плохая идея.

Вам нужно будет взять большую кодовую базу и систематически заменять int8_t, подписанные символы и простой char, если он подписан с помощью int_fast8_t. Затем протестируйте код, используя различные определения типов для int_fast8_t, и измерьте, что является самым быстрым.

Обратите внимание, что поведение undefined изменится. Например, присвоение 255 даст результат -1, если тип int8_t, и 255 в противном случае.