Всё равно медленно. BF527 делает FFT на 512 точках за 11 мкс.

А на какой частоте он у Вас работает? Глянул на страничке - он до 600 MHz. Детальнее не смотрел. Может ещё и плавающий сопроцессор есть.
Тогда там вообще эта ерундистика с целочисленным табличным синусом/косинусом плюс необходимые коррекции и на фиг не нужна ...
Я тут собираюсь заказать STM32F4DISCOVERY, там частота вроде 192 MHz (сорри, если ошибся) + FPU - вот и проверю.

ЗЫ.
Core2Quad (даже простой 2-х ядерный пень) ещё быстрее считает

...рано. Что-то уж очень большие цифры. Тем более, что мы(Вы) используем RealFFT.

По-поводу логарифмирования и корня:
sqrt() - это же число в степени 0.5 - а она легким движением руки переносится в показатель степени основания логарифма или просто выносится за логарифм. Потому никакой целочисленный корень не нужен.

Кстати, это оффтоп, но у меня есть веские основания полагать почему так развита была теория "кепструмов" для распознавания речи в эпоху малопроизводительных ЭВМ без float - а просто легкое целочисленное вычисление - смотрим дальше по тексту.

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


Это не я такой умный, а Pilot с "винграда". У него на форуме я такое нашел. Правда тогда я и не допер этот способ, а потом допер и вышла лабуда. А почему лабуда? А потому, что мы ищем не логарифм от 1 до 32768, а логарифм 0.001 до 0.999, а уже эту сетку домножаем на как по x 32768 так и по y.