Могу.
Есть разные архитектуры ядер процессоров: CISK и RISC. Последняя отличается простотой и ограниченным количеством инструкций, что позволяет этой архитектуре иметь быстрое Арифметико-Логическое Устройство (АЛУ). То есть поднять тактовую частоту ядра разменяв ее на длину кода. Практика показала, что ДЛЯ БОЛЬШИНСТВА ЗАДАЧ так считать быстрее.
Но беда в том, что сигнальные задачи (DSP) к этому большинству не относятся. И для них нужны ускорители.
Есть два вида таких ускорителей: VLIW и SIMD. Первый использует объединение нескольких РАЗНЫХ инструкций в одной, которая выполняется за 1 машинный цикл. То есть цепочка инструкций делается одновременно. Второй использует возможность считать ОДНУ КОРОТКУЮ инструкция С РАЗНЫМИ ОПЕРАНДАМИ. То есть производить матричные вычисления параллельно.
ARM относится к RISC-архитектуре. Основное отличие этой архитектуры в отсутствии инструкций арифметики с непосредственными данными в ОЗУ. Вся арифметика выполняется только в регистрах ядра, которые называются регистрами общего назначения (РОН). И прежде чем считать арифметику эти РОНы нужно загрузить данными из ОЗУ и для этого есть инструкции загрузки. А после вычислений результат из РОНа нужно выгрузить в ОЗУ. И для этого есть инструкции выгрузки. Кроме этого, в ARM-ах матрица шин позволяет одновременно в одном машинном цикле иметь лишь один доступ в ОЗУ для загрузки РОНов.
MAC - это стандартная инструкция DSP набора инструкций, которая реализует основную математику свертки - A=A+X*Y.
Фактически это две инструкции выполняемые за один машинный цикл, что ускоряет (теоретически) свертку в два раза.
Но есть одно "но". Проблема в том, что длина инструкции и схемотехника АЛУ ограничивает возможности адресации и потому MAC в любой архитектуре - это чисто регистровая команда. То есть X и Y это содержимое РОНов, а аккумулятор А - либо отдельный многоразрядный регистр или несколько РОНов соединенных в одно многоразрядное слово.
В ускорителях типа VLIW оные МАС-инструкции объединяют с загрузкой регистров по регистрам-указателям (тоже РОНы) для следующей инструкции и одновременной модификацией указателей для следующей загрузки в следующей инструкции. То есть сама эта длинная инструкция имеет встроенный трехстадийный конвейер. Это позволяет для реализации свертки тупо повторять одну и туже инструкцию N раз. И все. При этом пара данных в РОНы X и Y может быть загружена одновременно, что достигается сегментированием ОЗУ на две части с двумя разными шинами доступа.
в SIMD это делают иначе. Там сначала загружают матрицу исходных данных, а затем в один машинный цикл делают несколько MAC одновременно.
При расчете БПФ такой регулярности нет и приходится дергать промежуточные комплексные (двумерные) данные туда-сюда, выполняя разнотипные MAC. Это лишает возможности SIMD иметь значительный выигрыш, поскольку нет возможности одновременно дергать указатели.

Я написал то, что хотел написать. ДПФ и свертка математически суть есть одно и тоже - сумма произведений.

КРАМ, спасибо за ликбез. Из Вашего текста я смог понять, почему при расчете БПФ не удастся достичь такой же производительности вычислений, как при расчете свертки. Но для меня остался всё равно непонятен вопрос, почему, заменяя в одном и том же коде типы данных с float на short, а получаю в одном случае (свертка) существенный прирост скорости, а в другом (БПФ) ничего не получаю по скорости.

Потому что флоат не используется в МАС-инструкциях. Они целочисленные.