Операции с плавающей точкой без FPU, На сколько падает производительность? Опции

[sigmaN]

Интересно, а можно ли на целочисленном DSP с запасом производительности(скажем в 3-5 раз) зарулить вокодер на плавающей точке?

И вообще, каков overhead, так сказать, FP операций на проце без FPU?
Страдает ли точность вычисления?
Что нужно для подобных "извращений"?
Может быть есть какая-то библиотека виртуального FPU, так сказать?
DSP Техас 55 серии.

[Stanislav]

Интересно, а можно ли на целочисленном DSP с запасом производительности(скажем в 3-5 раз) зарулить вокодер на плавающей точке?

Нельзя.

И вообще, каков overhead, так сказать, FP операций на проце без FPU?

Примерно два порядка.

Страдает ли точность вычисления?

Относительно чего?

Что нужно для подобных "извращений"?

Быть "извращенцем".

Может быть есть какая-то библиотека виртуального FPU, так сказать?
DSP Техас 55 серии.

Библы есть какие-то, конечно, в т.ч., и стандартные. Только зачем они Вам? Компилятор плывучку поддерживает и для целочисленных DSP, а для нормальной плавающей точки нужно брать и процессор соответствующий.

[sigmaN]

Нельзя.
Примерно два порядка.
Относительно чего?
Быть "извращенцем".
Библы есть какие-то, конечно, в т.ч., и стандартные. Только зачем они Вам? Компилятор плывучку поддерживает и для целочисленных DSP, а для нормальной плавающей точки нужно брать и процессор соответствующий.

Ясно всё.
В общем нужно детальнее разбираться в алгоритмах работы нужных мне фич и не обращать внимание на плывучку, как вы говорите.
Точность Относительно чего? Ну я имел ввиду относительно DSP с FPU. Но, понятно, вопрос дурацкий на самом деле

А можно какие-нибудь подсказки по методике перевода алгоритма на целочисленные вычисления?
Я, честно говоря, пока четко себе не представляю сам процесс....

[Stanislav]

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

Строго говоря, вычисления лучше делать не в целых числах, а в числах с фиксированной точкой (fixed point arithmetics). Попробуйте погуглить - найдёте немало интересного. Кроме того, на сайтах AD и TI есть много статей, аппнотов и мануалов, посвящённых данному вопросу.
Однакож, и "плавающие" DSP никто не запретил юзать. Попробуйте-ка найти приличный fixed-point DSP за такую цену.

...А можно какие-нибудь подсказки по методике перевода алгоритма на целочисленные вычисления?
Я, честно говоря, пока четко себе не представляю сам процесс...

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

Есть и хитрости более "высокого порядка". Например, во многих вокодерах для параметрического оценивания используется рекурсивный алгоритм Левинсона-Дарбина, который весьма чувствителен к усечению разрядов. Заменив его на немного менее эффективный вычислительно метод LeRoux (Schur recursion), получим гораздо большую устойчивость решения для DSP с фиксированной точкой.
Кроме того, часть вычислений (не менее 10-20%) придётся писать на АСМе, потому что ЯВУ не поддерживают многие полезности архитектур DSP.

ЗЫ. А вообще, посмотрите стандарты. Алгоритмы работы вокодеров создаются обычно так, чтобы их легко можно было реализовать в целочисленном процессоре.
ЗЗЫ. А почему именно SPEEX? Послушал сэмплы на сайте speex.org - не понравилось мне звучание, особенно при малых битрейтах. Тот же G723.1 звучит заметно лучше, да и и MELP при 2400 бит/с ему точно не уступает...

[fontp]

ЗЗЫ. А почему именно SPEEX? Послушал сэмплы на сайте speex.org - не понравилось мне звучание, особенно при малых битрейтах. Тот же G723.1 звучит заметно лучше, да и и MELP при 2400 бит/с ему точно не уступает...

SPEEX CELP и звучит как CELP. Как G723.1 на 5.3 кб/cек. А MELP звучит конечно великолепно для 2.4кб/сек, но в целом так себе, если с потоком не париться

В варианте VBR SPEEX по идее должен, как говорят авторы, звучать лучше большинства стандартных.
Верю. Есть правда и стандарты VBR - тот же G726.2 AMR-NB

C другой стороны переменный битовый поток порождает свои проблемы - с тем же буфером джитера и всё такое. SPEEX "просто сказка" в том смысле, что там есть много чего нахаляву. Дело не только в том, что он open source, но и в том, что там много всяких дополнительных вкусностей. На вкус и цвет..., пусть расцветают все цветы..., у SPEEX есть тоже свои достоинства

Потом речь идёт не о том, чтобы "сделать", а о том, чтобы портировать готовое. Т.е. на С и если говорить о sPEEX vbr - то во float.

Во float по нормальному, вообще-то лучше использовать float процессор. И действительно, стандартный IEEE float тянет примерно два порядка быстродействия на процессоре FIXED
Или пользоваться суррогатными типами если нужно сделать за так и быстро :-) Тянет примерно один порядок
Пацан спросил-пацан ответел :-)

[Stanislav]

SPEEX CELP и звучит как CELP. Как G723.1 на 6.3 кб/cек.

Не знаю, может, сэмплы неудачные, но по мне, так SPEEX 6 кб/с звучит значительно хуже G 723.1 5.3 кб/с.

Кроме того, G723.1 - это не CELP, которым, как известно, является FS-1016, и SPEEX очень похож на него. У G723.1 формирование адаптивной кодовой книги производится иным способом.

...А MELP звучит конечно великолепно для 2.4кб/сек, но в целом так себе, если с потоком не париться

Мне показалось, что никак уж не хуже SPEEX на нижнем битрейте.

В варианте VBR SPEEX по идее должен, как говорят авторы, звучать лучше большинства стандартных.

Интересно, а за счёт чего он будет звучать лучше, скажем, того же FS-1016?
Ну, а на VBR можно переделать любой вокодер. С уменьшением устойчивости к ошибкам передачи, естественно.

...C другой стороны переменный битовый поток порождает свои проблемы - с тем же буфером джитера и всё такое. SPEEX "просто сказка" в том смысле, что там есть много чего нахаляву. Дело не только в том, что он open source, но и в том, что там много всяких дополнительных вкусностей. На вкус и цвет..., пусть расцветают все цветы..., у SPEEX есть тоже свои достоинства

С этим спорить не буду. Нахаляву оно, конечно, слаще...
Не подумайте, что я отношусь неодобрительно к SPEEX проекту - наоборот, считаю его очень полезным. Только вот "до кондиции" ему ещё далековато...

Потом речь идёт не о том, чтобы "сделать", а о том, чтобы портировать готовое. Т.е. на С и если говорить о sPEEX vbr - то во float.

Ага, и при этом головой абсолютно не думать. Лафа, паньмаешш, мечта "имбедецила".

...Или пользоваться суррогатными типами если нужно сделать за так и быстро :-) Тянет примерно один порядок.

А один порядок - это сколько?
По-моему, даже любой суррогатный тип уменьшит быстродействие DSP на типовых операциях значительно более 8-10 раз.

[fontp]

Не знаю, может, сэмплы неудачные, но по мне, так SPEEX 6 кб/с звучит значительно хуже G 723.1 5.3 кб/с.

Кроме того, G723.1 - это не CELP, которым, как известно, является FS-1016, и SPEEX очень похож на него.


Мне показалось, что никак уж не хуже SPEEX на нижнем битрейте.

Интересно, а за счёт чего он будет звучать лучше, скажем, того же FS-1016?

С 6.3 я погорячился, исправил на 5.3 ещё до Вашего поста.
G723.1 (5.3) - это ACELP, c FS-1016 одного поля ягода. "A" в ACELP влияет на скорость поиска,
но не на размер таблицы, а значит качество звучания
Слушать SPEEX нужно в соответствующем диапазоне > 4.8. На нижнем диапазоне 2.4 его лучше вообще не слушать.

Вообще-то главным образом качество CELP зависит от того как сделан поиск по стохастической кодовой книге - с разорваной обратной связью или без разорваной (разница между G729 и G729A)
Т.е. полный перебор или декомпозиция "переборов"
При одинаковых битрейтах качество зависит ещё от тщательности и развесистости векторного квантования.Не знаю уж, где оно лучше исполнено.
А так всё примерно одинаково (FS1016, SPEEX, G723/1 - 5.3) - линейные предсказания, спектральные пары, кодовые книги и т.д. Примерно одна фигня

А один порядок - это сколько?
По-моему, даже любой суррогатный тип уменьшит быстродействие DSP на типовых операциях значительно более 8-10 раз.

Да ладно. Посмотрите как написано в FastFloat16 в соответствующем EE185 для BF
Мантиссы умножил, порядки сложил - вот и умножение
Нормализовал операнды к большему порядку, сложил мантиссы - вот и сложение
Или деление. Фигня. Нормализация и целочисленное деление.
Нормализация у BF - это две операции, норм и шифт. На ADSP2105, понятно, ничего не получится, нет там аппаратной нормализации :-)
Всё инлайн. Без проверок переполнения и потери точности. В 10 раз даже много.
Нет, ну за три такта тоже не получится, конечно
Относительная точность - лучше 10**-4. Но это относительная точность, не абсолютная, как у fixed16.
Практически всегда достаточно такой, чего нельзя сказать про fixed16

[Stanislav]

С 6.3 я погорячился, исправил на 5.3 ещё до Вашего поста.
G723.1 (5.3) - это ACELP, c FS-1016 одного поля ягода. "A" в ACELP влияет на скорость поиска,
но не на размер таблицы, а значит качество звучания

Не соглашусь, пожалуй.
"А" - это алгебраический способ возбуждения адаптивной кодовой книги, в отличие от стохастического, как в "родном" CELP-е. Видимо, более эффективный - качество звучания ACELP-5,3 заметно выше, чем CELP-4,8. Особенно на высоких мужских и женских голосах.

Слушать SPEEX нужно в соответствующем диапазоне > 4.8. На нижнем диапазоне 2.4 его лучше вообще не слушать.

Я слушал сэмплы на 4 и 6 кб/с. Честно говоря, "нифпечатлило".

...А так всё примерно одинаково (FS1016, SPEEX, G723/1 - 5.3) - линейные предсказания, спектральные пары, кодовые книги и т.д. Примерно одна фигня

Может быть, а только по мне G723.1 звучит всё-таки лучше. Правда, я давно этими делами не занимался, и у меня нет сейчас "работающих" реализаций для РС. Если у Вас есть, можно попробовать сравнить на разных речевых фрагментах, и выложить здесь результаты, на суд публики.

...Да ладно. Посмотрите как написано в FastFloat16 в соответствующем EE185 для BF
Мантиссы умножил, порядки сложил - вот и умножение
Нормализовал операнды к большему порядку, сложил мантиссы - вот и сложение
Или деление. Фигня. Нормализация и целочисленное деление.
Нормализация у BF - это две операции, норм и шифт.

Ну, вот и попробуйте сделать операцию типа свёртки над двумя или более массивами в формате, скажем, 1.15, и то же самое с любым "плывучим" форматом. А потом сравним.
Операции типа свёртки, кстати, отнимают около 90% вычислительной нагрузки при реализации вокодера CELP, так что остальное можно не учитывать.

...На ADSP2105, понятно, ничего не получится, нет там аппаратной нормализации :-)

Ошибаетесь - есть.

...Всё инлайн. Без проверок переполнения и потери точности. В 10 раз даже много.

По-моему, в 10 раз всё-таки не получится... Могу предоставить пример исходника, на котором всё это можно проверить, но попозже.

[fontp]

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

У меня есть буквально ВСЁ, но не хочу я этим заниматься, времени жалко. Оно всё ещё и плывёт от условий. Про экспертов и их субъективные оценки, я, как эксперт, уже всё сказал: "Всякий эксперт при субъективной оценке должен учитывать, что его не только могут не позвать в другой раз, но могут и не заплатить в этот" (с)
Наиважнейшее правило для всех экспертов. Копирайт мой собственный

От МOS 3 до 3.5 - качество приемлемое
От 3.5 до 4.0 - хорошее
Ниже 3.0 - синтетическое

Цитата: g729a сохраняет не ниже 3.5 при потере 3.5% пакетов, а при 5% качество падает до 3.0
g723.1 сохраняет стандартное качество 3.5 при потере менее 1% пакетов, а при 3% падает до 2.8
Конец цитаты.

В общем, не очень-то это занятие продуктивное - сравнивать... Экспертам за это хоть деньги дают

Ну, вот и попробуйте сделать операцию типа свёртки над двумя или более массивами в формате, скажем, 1.15, и то же самое с любым "плывучим" форматом. А потом сравним.

По уму нужно конечно делать блочную нормализацию и лупить целочисленно

Ошибаетесь - есть.

По-моему, в 10 раз всё-таки не получится... Могу предоставить пример исходника, на котором всё это можно проверить, но попозже.

Уже есть? Ну может и есть. Уже не помню

Вот mult для BF из EE185 FastFloat.asm

.global _mult_ff16;
_mult_ff16:

r3.l = r0.l + r1.l (ns);
a0 = r0.h * r1.h;

r2.l = signbits a0; // get the number of sign bits
a0 = ashift a0 by r2.l; // normalize the mantissa
r0 = a0;
r0.l = r3.l - r2.l (ns); // adjust the exponent

rts;

_mult_ff16.end:

А вот add
_add_ff16:
.global _add_ff16;

r2.l = r0.l - r1.l (ns); // is Ex > Ey?
cc = an; // negative result?
r2.l = r2.l << 11 (s); // guarantee shift range [-16,15]
r2.l = r2.l >>> 11;
if !cc jump _add_ff16_1; // no, shift y
r0.h = ashift r0.h by r2.l; // yes, shift x
jump _add_ff16_2;

_add_ff16_1:
r2 = -r2 (v);
r1.h = ashift r1.h by r2.l; // shift y
a0 = 0;
a0.l = r0.l; // you can't do r1.h = r2.h
r1.l = a0 (iu); // so use a0.x as an intermediate storage place
_add_ff16_2:
r2.l = r0.h + r1.h (ns); // add fractional parts
cc = v; // was there an overflow?
if cc jump _add_ff16_3;

// normalize
r0.l = signbits r2.l; // get the number of sign bits
r0.h = ashift r2.l by r0.l; // normalize the mantissa
r0.l = r1.l - r0.l (ns); // adjust the exponent

rts;


Ну, там addd нужно немного доработать, чтобы избавить от глупостей проверки переполнения - это лишнее. Никаких Jump не должно быть, понятно. Никаких проверок. И всё в inline оформить
Где здесь 20 тактов? :-)

Целочисленный MELP 2.4 кб/cек считается не хуже gSM, но хуже всех стандартных вокодеров серии G
co скоростью > 5.3

про качество MELP почему-то не вставилось в тот раз
http://maya.arcon.com/ddvpc/compmelp.htm
Это родные цифры качества
Его качество 3-3.5 т.е. в точности соответствует GSM (13 кбит) и примерно CELP 1016 (4.8 кбит)
Если нужно меньше 4 кбит, то это скорее всего melp