Почему моя программа работает медленно, когда зацикливается ровно на 8192 элемента?

Следующие тесты были выполнены с помощью компилятора Visual С++, так как он используется установкой Qt Creator по умолчанию (думаю, без флага оптимизации). При использовании GCC нет большой разницы между мистической версией и моим "оптимизированным" кодом. Таким образом, вывод заключается в том, что оптимизация компилятора лучше заботится о микро оптимизации, чем люди (я наконец). Я оставляю остальную часть своего ответа для справки.

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

pointer + (x + y*width)*(sizeOfOnePixel)

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

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

Оригинальный код пользователя1615209:

8193: 4392 ms
8192: 9570 ms

Мистическая версия:

8193: 2393 ms
8192: 2190 ms

Два прохода с использованием массива 1D: первый проход для горизонтальных сумм, второй для вертикальной суммы и среднего. Двухпроходная адресация с тремя указателями и только приращения:

imgPointer1 = &avg1[0][0];
imgPointer2 = &avg1[0][SIZE];
imgPointer3 = &avg1[0][SIZE+SIZE];

for(i=SIZE;i<totalSize-SIZE;i++){
    resPointer[i]=(*(imgPointer1++)+*(imgPointer2++)+*(imgPointer3++))/9;
}

8193: 938 ms
8192: 974 ms

Два прохода с использованием 1D-массива и адресация следующим образом:

for(i=SIZE;i<totalSize-SIZE;i++){
    resPointer[i]=(hsumPointer[i-SIZE]+hsumPointer[i]+hsumPointer[i+SIZE])/9;
}

8193: 932 ms
8192: 925 ms

Однократное кеширование горизонтальных сумм только на одну строку вперед, поэтому они остаются в кеше:

// Horizontal sums for the first two lines
for(i=1;i<SIZE*2;i++){
    hsumPointer[i]=imgPointer[i-1]+imgPointer[i]+imgPointer[i+1];
}
// Rest of the computation
for(;i<totalSize;i++){
    // Compute horizontal sum for next line
    hsumPointer[i]=imgPointer[i-1]+imgPointer[i]+imgPointer[i+1];
    // Final result
    resPointer[i-SIZE]=(hsumPointer[i-SIZE-SIZE]+hsumPointer[i-SIZE]+hsumPointer[i])/9;
}

8193: 599 ms
8192: 652 ms

Вывод:

• Невозможно использовать несколько указателей и просто увеличить (я думал, что это было бы быстрее)
• Кэширование горизонтальных сумм лучше, чем вычисление их несколько раз.
• Два прохода не три раза быстрее, а два раза.
• Достичь в 3,6 раза быстрее, используя как один проход, так и кеширование промежуточного результата.

Я уверен, что это можно сделать намного лучше.

Примечание Пожалуйста, обратите внимание, что я написал этот ответ для решения общих проблем производительности, а не проблемы с кешем, описанной в "Мистическом отличном ответе". Сначала это был просто псевдокод. Меня попросили сделать тесты в комментариях... Вот полностью обновленная версия с тестами.

Порядок доступа к элементу, который позаботился о нем, по-прежнему остается немного низко висящих фруктов. Накопление может быть выполнено таким образом, что при итерации вправо только 3 новые значения должны быть извлечены из памяти и накоплены. Трюк состоит в том, чтобы знать, как удалить крайний левый столбец; при добавлении нового столбца помните его значение, пока оно не выйдет из окна выборки.

Стоимость до: 9 читать, 9 сложение, 1 деление Стоимость после: 3 чтения, 3 сложения, 1 деление

Подумайте о окне выборки как поле 3x3, где вы будете отслеживать каждый столбец (1x3) отдельно. Накопите новый столбец и оставьте самый старый.

Разделение - это команда с высокой задержкой, поэтому может быть полезно скрыть задержку, но перед тем, как перейти туда, вывод компилятора должен быть проверен, если деление на константу отменено, и если разворачивание цикла (компилятором) уже делает некоторые компенсация задержки.

Но после самой резкой оптимизации правильного использования кеша это действительно незначительные вещи.