Самый быстрый целочисленный тип

#c++

Почему целочисленный тип, меньший чем размер машинного слова, обрабатывается медленней
чем тип размерностью = размеру машинного слова?

Тогда какой тип быстрей будет обрабатываться int > T или int < T?
    

Ответы

Ответ 1

Хотел я поработать разрушителем мифов ... Не получилось. "Миф" выдержал...

Была сделана тестовая программа на C:

int main()
 {
  unsigned char b,c,d;
  unsigned int a;
  struct timespec t,t1;
  int i;
  clock_gettime(CLOCK_REALTIME, &t);
  b=5; c=7; d=45;
  for(i=0;i<50000000;i++)
   {
    for(a=0;a<200;a++)
     {
      b^=c+d;
      c=d-b;
      d=b^5;
     }
   }
  clock_gettime(CLOCK_REALTIME, &t1);
  printf("Difference %ld %ld\n",t1.tv_sec-t.tv_sec,t1.tv_nsec-t.tv_nsec);
  printf("%d %d %d %d\n",a,b,c,d);
 }


Назовем ее программой 'A'. И точно такая же программа, но с переменными unsigned
int b,c,d - программа 'B'.
При компиляции gcc с оптимизацией -O3 получился следующий ассемблерный код основных
циклов, с моими комментариями с смыслом операций:

      Программа А                         Программа B
.L2:                                .L2:
    movl    $200, %eax   a=200          movl    $200, %eax     a=200
.L3:                                .L3:
    addl    %r9d, %r8d   c+=d           addl    %r9d, %r8d     c+=d
    movl    %r9d, %ecx   X=d            xorl    %r8d, %ebx     b^=c
    movl    $5, %r9d     d=5            movl    %r9d, %r8d     c=d
    xorl    %r8d, %ebx   b^=c           movl    %ebx, %r9d     d=b
    subb    %bl, %cl     X-=b           subl    %ebx, %r8d     c-=b
    xorl    %ebx, %r9d   d^=b           xorl    $5, %r9d       d^=5
    subl    $1, %eax     a--            subl    $1, %eax       a--
    movl    %ecx, %r8d   c=X
    jne     .L3          for(a)         jne     .L3            for(a)
    subl    $1, %edx     i--            subl    $1, %edx       i--
    jne     .L2          for(i)         jne     .L2            for(i)

                     Результаты выполнения:
 Difference 22 -30098974                Difference 19 -697228347
 Difference 22 394100751                Difference 18 2860932
 Difference 22 -37226465                Difference 18 3254312
 Difference 22 67398660                 Difference 18 43898871
 Difference 22 -29109230                Difference 18 449544279


Первое, что бросается в глаза, в варианте 'A' оптимизатор вводит новую "переменную"
'X', а точнее выполняет пересылку d в регистр ecx работает с ним и потом возвращает
обратно в d. Это связано с тем, что под переменную d он использует регистр R9 с младшим
байтом которого независимо работать невозможно, а для вычитания он предпочитает использовать
операцию той размерности, которую мы попросили. Поэтому использует ECX, младший байт
которого доступен как CL

Фактически оптимизатор как с 1 байтом в данном случае выполняет только вычитание.
А сложение и XOR он спокойно выполняет в полноразмерных, 4х байтовых регистрах, не
опасаясь побочных эффектов.

Дабы быстрее развеять миф я решил заменить в варианте 'A' subb bl,cl, на равнозначную
4х байтовую subl ebx,ecx. И тут меня ждал сюрприз, без каких либо еще правок программа
стала выполнятся 18 секунд, вместо 22. Процессор (в моем случае Core i7) выполняет
вычитание в 1 байтовых регистрах медленнее, чем в "полных", 4х байтовых. После я попробовал
так же операции add и xor и получил те же результаты.

После этого я сделал программу 'C' с типами unsigned long long, компилятор сгенерил
нормальные 64х битные операции, которые показали те же 18 секунд. Т.е. в 64х битном
режиме операции с int и long работают одинаково быстро. Проверка с типом short int,
т.е. c 16 битным дала 22 секунды, как и с 8-битным.


  Итого: Современные процессоры Intel, как минимум Core i7, выполняет операции в
однобайтовых регистрах медленнее, чем в 4х байтовых, почему - спросите архитекторов
процессоров Intel. Кроме того, в архитектуре x86 только с 4 из 16 регистров общего
назначения можно работать как с байтовыми, следовательно оптимизатору приходится генерить
более сложный код для обеспечения работы с такими типами.


Ответ 2

Предположу, что потому что при всех операциях он всё равно расширяется до int'а.

Скорее всего int самый быстрый. В x32 это даже писалось в книге, правда, не по си.
А вот для x64 имеет смысл проверить - вероятно будет или int32, или int64.

Хотя, проверить в любом случае имеет смысл - зачем спрашивать то, что можно измерить?