Сообщение Re[19]: Производительность .Net на вычислительных задачах от 03.11.2020 14:50
Изменено 04.11.2020 11:36 vdimas
Re[19]: Производительность .Net на вычислительных задачах
Здравствуйте, Sinclair, Вы писали:
V>>До какой-то степени можно, конечно.
V>>Это как минимизация выражений, распространение констант и т.д.
V>>В общем, всё то, что входит в стадию бета-редукции у современных оптимизирующих компиляторов, с учётом предметной области вычислений.
S>Если мы уже перешли к линейным фильтрам, то они компонуемы просто по определению. Любая комбинация линейных фильтров является линейным фильтром.
Это в теории непрерывных вычислений.
А как на практике сложить дискретные (цифровые) рекурсивный и нерекурсивный фильтры в один? ))
(линия задержки — это тоже нерекурсивный фильтр с коэфициентами 0, 0, ..., 1)
У них принципиально разный отклик, не выражаемый в общем случае один из другого (при разумной длине нерекурсивного фильтра).
Но так-то ты говоришь верно, просто у тебя недостаточно информации.
Например, такой, что рекурсивные фильтры высоких порядков часто реализуют как каскадное или параллельное подключение фильтров 2-го порядка, зависит от расположения полюсов по квандранту.
Это предпочтительней, чем прямая реализация единого многополюсного фильтра, т.к. чем выше порядок фильтра, тем меньше его устойчивость — цифровые рекурсивные фильтры высоких порядков склонны к возбуждению из-за погрешностей округления при вычислении, т.е. это надо относительно широкое представление вещественного числа брать, которое на сегодня зачастую исключительно эмулируемое в софте.
В общем, основная идея в том, что можно найти минимальное представление линейной такой комбинированной системы, т.е. свести к минимальному кол-ву линий задержек (нерекурсивные фильтры самые дорогие) из исходного их кол-ва и произвольных связей.
Над каждой линией задержки будет более одной обратной связи с разной "дистанцией", в т.ч. с небольшой, достаточной для рекурсивных фильтров, для параллельной и последовательной их реализаций.
S>>>Ну, по сравнению с арифметикой даже они гораздо дороже. Как сделать табличную аппроксимацию в SIMD?
V>>Через a*x+b
S>Не-не-не-не-не, Дэвид Блейн. ax+b — это линейное преобразование. Таблица — это когда у меня значения выхода произвольные.
Не понял возражения.
Для линейной интерполяции по таблице у нас есть прямая и точка на этой прямой.
Индекс значений i (a[i], b[i]) — целая часть значения (после масштабирования на размер таблицы), x — дробная часть.
Это классический вариант табличной линейной интерполяции.
Или ты имел ввиду "сырой" вариант табличной апроксимации, когда таблица будет содержать в ячейках таблицы непосредственные значения выходной ф-ии вместо коэф. {a,b}? Тогда искомую прямую придётся строить каждый раз заново по двум точкам {a[i], a[i+1]}: a[i]*(1-x)+a[i+1]*x, где i — опять целая часть, x — дробная.
По "сырому" методу операций больше на одно умножение и три сложения.
S>То есть я беру, скажем, логарифм по некоторому основанию от x, и рассчитываю его для всех 65536 возможных значений x, складывая в таблицу.
S>А потом вычисляю logtable[x] для каждого x.
S>Вот как развлекались любители математики 12 лет тому: http://jrfonseca.blogspot.com/2008/09/fast-sse2-pow-tables-or-polynomials.html
А в чем там "математичность"?
Что использовали формулу суммы степеней exp(a+b)=exp(a)*exp(b)?
На олимпиадах для 7-8-х классов подобные задачи дают.
А меня, как программиста-профика, интересуют вещи куда как более скучные, см. выделенное:
— никакой интерполяции не происходит, даже линейной, именно поэтому по ссылке баловство.
Кто-то дорвался "немного попрограммировать".
S>То есть работать с 16-битным звуком напрямую через них не выйдет.
На HD Audio идёт туда-обратно обычно int32.
AC'97 в живых, наверно, уже и не осталось.
Но стандарты цифрового софта давно сошлись на потоке IO float32.
Как остроумно объяснил один аудиофил другому:
Сейчас стандарт float32 потихоньку пролазит в железо, например, в USB-аудио-девайсы.
Фишка в том, что АЦП/ЦАП на 32 честных бита задешево — давно реальность, и даже начинают превышать 32 бита в проф.аппаратуре (значит, в обозримом будущем доедет и до ширпотреба).
И не потому что нужна такая точность, а потому что из-за динамического диапазона.
Например, для тихого сигнала при разрядности 16 бит реальная разрядность была пару бит всего, а то и 1.
Вот и получается, что для настраиваемого динамического диапазона 24 бита за глаза хватает, а для ненастраиваемого и 32 бита так себе.
V>>В 2 раза развёртки циклов я не видел ни разу в ассемблерном виде в релизе.
V>>От 16 до 128 с шагом в степень двойки видел.
S>А чего далеко ходить? Вот, берём простейший код поэлементного сложения массивов. Максимально дружественный к векторизации.
S>Гляньте — какой имеем loop unroll factor: https://godbolt.org/z/919Mf9 ?
Нулевой:
S>Покажите мне код, который разворачивается в SIMD с фактором хотя бы в 16, не говоря уже о 128.
Давай ты мне просто поверишь на слово или забьёшься на спор, оформив чётко своё возражение?
S>А зачем нам нецелые смещения?
Чтобы обеспечить кач-во.
S>Выражение 0.2*x[-3.5]+0.1*x[-4.3] сводится к 0.1*x[-3]+0.17*x[-4]+0.03*x[-5], и у нас опять всё целое.
Навряд ли сводится именно таким образом.
Если по 3-м точкам, то искомая точка будет на параболле.
S>Если нас интересует период эха, то как бы 44кГц уже дают точность в 22.6 микросекунд — вряд ли слушатель заметит, что эхо приходит не ровно через 2.5 секунды, а через 2.500023.
Это если эхо статичное.
V>>До какой-то степени можно, конечно.
V>>Это как минимизация выражений, распространение констант и т.д.
V>>В общем, всё то, что входит в стадию бета-редукции у современных оптимизирующих компиляторов, с учётом предметной области вычислений.
S>Если мы уже перешли к линейным фильтрам, то они компонуемы просто по определению. Любая комбинация линейных фильтров является линейным фильтром.
Это в теории непрерывных вычислений.
А как на практике сложить дискретные (цифровые) рекурсивный и нерекурсивный фильтры в один? ))
(линия задержки — это тоже нерекурсивный фильтр с коэфициентами 0, 0, ..., 1)
У них принципиально разный отклик, не выражаемый в общем случае один из другого (при разумной длине нерекурсивного фильтра).
Но так-то ты говоришь верно, просто у тебя недостаточно информации.
Например, такой, что рекурсивные фильтры высоких порядков часто реализуют как каскадное или параллельное подключение фильтров 2-го порядка, зависит от расположения полюсов по квандранту.
Это предпочтительней, чем прямая реализация единого многополюсного фильтра, т.к. чем выше порядок фильтра, тем меньше его устойчивость — цифровые рекурсивные фильтры высоких порядков склонны к возбуждению из-за погрешностей округления при вычислении, т.е. это надо относительно широкое представление вещественного числа брать, которое на сегодня зачастую исключительно эмулируемое в софте.
В общем, основная идея в том, что можно найти минимальное представление линейной такой комбинированной системы, т.е. свести к минимальному кол-ву линий задержек (нерекурсивные фильтры самые дорогие) из исходного их кол-ва и произвольных связей.
Над каждой линией задержки будет более одной обратной связи с разной "дистанцией", в т.ч. с небольшой, достаточной для рекурсивных фильтров, для параллельной и последовательной их реализаций.
S>>>Ну, по сравнению с арифметикой даже они гораздо дороже. Как сделать табличную аппроксимацию в SIMD?
V>>Через a*x+b
S>Не-не-не-не-не, Дэвид Блейн. ax+b — это линейное преобразование. Таблица — это когда у меня значения выхода произвольные.
Не понял возражения.
Для линейной интерполяции по таблице у нас есть прямая и точка на этой прямой.
Индекс значений i (a[i], b[i]) — целая часть значения (после масштабирования на размер таблицы), x — дробная часть.
Это классический вариант табличной линейной интерполяции.
Или ты имел ввиду "сырой" вариант табличной апроксимации, когда таблица будет содержать в ячейках таблицы непосредственные значения выходной ф-ии вместо коэф. {a,b}? Тогда искомую прямую придётся строить каждый раз заново по двум точкам {a[i], a[i+1]}: a[i]*(1-x)+a[i+1]*x, где i — опять целая часть, x — дробная.
По "сырому" методу операций больше на одно умножение и три сложения.
S>То есть я беру, скажем, логарифм по некоторому основанию от x, и рассчитываю его для всех 65536 возможных значений x, складывая в таблицу.
S>А потом вычисляю logtable[x] для каждого x.
S>Вот как развлекались любители математики 12 лет тому: http://jrfonseca.blogspot.com/2008/09/fast-sse2-pow-tables-or-polynomials.html
А в чем там "математичность"?
Что использовали формулу суммы степеней exp(a+b)=exp(a)*exp(b)?
На олимпиадах для 7-8-х классов подобные задачи дают.
А меня, как программиста-профика, интересуют вещи куда как более скучные, см. выделенное:
/* index = EXP2_TABLE_OFFSET + (int)(fpart * EXP2_TABLE_SCALE) */— никакой интерполяции не происходит, даже линейной, именно поэтому по ссылке баловство.
Кто-то дорвался "немного попрограммировать".
S>То есть работать с 16-битным звуком напрямую через них не выйдет.
На HD Audio идёт туда-обратно обычно int32.
AC'97 в живых, наверно, уже и не осталось.
Но стандарты цифрового софта давно сошлись на потоке IO float32.
Как остроумно объяснил один аудиофил другому:
))32 bit floating is a 24 bit recording with 8 extra bits for volume.
Сейчас стандарт float32 потихоньку пролазит в железо, например, в USB-аудио-девайсы.
Фишка в том, что АЦП/ЦАП на 32 честных бита задешево — давно реальность, и даже начинают превышать 32 бита в проф.аппаратуре (значит, в обозримом будущем доедет и до ширпотреба).
И не потому что нужна такая точность, а потому что из-за динамического диапазона.
Например, для тихого сигнала при разрядности 16 бит реальная разрядность была пару бит всего, а то и 1.
Вот и получается, что для настраиваемого динамического диапазона 24 бита за глаза хватает, а для ненастраиваемого и 32 бита так себе.
V>>В 2 раза развёртки циклов я не видел ни разу в ассемблерном виде в релизе.
V>>От 16 до 128 с шагом в степень двойки видел.
S>А чего далеко ходить? Вот, берём простейший код поэлементного сложения массивов. Максимально дружественный к векторизации.
S>Гляньте — какой имеем loop unroll factor: https://godbolt.org/z/919Mf9 ?
Нулевой:
.L5:
vmovdqu ymm1, YMMWORD PTR [rsi+rax]
vpaddb ymm0, ymm1, YMMWORD PTR [rdx+rax]
vmovdqu YMMWORD PTR [rcx+rax], ymm0
add rax, 32
cmp rax, r8
jne .L5S>Покажите мне код, который разворачивается в SIMD с фактором хотя бы в 16, не говоря уже о 128.
Давай ты мне просто поверишь на слово или забьёшься на спор, оформив чётко своё возражение?
S>А зачем нам нецелые смещения?
Чтобы обеспечить кач-во.
S>Выражение 0.2*x[-3.5]+0.1*x[-4.3] сводится к 0.1*x[-3]+0.17*x[-4]+0.03*x[-5], и у нас опять всё целое.
Навряд ли сводится именно таким образом.
Если по 3-м точкам, то искомая точка будет на параболле.
S>Если нас интересует период эха, то как бы 44кГц уже дают точность в 22.6 микросекунд — вряд ли слушатель заметит, что эхо приходит не ровно через 2.5 секунды, а через 2.500023.
Это если эхо статичное.
Re[19]: Производительность .Net на вычислительных задачах
Здравствуйте, Sinclair, Вы писали:
V>>До какой-то степени можно, конечно.
V>>Это как минимизация выражений, распространение констант и т.д.
V>>В общем, всё то, что входит в стадию бета-редукции у современных оптимизирующих компиляторов, с учётом предметной области вычислений.
S>Если мы уже перешли к линейным фильтрам, то они компонуемы просто по определению. Любая комбинация линейных фильтров является линейным фильтром.
Это в теории непрерывных вычислений.
А как на практике сложить дискретные (цифровые) рекурсивный и нерекурсивный фильтры в один? ))
(линия задержки — это тоже нерекурсивный фильтр с коэфициентами 0, 0, ..., 1)
У них принципиально разный отклик, не выражаемый в общем случае один из другого (при разумной длине нерекурсивного фильтра).
Но так-то ты говоришь верно, просто у тебя недостаточно информации.
Например, такой, что рекурсивные фильтры высоких порядков часто реализуют как каскадное или параллельное подключение фильтров 2-го порядка, зависит от расположения полюсов по квандрантам.
Это предпочтительней, чем прямая реализация единого многополюсного фильтра, т.к. чем выше порядок фильтра, тем меньше его устойчивость — цифровые рекурсивные фильтры высоких порядков склонны к возбуждению из-за погрешностей округления при вычислении, т.е. это надо относительно широкое представление вещественного числа брать, которое на сегодня зачастую исключительно эмулируемое в софте.
В общем, основная идея в том, что можно найти минимальное представление линейной такой комбинированной системы, т.е. свести к минимальному кол-ву линий задержек (нерекурсивные фильтры самые дорогие) из исходного их кол-ва и произвольных связей.
Над каждой линией задержки будет более одной обратной связи с разной "дистанцией", в т.ч. с небольшой, достаточной для рекурсивных фильтров, для параллельной и последовательной их реализаций.
S>>>Ну, по сравнению с арифметикой даже они гораздо дороже. Как сделать табличную аппроксимацию в SIMD?
V>>Через a*x+b
S>Не-не-не-не-не, Дэвид Блейн. ax+b — это линейное преобразование. Таблица — это когда у меня значения выхода произвольные.
Не понял возражения.
Для линейной интерполяции по таблице у нас есть прямая и точка на этой прямой.
Индекс значений i (a[i], b[i]) — целая часть значения (после масштабирования на размер таблицы), x — дробная часть.
Это классический вариант табличной линейной интерполяции.
Или ты имел ввиду "сырой" вариант табличной апроксимации, когда таблица будет содержать в ячейках таблицы непосредственные значения выходной ф-ии вместо коэф. {a,b}? Тогда искомую прямую придётся строить каждый раз заново по двум точкам {a[i], a[i+1]}: a[i]*(1-x)+a[i+1]*x, где i — опять целая часть, x — дробная.
По "сырому" методу операций больше на одно умножение и три сложения.
S>То есть я беру, скажем, логарифм по некоторому основанию от x, и рассчитываю его для всех 65536 возможных значений x, складывая в таблицу.
S>А потом вычисляю logtable[x] для каждого x.
S>Вот как развлекались любители математики 12 лет тому: http://jrfonseca.blogspot.com/2008/09/fast-sse2-pow-tables-or-polynomials.html
А в чем там "математичность"?
Что использовали формулу суммы степеней exp(a+b)=exp(a)*exp(b)?
На олимпиадах для 7-8-х классов подобные задачи дают.
А меня, как программиста-профика, интересуют вещи куда как более скучные, см. выделенное:
— никакой интерполяции не происходит, даже линейной, именно поэтому по ссылке баловство.
Кто-то дорвался "немного попрограммировать".
S>То есть работать с 16-битным звуком напрямую через них не выйдет.
На HD Audio идёт туда-обратно обычно int32.
AC'97 в живых, наверно, уже и не осталось.
Но стандарты цифрового софта давно сошлись на потоке IO float32.
Как остроумно объяснил один аудиофил другому:
Сейчас стандарт float32 потихоньку пролазит в железо, например, в USB-аудио-девайсы.
Фишка в том, что АЦП/ЦАП на 32 честных бита задешево — давно реальность, и даже начинают превышать 32 бита в проф.аппаратуре (значит, в обозримом будущем доедет и до ширпотреба).
И не потому что нужна такая точность, а потому что из-за динамического диапазона.
Например, для тихого сигнала при разрядности 16 бит реальная разрядность была пару бит всего, а то и 1.
Вот и получается, что для настраиваемого динамического диапазона 24 бита за глаза хватает, а для ненастраиваемого и 32 бита так себе.
V>>В 2 раза развёртки циклов я не видел ни разу в ассемблерном виде в релизе.
V>>От 16 до 128 с шагом в степень двойки видел.
S>А чего далеко ходить? Вот, берём простейший код поэлементного сложения массивов. Максимально дружественный к векторизации.
S>Гляньте — какой имеем loop unroll factor: https://godbolt.org/z/919Mf9 ?
Нулевой:
S>Покажите мне код, который разворачивается в SIMD с фактором хотя бы в 16, не говоря уже о 128.
Давай ты мне просто поверишь на слово или забьёшься на спор, оформив чётко своё возражение?
S>А зачем нам нецелые смещения?
Чтобы обеспечить кач-во.
S>Выражение 0.2*x[-3.5]+0.1*x[-4.3] сводится к 0.1*x[-3]+0.17*x[-4]+0.03*x[-5], и у нас опять всё целое.
Навряд ли сводится именно таким образом.
Если по 3-м точкам, то искомая точка будет на параболле.
S>Если нас интересует период эха, то как бы 44кГц уже дают точность в 22.6 микросекунд — вряд ли слушатель заметит, что эхо приходит не ровно через 2.5 секунды, а через 2.500023.
Это если эхо статичное.
V>>До какой-то степени можно, конечно.
V>>Это как минимизация выражений, распространение констант и т.д.
V>>В общем, всё то, что входит в стадию бета-редукции у современных оптимизирующих компиляторов, с учётом предметной области вычислений.
S>Если мы уже перешли к линейным фильтрам, то они компонуемы просто по определению. Любая комбинация линейных фильтров является линейным фильтром.
Это в теории непрерывных вычислений.
А как на практике сложить дискретные (цифровые) рекурсивный и нерекурсивный фильтры в один? ))
(линия задержки — это тоже нерекурсивный фильтр с коэфициентами 0, 0, ..., 1)
У них принципиально разный отклик, не выражаемый в общем случае один из другого (при разумной длине нерекурсивного фильтра).
Но так-то ты говоришь верно, просто у тебя недостаточно информации.
Например, такой, что рекурсивные фильтры высоких порядков часто реализуют как каскадное или параллельное подключение фильтров 2-го порядка, зависит от расположения полюсов по квандрантам.
Это предпочтительней, чем прямая реализация единого многополюсного фильтра, т.к. чем выше порядок фильтра, тем меньше его устойчивость — цифровые рекурсивные фильтры высоких порядков склонны к возбуждению из-за погрешностей округления при вычислении, т.е. это надо относительно широкое представление вещественного числа брать, которое на сегодня зачастую исключительно эмулируемое в софте.
В общем, основная идея в том, что можно найти минимальное представление линейной такой комбинированной системы, т.е. свести к минимальному кол-ву линий задержек (нерекурсивные фильтры самые дорогие) из исходного их кол-ва и произвольных связей.
Над каждой линией задержки будет более одной обратной связи с разной "дистанцией", в т.ч. с небольшой, достаточной для рекурсивных фильтров, для параллельной и последовательной их реализаций.
S>>>Ну, по сравнению с арифметикой даже они гораздо дороже. Как сделать табличную аппроксимацию в SIMD?
V>>Через a*x+b
S>Не-не-не-не-не, Дэвид Блейн. ax+b — это линейное преобразование. Таблица — это когда у меня значения выхода произвольные.
Не понял возражения.
Для линейной интерполяции по таблице у нас есть прямая и точка на этой прямой.
Индекс значений i (a[i], b[i]) — целая часть значения (после масштабирования на размер таблицы), x — дробная часть.
Это классический вариант табличной линейной интерполяции.
Или ты имел ввиду "сырой" вариант табличной апроксимации, когда таблица будет содержать в ячейках таблицы непосредственные значения выходной ф-ии вместо коэф. {a,b}? Тогда искомую прямую придётся строить каждый раз заново по двум точкам {a[i], a[i+1]}: a[i]*(1-x)+a[i+1]*x, где i — опять целая часть, x — дробная.
По "сырому" методу операций больше на одно умножение и три сложения.
S>То есть я беру, скажем, логарифм по некоторому основанию от x, и рассчитываю его для всех 65536 возможных значений x, складывая в таблицу.
S>А потом вычисляю logtable[x] для каждого x.
S>Вот как развлекались любители математики 12 лет тому: http://jrfonseca.blogspot.com/2008/09/fast-sse2-pow-tables-or-polynomials.html
А в чем там "математичность"?
Что использовали формулу суммы степеней exp(a+b)=exp(a)*exp(b)?
На олимпиадах для 7-8-х классов подобные задачи дают.
А меня, как программиста-профика, интересуют вещи куда как более скучные, см. выделенное:
/* index = EXP2_TABLE_OFFSET + (int)(fpart * EXP2_TABLE_SCALE) */— никакой интерполяции не происходит, даже линейной, именно поэтому по ссылке баловство.
Кто-то дорвался "немного попрограммировать".
S>То есть работать с 16-битным звуком напрямую через них не выйдет.
На HD Audio идёт туда-обратно обычно int32.
AC'97 в живых, наверно, уже и не осталось.
Но стандарты цифрового софта давно сошлись на потоке IO float32.
Как остроумно объяснил один аудиофил другому:
))32 bit floating is a 24 bit recording with 8 extra bits for volume.
Сейчас стандарт float32 потихоньку пролазит в железо, например, в USB-аудио-девайсы.
Фишка в том, что АЦП/ЦАП на 32 честных бита задешево — давно реальность, и даже начинают превышать 32 бита в проф.аппаратуре (значит, в обозримом будущем доедет и до ширпотреба).
И не потому что нужна такая точность, а потому что из-за динамического диапазона.
Например, для тихого сигнала при разрядности 16 бит реальная разрядность была пару бит всего, а то и 1.
Вот и получается, что для настраиваемого динамического диапазона 24 бита за глаза хватает, а для ненастраиваемого и 32 бита так себе.
V>>В 2 раза развёртки циклов я не видел ни разу в ассемблерном виде в релизе.
V>>От 16 до 128 с шагом в степень двойки видел.
S>А чего далеко ходить? Вот, берём простейший код поэлементного сложения массивов. Максимально дружественный к векторизации.
S>Гляньте — какой имеем loop unroll factor: https://godbolt.org/z/919Mf9 ?
Нулевой:
.L5:
vmovdqu ymm1, YMMWORD PTR [rsi+rax]
vpaddb ymm0, ymm1, YMMWORD PTR [rdx+rax]
vmovdqu YMMWORD PTR [rcx+rax], ymm0
add rax, 32
cmp rax, r8
jne .L5S>Покажите мне код, который разворачивается в SIMD с фактором хотя бы в 16, не говоря уже о 128.
Давай ты мне просто поверишь на слово или забьёшься на спор, оформив чётко своё возражение?
S>А зачем нам нецелые смещения?
Чтобы обеспечить кач-во.
S>Выражение 0.2*x[-3.5]+0.1*x[-4.3] сводится к 0.1*x[-3]+0.17*x[-4]+0.03*x[-5], и у нас опять всё целое.
Навряд ли сводится именно таким образом.
Если по 3-м точкам, то искомая точка будет на параболле.
S>Если нас интересует период эха, то как бы 44кГц уже дают точность в 22.6 микросекунд — вряд ли слушатель заметит, что эхо приходит не ровно через 2.5 секунды, а через 2.500023.
Это если эхо статичное.