Здравствуйте, Sinclair, Вы писали:

V>>Если промежуточные результаты в регистрах сохранить не получится (а в моих экспериментах не получится с запасом раз так в 50-100), то трафик с памятью будет в любом случае.
S>Интересно посмотреть на формулы, в которых это так устроено. Откуда берутся промежуточные результаты размером в 100 регистр файлов?

Стек аудио-эффектов для гитары, например.


V>>Причём, самая мощная из разновидностей, бо способна на произвольные фазовые задержки, т.е. позволяет даже описывать реверберацию и эхо.
S>Хм, реверберация — она же только с рекурсивным фильтром.

Рекурсивная при эмуляции в цифре аналоговых процессов.
Но "родной" цифровой способ (т.е. позволяющий получить наибольшую точность) — через свёртку:
https://en.wikipedia.org/wiki/Convolution_reverb

Т.е., даже если импульсная характеристика порождена не аналоговым процессом, а цифровым, то делается это примерно так:
— на некоей модели, оперирующей большой точностью, моделируется некая обработка сигнала;
— с этой модели снимается итоговая импульсная характеристика;
— в реалтайме затем происходит свёртка входного сигнала с импульсной характеристикой.

Суть в том, что "точная модель" оперирует большой разрядностью и кратной передискетизацией унутре, поэтому эта модель не работает в реалтайм, она используется один раз при вычислении IR.


S>Я так понимаю, что под "самой мощной" имеется в виду "среди линейных фильтров", так? С нелинейщиной всё может быть гораздо кучерявее.

Нелинейщина обычно проще. Это разного рода пороговые ф-ии, типа sqrt, log и т.д. и они часто реализованы через табличную аппроксимацию, т.е. практически бесплатны.


V>>MemoryMarshal.CreateReadOnlySpan<T>(..) и зеркальный ему MemoryMarshal.AsRef<T>(..) — оба имеют нулевую стоимость в рантайм, это просто unsafe-реинтерпретация памяти.
S>Ну, так-то пофиг, но работать с этим неудобно. Это ж надо весь этот код по приведению Сolor* к Vector256<Color> порождать в MSIL.

Ты спросил "как" — я показал направление.


V>>При слишком большом N разворачивания цикла получается многократное N-дублирование тела цикла.
V>>И чем больше в бинаре подобного кода, тем быстрее охлаждается кеш.
V>>Всегда есть некий оптимум этого N.
S>А зачем слишком большой? При работе с SIMD больше чем 2-4 раза разворачивать и не приходится.

Компилятор Intel С++ разворачивает циклы именно при работе с SIMD в N=16, 32, ..., 128 раз.


S>Там всё равно всё быстро упирается в быстродействие памяти.

Кеш данных 1-го уровня имеет в точности быстродействие файла регистров (и там и там косвенная адресация из-за ассоциативности, для кеша данных — с данными, для файла регистров — из-за переименований регистров, где внутренний файл регистров в несколько раз больше "публичного" его отображения).


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

Ес-но, я лишь возражал, что для этого применялись недоступные простым смертным знания.
Мне попадались в разные времена док-ты от Intel по способам увеличения эффективности исполняемого на их процах кода.
Другое дело, что там много инфы и она достаточно "муторная". ))


V>>"Я в курсе" не согласуется с написанным тобой выше:
V>>

V>>>>Формулы одинаковые для каждого канала, просто в памяти эффективней расположить подряд данные от одного канала, а не "смесь" их.
S>>>По-прежнему не вижу обоснования этой эффективности.
S>>>Например, если мне нужно умножить оба канала на 0.74, то я просто

S>Вполне согласуется. Если формула одинаковая, то она будет записываться в виде SIMD хоть для отдельных каналов, хоть для пары каналов через один.

Но для второго канала для рекурсивного фильтра надо подгрузить уже другие минус N отсчётов.


S>Та же свёртка просто будет не с вектором (a0, a1, a2, a3), а c вектором (a0, a0, a1, a1).
S>Кстати, каков типичный размер IR для практических фильтров?

В теории IR бесконечен, на практике берут некую заданную точность.
https://studfile.net/preview/5830088/page:5/

Соотв, кол-во отсчётов IR зависит от отношения частоты дискретизации / частоты фильтра и от заданной точности.
В реальности это от нескольких десятков отсчётов, до нескольких тысяч, чаще всего в пределах нескольких сотен для низких порядков фильтра (до ~8 порядков).

Для ревербераторов+эха длина IR может составлять секунды, умножай на частоту дискретизации.

Для IR микрофонно-аккустических систем (т.н. кабинеты) — десятые доли секунд.


V>>Например, подобного рода баловство:
V>>http://files.rsdn.org/21096/MusicFX.png
S>Ну, так это ж картинка. Надо смотреть внутрь — как там эти фильтры представлены.

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


S>И можно ли представить их лучше/удобнее, чем они уже представлены.

Можно.
Вернее, нужно, чтобы стимулировать желание экспериментировать задёшево. ))


V>>Если ты вплотную к плюсам подобрался, то представления о том, как должны выглядеть современные эксперименты, скажем, в области ИИ, могут малость поменяться. ))
S>Мои представления изменить нетрудно — я об этом знаю примерно ноль.

ОК, это была инфа — эксперименты/рассчёты ИИ делают сегодня в основном на Питоне.
Т.е., в реальных железках работают уже плюсы с вычисленными на Питоне коэф. сетки.