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

V>Стек аудио-эффектов для гитары, например.
А нельзя композицию эффектов свести к композитному эффекту?

V>Т.е., даже если импульсная характеристика порождена не аналоговым процессом, а цифровым, то делается это примерно так:
V>- на некоей модели, оперирующей большой точностью, моделируется некая обработка сигнала;
V>- с этой модели снимается итоговая импульсная характеристика;
V>- в реалтайме затем происходит свёртка входного сигнала с импульсной характеристикой.
Хм. Это должно работать только с линейными фильтрами.
V>Суть в том, что "точная модель" оперирует большой разрядностью и кратной передискетизацией унутре, поэтому эта модель не работает в реалтайм, она используется один раз при вычислении IR.
Как-то это сложно. Непонятно, зачем вообще вся эта суперпередискретизация, если мы всё равно пропускаем через эту модель единичный сигнал, а на выход записываем коэффициенты в "финальной" дискретизации и разрядности.
V>Нелинейщина обычно проще. Это разного рода пороговые ф-ии, типа sqrt, log и т.д. и они часто реализованы через табличную аппроксимацию, т.е. практически бесплатны.
Ну, по сравнению с арифметикой даже они гораздо дороже. Как сделать табличную аппроксимацию в SIMD?

V>Компилятор Intel С++ разворачивает циклы именно при работе с SIMD в N=16, 32, ..., 128 раз.
В примерах, которые видел я, развёртки SIMD циклов от ICC ~ 2, от GCC — ~4. И это при простейшем коде цикла, где вроде бы и нагрузки на CPU на итерацию мало, и до пределов кэша коду ещё далеко.
V>Кеш данных 1-го уровня имеет в точности быстродействие файла регистров (и там и там косвенная адресация из-за ассоциативности, для кеша данных — с данными, для файла регистров — из-за переименований регистров, где внутренний файл регистров в несколько раз больше "публичного" его отображения).
Ну... хз. Всё равно юнитов исполнительных в одном ядре не очень много; даже если я разверну цикл 128 раз, никто мне не будет 128 пар сложений одновременно выполнять.

V>Другое дело, что там много инфы и она достаточно "муторная". ))
Ну вот в том-то и дело. Формально вроде бы интел и переходы предсказывает, и инструкции перемещает, а на практике — всё равно разница есть.
Вот то же предсказание переходов: по идее, проверка выхода за диапазон вообще не должна влиять на массивах размером в 33мегапиксела. Там же ровно всегда один и тот же бранч выбирается.
Ан нет — жрёт до 25% времени в скалярном варианте фильтра C4.
Вот и перемешивание инструкций — есть подозрение, что даже формальная независимость по данным не обеспечит идеальный тайминг; а ICC как раз их располагает с учётом знания устройства конвеера.
Впрочем, мне всё равно до этого далеко. Мой оптимизатор даже эвристическим назвать нельзя — он тупой табличный. В то время, как взрослые пацаны работают как минимум со стоимостями, т.е. рассматривают для любой комбинации операций разные варианты её кодирования в бинарь, и выбирают наиболее дешёвый.
Способность ещё и анализировать инструкции с точки зрения возможности наложения друг на друга — вообще космос по сравнению с тем, что уже сделано в linq2d.

V>Но для второго канала для рекурсивного фильтра надо подгрузить уже другие минус N отсчётов.
Почему другие-то? На выходе-то оба канала точно так же идут в памяти вместе: LRLRLRLRLR.

V>Соотв, кол-во отсчётов IR зависит от отношения частоты дискретизации / частоты фильтра и от заданной точности.
V>В реальности это от нескольких десятков отсчётов, до нескольких тысяч, чаще всего в пределах нескольких сотен для низких порядков фильтра (до ~8 порядков).
V>Для ревербераторов+эха длина IR может составлять секунды, умножай на частоту дискретизации.
Омг. То есть мы говорим о ~10^6 отсчётов. Да, тут есть шанс вылететь за кэш.
С другой стороны, тут никакой мотивации для linq нету. Все фильтры устроены одинаково — тупо свёртка IR с входом и выходом. Один раз пишем оптимальную функцию; можно её специализировать для пяти-шести вариантов аппаратуры — и вперёд, на танки.

V>Исходники есть, можно подключить гитару и играть. ))
V>Могу переслать куда-нить.
Пересылай. Хотя я скорее гитару подключу к готовой железке
V>Можно.
V>Вернее, нужно, чтобы стимулировать желание экспериментировать задёшево. ))
Пока непонятно. То есть понятно, что можно давать, скажем, описывать частотный фильтр его графиком, а потом конвертировать это в IR при помощи Фурье. (Я такие штуки видел ещё в 1980х, вряд ли кого чем-то тут можно удивить).
И вообще, если мы всё сводим к IR, то любой фильтр — это просто набор чиселок. Ну, или функция от N аргументов, которая порождает этот набор чиселок.
Что тут можно придумать, кроме того, что уже сто лет как придумано?

V>ОК, это была инфа — эксперименты/рассчёты ИИ делают сегодня в основном на Питоне.
V>Т.е., в реальных железках работают уже плюсы с вычисленными на Питоне коэф. сетки.
Ну, для ML уже есть кому экспериментировать. https://devblogs.microsoft.com/dotnet/using-net-hardware-intrinsics-api-to-accelerate-machine-learning-scenarios/