Попытка оптимизации

Есть программа, где в цикле производиться много вычислений. одно из них это циклический сдвиг (то есть с переносом бит).
Делаю это я в три шага:
Решил я немного оптимизировать данную операцию - создал массив с предварительно подсчитанными значениями и... ничего не изменилось. Быстрее не стало
в чем дело?

0

Сообщение от Alex1126 в чем дело?

Сильно глубокий цикл?
Посмотри код на асме. И уверен, что именно это место сильно тормозило?

0

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

0

Сообщение от Alex1126 в чем дело?

Чтение данных - дело долгое (по сравнению с примитивной "арифметикой").
Также, м.б., массив arr_shift[] слишком большой (если переменная b принимает значения из достаточно широкого интервала) и, поэтому, целиком не влезает в самый быстрый L1-кэш данных (а каждый следующий уровень кэша - это более долгий доступ).

Ну и компилятор какой используется? Родной ембракоделовский - или шланг (clang)?
Если шланг - то, возможно, компилятор векторизовал вычисления. Т.е. несколько соседних элементов обсчитываются одной векторной командой процессора. Число итераций цикла при этом сокращается в несколько раз (во столько, сколько значений обрабатываемого типа данных влезает в векторный регистр).
А вот обращения к памяти по индексу - не векторизуются, т.е. будут выполняться скалярными командами.

0

Сообщение от Alex1126 Есть программа, где в цикле производиться много вычислений.

покаж кот.

0

Сообщение от VTsaregorodtsev Чтение данных - дело долгое (по сравнению с примитивной "арифметикой").

Я думал об этом. Типа массив объявляется в стеке, для получения элемента массива сначала вычисляется адрес начала стека, потом берется смещение в стеке элемента. Вы про это? Объявлял массив глобально - так же ничего не вышло.

Сообщение от VTsaregorodtsev Также, м.б., массив arr_shift[] слишком большой

uint8_t, 256 элементов

Сообщение от VTsaregorodtsev Ну и компилятор какой используется?

родной


Ну я правильно понимаю, что выигрыш должен быть?

0

Сообщение от Alex1126 Вы про это?

нет. Я про то, что процессорная команда чтения данных сама по себе выполняется за бОльшее число тактов процессора, чем команды сдвигов/OR.

Сообщение от Alex1126 Ну я правильно понимаю, что выигрыш должен быть?

Я код целиком не видел. Поэтому ХЗ.

0

Alex1126, как проводились измерения скорости работы?

И была ли включена оптимизация при этом ?

0