целочисленное БПФ в формате 1.15

Дмитрий К
Сообщения: 29
Зарегистрирован: 02 мар 2011, 09:48

Re: целочисленное БПФ в формате 1.15

Сообщение Дмитрий К »

кстати о производительности:

Как видно по дизасемблеру, умножение двух long(32 бита) занимает 4 такта.
Кроме того есть инструкиця множения с накоплением, которая позволяет за один такт перемножить два операнда и прибавить к некоему третьему.
У меня ядро ARM9E. Так вот в книге посвящённой ARM (ARM Development guide) есть отдельная глава по DSP, где говорится о том что процессоры с этими ядрами применяются в устройствах считывания CD и пр., где математика обсчитывается.
На рисунке видно умноженеи long. А так я ещё и с float баловался))
Вложения
Multiplication.JPG
Multiplication.JPG (111.22 КБ) 5278 просмотров

Аватара пользователя
Бахурин Сергей
Администратор
Сообщения: 1114
Зарегистрирован: 05 окт 2010, 19:55
Контактная информация:

Re: целочисленное БПФ в формате 1.15

Сообщение Бахурин Сергей »

Правильно ли я понял из прикрепленного скрина, что умножение двух целых типа long занимает 4 такта, а умножение двух float 6 тактов?

Дмитрий К
Сообщения: 29
Зарегистрирован: 02 мар 2011, 09:48

Re: целочисленное БПФ в формате 1.15

Сообщение Дмитрий К »

Нет. На рисунке видно, что при умножении двух float компилятор вызывает интринсик __aeabi_fmul.

Подозреваю, что она разворачивается в целую серию операций (пока не нашёл как она интерпретируется).

Ivan Karamazov
Сообщения: 89
Зарегистрирован: 28 окт 2010, 22:31
Откуда: Москва

Re: целочисленное БПФ в формате 1.15

Сообщение Ivan Karamazov »

Как видно по дизасемблеру, умножение двух long(32 бита) занимает 4 такта.
Кроме того есть инструкиця множения с накоплением, которая позволяет за один такт перемножить два операнда и прибавить к некоему третьему.
М.б. в Вашем ARM'е умножение и занимает один такт (надо уточнить).
На самом деле это не слишком принципиально.
Очевидно, что если никто не заставит (в самый неподходящий момент) CPU "немножко подождать", то все он перемолотит. А вот если ему надо будет постоянно-время-от-времени приостанавливаться -- никто не знает. Кстати, обратите внимание на конфигурацию системы с SRAM из дата-шита. Если бы все было так просто, она не была бы актуальной.
Так вот в книге посвящённой ARM (ARM Development guide) есть отдельная глава по DSP, где говорится о том что процессоры с этими ядрами применяются в устройствах считывания CD и пр., где математика обсчитывается.
(1) в CD обсчитвается специфическая математика -- 2 следящих системы + Рид-Соломон+линейный код. И не факт, что этим эанимается отдельно взятый АРМ без специфической обвязки. А даже если и так -- это отнюдь не Фурье. У меня вот тоже АРМ есть в плеере, только называется он TMS320DM64xx (ARM9-200+DSP-ядро от TI, см., если интересно). Т.е. сам ARM занимается только чтением/записью, менюшками на экране, кнопками, USB и распознаванием форматов, а все кодеки живут в DSP-ядре.
(2) Ежели у Вас все под пальцами -- поробуйте изобразить чтение в реальном времени 16-битных чисел, фильтрацию + модель того, что должно стоять на выходе Фурье. Загрузите по максимому всю потребную переферию. И конечно, заложите механизм обнаружения потерь, т.е. факта пропуска отсчетов. Все, естественно, в той программной среде (if any), которая предполагается к использованию. Далее, навесте на все это программную болванку, слегка грузящую проц, например, разумно-периодическим сканированием памяти в объеме, потребном для фурье * 2. Пока это не заработает без пропуска отсчетов хотя бы с 2-кратным запасом по частоте дискретизации, дальше двигаться нет смысла. Когда получится -- дай Бог! -- дальше -- очень может быть, что Вам и программной точки поддержки компилятора хватит; а может быть, придется самым подробным образом изучать DSP-расширения (с реализацией на ASM) -- все эти тонкости реализации -- приятные хлопоты, после того, как динамика работы платформы сформирована. А код ARM'а компилируется классно, о да -- если убрать из примера 'volatile' -- он будет еще раза в 2 красивше.
(3) Вырожденные экспирименты с коротким кодом, "работающим сам на себя" ограниченно полезны, но дать представление о реальной производительности системы они не могут, на мой взгляд. Т.е. могут, но только в смысле верхней оценки.
Если ваши решения вам нравятся -- это хорошие решения. И наоборот.

Ivan Karamazov
Сообщения: 89
Зарегистрирован: 28 окт 2010, 22:31
Откуда: Москва

Re: целочисленное БПФ в формате 1.15

Сообщение Ivan Karamazov »

Кстати, коль скоро Вы решили посмотреть, как и что компилируется, рекомендую посмотреть такие конструкции:

Код: Выделить всё

// скалярные типы
typedef int SINT32;            // 32 бита со знаком
typedef long long SINT64;   // 64 бита со знаком 
// (long long м.б. надо заменить -- зависит от компилятора)!!

// 63-сумма произведений операндов - V1
SINT64 ex1(SINT32 a, SINT32 b, SINT32 c, SINT32 d)
{
  SINT64 temp = ((SINT64)a) * b;  // д.б. одна команда SMULL, и никаких вызовов
  temp += ((SINT64)c) * d;            // д.б. одна команда SMLAL
// допустимы также пересылки по вкусу, но никаких вызовов ф-й поддержки языка
  return temp;
}

// 63-сумма произведений операндов - V2
SINT64 ex2(SINT32 a, SINT32 b, SINT32 c, SINT32 d)
{
  return ((SINT64)a) * b + ((SINT64)c) * d;
// должно быть не хуже версии 1.
}
Т.е. MS VC для x86 и ARM V4i+ здесь работает правильно (правда, без SMLAL -- только SMULL + сложение с переносом), перемножая одной командой 32-битные операнды и получая 63-битный результат. На ARM есть дополнительный шанс использовать "умножить и сложить", но, вообще-то все это хак, который может пройти, а может и нет. (Компилироваться надо бы с оптимизацией.) Но хак очень соблазнимельный с точки зрения оптимизации вычислений, не прибегая к ассемблеру.
И, кстати, такты и команды -- вещи, вообще говоря, разные. Для ARM 7 среднее соотношение тактов к командам составляло 1.7 на типовом коде; для ARM9e -- не говорят толком ничего, требуя регистрации за полный PDF.
Если ваши решения вам нравятся -- это хорошие решения. И наоборот.

Ответить