Почему const int быстрее const int &?

Question

Я заметил это случайно однажды, и теперь решил тщательно его протестировать.

Так что, когда я вызвать функцию:

#define Type int 
#define Prm const Type & 
Type testfunc1(Prm v1, Prm v2, Prm v3, Prm v4, Prm v5, Prm v6, Prm v7, Prm v8, Prm v9, Prm v10){ 
    return (v1|v2|v3|v4|v5|v6|v7|v8|v9|v10); 
} 

100 миллион раз:

 for(Type y = 0; y < 10000; y++){ 
      for(Type x = 0; x < 10000; x++){ 
       out |= testfunc1(x,y,x,x,y,y,x,y,x,y); 
      } 
     } 

С типами int, const int и const int &, я заметил, что const int быстрее, чем const int &. (Примечание: im использует возвращаемое значение, чтобы гарантировать, что функция не будет оптимизирована).

Почему это так? Я всегда думал, что добавление & действительно сделает это быстрее, но тесты говорят об обратном. Я знаю, что для более крупных типов данных это, вероятно, будет другой результат, я не тестировал их, хотя, поскольку я совершенно уверен в результатах.

Мои тесты:

const int: 7.95s 
const int &: 10.2s 

Edit: Я думаю, что это на самом деле из-за моей архитектуры; Я тестировал с Sint64 типа и результаты были:

const Sint64: 17.5s 
const Sint64 &: 16.2s 

Edit2: Или это? Испытано с double типа (который является 64-битной?), И результаты заставляют меня озадачило:

const double: 11.28s 
const double &: 12.34s 

Edit3: обновлен код цикла, чтобы соответствовать моим новейшие тесты с типами 64-битных.

Answer 1

Поместив в аргумент &, вы добавляете в программу больше кода.Без &, эта последовательность:

push values 
call Function 
pop values <- usually an update to stack pointer 

и функции:

return sp[arg1] | sp[arg2] | etc <- value read direct from stack. 

Добавление '&' делает это:

push address of value1 
push address of value2 
etc 
call Function 
pop values <- usually an update to stack pointer 

и функции:

return_value = 0; 
address = sp[arg1] 
or return_value, [address] 
address = sp[arg2] 
or return_value, [address] 
etc 
return return_value 

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

Answer 2

Этот результат сильно зависит от системы. Это указывает на то, что на вашей конкретной системе копирование значения ссылки (которое, скорее всего, реализовано как указатель) имеет более высокую стоимость, чем копирование значения целого числа. Наиболее вероятной причиной этого различия является то, что для вашего целого требуется 32 бита для представления, а вашему представлению указателя/ссылки требуется 64 бит. EDIT Это не говоря уже о стоимости , обращаясь к целым числам: получение их значений потребует дополнительной косвенности. Поскольку вы передаете только два элемента, использование кеширования скрывает дополнительную стоимость в значительной степени, но стоимость там.

Вы абсолютно правы в более крупных типах: передавая ссылку на, скажем, большой struct или vector<...>, по-прежнему требуется только 64 бит (или что бы то ни было в вашей системе), независимо от количества элементов вашей структуры имеет или сколько предметов находится у вашего vector<...>. Чем больше структура, тем выше затраты, чтобы передать ее по стоимости, и, следовательно, экономия, которую вы понимаете, сделав ее ссылкой.

Answer 3

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

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