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

[sigmaN]

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

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

[fontp]

Можно, только не в 3-5, а скорее раз 8-10
Для этого обычно строят библиотеки "короткого" нестандартного FP
Чтобы удобно (т.е. быстро) было работать. Слово мантисы + слово экспоненты
И никаких проверок на потерю точности - с ними всё равно нечего делать в риал-тайме
Ещё они должны быть inline, иначе труба
Такие библиотеки есть. Можете и сами написать умножение деление сложение и вычитание.
Преобразование типа из/в int и float можно где-нибудь найти на С
Если Вы хотите приспособить к SPEEX без переписывания, то проблемы всё равно останутся.
Во-первых операторами можно оформить только в СPP, в С это функции/ SPEEX это С, а значит...
Во-вторых в чужих проектах используются стандартные математические библиотеки math.h,
а это уж точно прийдётся самому писать под новый тип новую реализацию - sin, sqr, и что там ещё есть в SPEEX

[sigmaN]

Можно, только не в 3-5, а скорее раз 8-10

Да уж... труба дело :-)
Неужели всё-таки придется окунуться в математику и переписывать некоторые алгоритмы на целочисленную модель.
А есть где-нибудь мануальчики как это обычно делается.
Ну там, начиная от анализа существующего FP алгоритма и так далее чтобы на выходе был ФТ алгоритм.

Видимо от этого никуда не деться....:-(

[fontp]

Да уж... труба дело :-)
Неужели всё-таки придется окунуться в математику и переписывать некоторые алгоритмы на целочисленную модель.
А есть где-нибудь мануальчики как это обычно делается.
Ну там, начиная от анализа существующего FP алгоритма и так далее чтобы на выходе был ФТ алгоритм.

Видимо от этого никуда не деться....:-(

Если никуда не деться... Могу посоветовать AN EE-185 для BF
Там хоть преобразование типов есть на С, операции на асемблере (делать самому, если не знать его ассемблера, чтобы использовать как прототип), ну и вообще по тексту описание
FastFloat16 или FastFloat32
Это на www.analog.com Application Note
Как у ti c такими библиотеками - не знаю, возможно, что и есть
Математику, в смысле, стандартные функции с нужной точностью - самому


Потом грамотно целый класс в С++ накропать
Типа c таким прототипом
http://www.koders.com/cpp/fid5E90955711BFB...C383C.aspx#L103

Потом все модули SPEEX переименовать в cpp, компилировать и править ошибки :-)

[DRUID3]

Если никуда не деться... Могу посоветовать AN EE-185 для BF
Там хоть преобразование типов есть на С, операции на асемблере (самому, если не знать его ассемблера, чтобы использовать как прототип), ну и вообще по тексту описание
FastFloat16 или FastFloat32
Это на www.analog.com Application Note
Как у ti c такими библиотеками - не знаю, возможно, что и есть
Математику, в смысле, стандартные функции с нужной точностью - самому
Потом грамотно целый класс в С++ накропать
Типа c таким прототипом
http://www.koders.com/cpp/fid5E90955711BFB...C383C.aspx#L103

Потом все модули SPEEX переименовать в cpp, компилировать и править ошибки :-)

Я еще speex не собирал, и вот заинтересовался темой. Но...

во-первых - помниЦЦо в VDSP++ есть float для целочисленных процессоров. В чем проблема? На Bf все будет летать и так. Что надо переписывать? Я кода-то с float алгоритмы переносил на fix так и то вспоминать не хочу больше... а если еще самому мутить матлибу (пусть и "быстрый float")- это ошибки человека + ошибки принципиальные - ну как в fix с масштабированием.

во-вторых - насколько я понимаю Linuxовый Speex для bf - целочисленный...и он вполне собираеЦЦо...??? Есть целочисленный вход/выход, в портах для TMS и BF используются типы данных на основе int. ... Что еще надо для души?

Ну и в-тетьих, если так хочеЦЦо float - то у AD есть серия дешевых SHARKов, они собственно для того и создавались что-бы не ломая голову применять акадэмические(книжные) алгоритмы. Тем более что их производительности хватит еще на корзинку таких speexов...

P.S.: собственно мне не понравился подход... не хочу чтобы медаппаратуру, например, даже для зубного кабинета, разрабатывали так...

[fontp]

Я еще speex не собирал, и вот заинтересовался темой. Но...
во-первых насколько я помню в VDSP++ есть float для целочисленных процессоров. В чем проблема? На Bf все будет летать и так. Что надо переписывать? Я кода-то с float алгоритмы переносил на fix так и то вспоминать не хочу больше...а если еще самому мутить матлибу - это ошибки человека + ошибки принципиальные - ну как в fix с масштабированием.
во-вторых - насколько я понимаю Linuxовый Speex для bf - целочисленный...и он вполне собираеЦЦо...??? Есть целочисленный вход/выход, в портах для TMS и BF используются типы данных на основе int. ... Что еще надо для души?

Он хочет VBR, jitter buffer и эхоподавитель
А все эксперементальные, недоделаные фичи в SPEEX - float, что в общем-то правильно. Зачем вылизывать алгоритмы, которые ещё десять раз будут переделаны?

Порты BF и TMS int но он их не хочет ;-) В стандартном float32 ни BF ни TMS sPEEX с прибабахами не потянут
Вообще-то float всегда это больше fast prototyping - типа для лохов. Но человек хочет повозиться с прибабахами. Я так понимаю

Быстродействие int на BF я проверял
http://electronix.ru/forum/index.php?showt...36206&st=15
На tms помедленей, упомянуто там же

[sigmaN]

Он хочет VBR, jitter buffer и эхоподавитель
А все эксперементальные, недоделаные фичи в SPEEX - float, что в общем-то правильно. Зачем вылизывать алгоритмы, которые ещё десять раз будут переделаны?

Порты BF и TMS int но он их не хочет ;-) В стандартном float32 ни BF ни TMS sPEEX с прибабахами не потянут
Вообще-то float всегда это больше fast prototyping - типа для лохов. Но человек хочет повозиться с прибабахами. Я так понимаю

Быстродействие int на BF я проверял
http://electronix.ru/forum/index.php?showt...36206&st=15
На tms помедленей, упомянуто там же

Правильно понимаете.
Мне очень нужны именно эти фичи - без VBR и эхоподавления никак мне не жить.
На int там действительно только кодер/декодер - этого мало для решения моей задачи.
То, что типа для лохов - это тоже верно, но щас важнее чтоб по быстрому всё заработало и запахло капустой :-)
Потом следующую версию забабахаю на ФТ(если получится).
Есть ведь TMS320F28335 c FPU - вот на нем всё это без переделок пойдет. Просто жрет он очень много! Это меня и насторожило.

То, что тема это гнилая(мутить алгоритм ПТ на процах ФТ) - и ежу понятно, хотелось просто это ещё раз услышать.

Вообще Speex очень хорош!
Я на PC провел испытания качества на низких битрейтах - просто сказка!
Нужно будет взяться и разрулить как-нибудь всё на ФТ.

[DRUID3]

Он хочет VBR, jitter buffer и эхоподавитель
А все эксперементальные, недоделаные фичи в SPEEX - float, что в общем-то правильно. Зачем вылизывать алгоритмы, которые ещё десять раз будут переделаны?

Порты BF и TMS int но он их не хочет ;-) В стандартном float32 ни BF ни TMS sPEEX с прибабахами не потянут
Вообще-то float всегда это больше fast prototyping - типа для лохов. Но человек хочет повозиться с прибабахами. Я так понимаю

Быстродействие int на BF я проверял
http://electronix.ru/forum/index.php?showt...36206&st=15
На tms помедленей, упомянуто там же

Ну спасибо...так перечеркнуть все мои надежды на SHARC. К стати, они его не даром для музыки и радиолюбителей позиционируют, ибо это еще и low digital noise in superlongest accumulation operation .
а так, по кодеку, вобщем ясно... Кстати, я тут недавно заинтересовался нелинейными системами, а там чем больше точность тем больше матриц матриц которые матрицы матриц ...может попробую bf561 тем более и луникс для него оказываеЦЦо есть. Если правильно распределить потоки - то в среднем можно на суммарнуй 1 Гигатакт расчитывать....уж если он speex float не потянет, то даже не знаю...

[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

[sigmaN]

Господа, ну послушайте не сэмплы с сайта, которые действительно ужасно звучат(они просто закодированы/раскодированы на стандартных настройках кодера), а проведите эксперимент самостоятельно. VBR дает обалденное качество на 4Кб/с, по сравнению с другими!
Ну может быть посоветуйте что-нибудь, чтобы было не хуже GSM по субъективным оценкам пользователей, но на скорости не более 4.5.
Задача вообще решаема?
GSM очень расточителен(целых 13Кб/с!)

Да, халява это приятно всегда.
Блин, а этот шарк аж 370мА захавывает - это очень много для меня(батарейка мобилы просто умрет за часок-другой).

Сообщение отредактировал sigmaN - Apr 4 2008, 09:05