Доступ к памяти медленнее, чем сдвиг?

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

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

Пример фрагмента кода устройства Даффа:

void copy_duff(register short *to, register short *from, register  count)
{
    register n=(count+7)/8;
    switch(count%8) {
        case 0:    do {    *to = *from++;
        case 7:        *to = *from++;
        case 6:        *to = *from++;
        case 5:        *to = *from++;
        case 4:        *to = *from++;
        case 3:        *to = *from++;
        case 2:        *to = *from++;
        case 1:        *to = *from++;
        } while(--n>0);
    }
}

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

*p

против . что из

p + 1

, где p - указатель на int, значение которого не нужно извлекать из памяти (потому что оно уже находится в регистре ЦП). Вообще говоря, арифметические устройства современных ЦП работают, по крайней мере, в несколько раз быстрее, чем подсистемы подсистемы памяти, даже для тех ячеек памяти, содержимое которых в настоящее время доступно из самого быстрого кеша ЦП, поэтому обычно можно ожидать, что последний будет быстрее.

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

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