Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
V>>>До какой-то степени можно, конечно.
V>>>Это как минимизация выражений, распространение констант и т.д.
V>>>В общем, всё то, что входит в стадию бета-редукции у современных оптимизирующих компиляторов, с учётом предметной области вычислений.
S>>Если мы уже перешли к линейным фильтрам, то они компонуемы просто по определению. Любая комбинация линейных фильтров является линейным фильтром.
V>Это в теории непрерывных вычислений.
V>А как на практике сложить дискретные (цифровые) рекурсивный и нерекурсивный фильтры в один? ))
V>(линия задержки — это тоже нерекурсивный фильтр с коэфициентами 0, 0, ..., 1)
V>У них принципиально разный отклик, не выражаемый в общем случае один из другого (при разумной длине нерекурсивного фильтра).
V>Но так-то ты говоришь верно, просто у тебя недостаточно информации.
V>Например, такой, что рекурсивные фильтры высоких порядков часто реализуют как каскадное или параллельное подключение фильтров 2-го порядка, зависит от расположения полюсов по квандранту.
V>Это предпочтительней, чем прямая реализация единого многополюсного фильтра, т.к. чем выше порядок фильтра, тем меньше его устойчивость — цифровые рекурсивные фильтры высоких порядков склонны к возбуждению из-за погрешностей округления при вычислении, т.е. это надо относительно широкое представление вещественного числа брать, которое на сегодня зачастую исключительно эмулируемое в софте.
V>В общем, основная идея в том, что можно найти минимальное представление линейной такой комбинированной системы, т.е. свести к минимальному кол-ву линий задержек (нерекурсивные фильтры самые дорогие) из исходного их кол-ва и произвольных связей.
V>Над каждой линией задержки будет более одной обратной связи с разной "дистанцией", в т.ч. с небольшой, достаточной для рекурсивных фильтров, для параллельной и последовательной их реализаций.
V>Не понял возражения.
V>Для линейной интерполяции по таблице у нас есть прямая и точка на этой прямой.
V>Индекс значений i (a[i], b[i]) — целая часть значения (после масштабирования на размер таблицы), x — дробная часть.
V>Это классический вариант табличной линейной интерполяции.
V>Или ты имел ввиду "сырой" вариант табличной апроксимации, когда таблица будет содержать в ячейках таблицы непосредственные значения выходной ф-ии вместо коэф. {a,b}? Тогда искомую прямую придётся строить каждый раз заново по двум точкам {a[i], a[i+1]}: a[i]*(1-x)+a[i+1]*x, где i — опять целая часть, x — дробная.
V>По "сырому" методу операций больше на одно умножение и три сложения.
А, то есть предлагается сделать
VBROADCASTSS ymm1, $tableLength
VMULPS ymm2, ymm1, [$data+i]
VCVTPS2DQ ymm3, ymm2
VSUBPS ymm4, ymm2, ymm3
а потом два gather по индексам из ymm3 в ymm5 и ymm6, c последующим
VFMADD132PS ymm4, ymm5, ymm6
? Ну... можно попробовать, хотя я пока не понимаю, как работают gather-инструкции, и нет ли там промежуточного сохранения индексов в память, что убьёт всю идею.
V>А в чем там "математичность"?
В том, что пытались сделать SIMD-версию функции возведения в степень. Пришли к выводу, что интерполяция полиномом эффективнее.
V>А меня, как программиста-профика, интересуют вещи куда как более скучные, см. выделенное:
V>V>/* index = EXP2_TABLE_OFFSET + (int)(fpart * EXP2_TABLE_SCALE) */
V>
V>- никакой интерполяции не происходит, даже линейной, именно поэтому по ссылке баловство.
V>Кто-то дорвался "немного попрограммировать".
Ну, как смогли — так и сделали. Можно попробовать улучшить.
V>На HD Audio идёт туда-обратно обычно int32.
V>AC'97 в живых, наверно, уже и не осталось.
Ну, ок, 32 так 32. Всё равно мне пока непонятно, как эффективно делать табличные интерполяции с таким сигналом. С честным int16 мы могли бы просто строить полную таблицу безо всяких умножений и сложений — просто 128 килобайт lookup, описывающий любую потребную нам функцию без потери точности. А с флоатом мы сможем работать только в предположении, что он нормализован в каком-то узком диапазоне. Иначе у нас таблица окажется очень "неравномерной".
V>Сейчас стандарт float32 потихоньку пролазит в железо, например, в USB-аудио-девайсы.
V>Фишка в том, что АЦП/ЦАП на 32 честных бита задешево — давно реальность, и даже начинают превышать 32 бита в проф.аппаратуре (значит, в обозримом будущем доедет и до ширпотреба).
Фишка в том, что непонятно, откуда брать источник с таким соотношением сигнал/шум. Сколько бит из этих 32 — мусор?
V>Нулевой:
V>V>.L5:
V> vmovdqu ymm1, YMMWORD PTR [rsi+rax]
V> vpaddb ymm0, ymm1, YMMWORD PTR [rdx+rax]
V> vmovdqu YMMWORD PTR [rcx+rax], ymm0
V> add rax, 32
V> cmp rax, r8
V> jne .L5
V>
Точнее, единичный.
S>>Покажите мне код, который разворачивается в SIMD с фактором хотя бы в 16, не говоря уже о 128.
V>Давай ты мне просто поверишь на слово или забьёшься на спор, оформив чётко своё возражение?
Ну ок, поверю. Смысла спорить нет — я всё равно даже пробовать не буду разворачивать SIMD 128 раз.
V>Чтобы обеспечить кач-во.
Качество чего?
S>>Выражение 0.2*x[-3.5]+0.1*x[-4.3] сводится к 0.1*x[-3]+0.17*x[-4]+0.03*x[-5], и у нас опять всё целое.
V>Навряд ли сводится именно таким образом.
По твоей же формуле сводится именно таким.
S>>Если нас интересует период эха, то как бы 44кГц уже дают точность в 22.6 микросекунд — вряд ли слушатель заметит, что эхо приходит не ровно через 2.5 секунды, а через 2.500023.
V>Это если эхо статичное.
А если нет, то что?
