Доброго времени суток!
После написания программного ФМ демодулятора сразу возникла проблема оптимизиции. Начал с оптимизации структуры демодулятора, переписал основные узлы, убрал тривиальные операции, что можно заменил таблицами и т.д. и т.п., в общем выжал все возможное. В результате получил 1,5 Мсим/с символьной скорости в реальном масштабе времени на Intel Core2Duo 2,4 GHz. Но надо еще быстрее. Единственным возможным выходом вижу переход демодулятора на работу с целочисленной арифметикой т.е. замена всех операций с плавающей точкой на целочисленные, но как это реализовать пока не знаю. Посему прошу помощи уважаемой аудитории предоставить любую информацию по этому вопросу, заранее благодарен.

Делайте на FPGA.

Надо на персоналке.

Не получите на персоналке много, на FPGA десятки мегабод легко.
Вообще непонятно как быть когда операционная система задумывается на неопределённое время? А зачем такое на персоналке если не секрет?

какая ОС, язык, компилятор? вспомните про ассемблер
говорят еще на фортране быстро летает, может даже в матлабе будет быстрее- там оптимизированно много чего.
есть еще один невероятный совет- pci плата с каким нибудь ДСП или той же ФПГА.

Использовать Intel C compiler и написать все в интристиках задействующих SSE2(3).

Используйте SIMD инструкции, гораздо шустрее будет. Если задержка на обработку не важна, можно для этой цели современную видеокарту использовать.

На ПЛИС понятное дело что быстрее. Секрета никакого нет, просто стоимость разработки на базе ПЭВМ определяется в конечном счете по сути только стоимостью самого сервера, разработка на ПЛИС стоит гораздо дороже.


Именно его и использовал совместно с IPP производительность существенно повысилась


ОС Win32, компилятор C от Intel совместно с Intel primitive performance. Поэтому использовать ассемблер нет смысла.


Прошу прощения не понял причем здесь видеокарта

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

Современные видеокарты можно использовать для вычислений. Они уже поддерживают плавающую точку с двойной точностью, есть библиотеки, типа http://rapidmind.net/, которые позволяют более-менее прозрачно использовать их ресурсы. Однако, мне FPGA в данном случае тоже кажется более перспективным вариантом...

Не знал об этом, интересное предложение, обязательно проанализирую, спасибо. Не дадите ссылочку где можно скачать библиотеки?

rapidmind, к сожалению, убрали из открытого доступа. Теперь вроде как регистрироваться нужно, чтобы скачать...
Есть библиотеки на сайтах AMD (Stream) и Nvidia (Cuda), можно их использовать. AMD ещё собиралась свою ACML портировать под Stream.

Спасибо за ссылки буду разбираться. Как по вашему что лучше IPP или CUDA при всех прочих равных условиях?

IPP - это интеловская библиотека?
Вообще, чтобы видеокарту эффективно использовать, нужно весь алгоритм реализовать в виде операций над векторами (или матрицами). Это не всегда легко сделать, а для некоторых алгоритмов и вообще нереально. Ещё напрягает отсутствие в этих (видеокарточных) библиотеках спецфункций.

Да, IPP это интеловые библиотеки плюс к этому есть еще и компилятор (последний по-моему Intel C++ compiler v.11.0.066 сейчас как раз выкачиваю ). Вещь стоящая, после того как переписал демодулятор с использованием этих функций и компилятора (+ оптимизация под Core2Duo) производительность увеличилась в разы.

киньте ссылку на алгоритм (желательно общими словами, т.е. теорию), прикинем рационально ли на видеокарточке такое сделать.
какое ТЗ в общих чертах? вычисления офлайн/онлайн? какой жирины поток данных требуется обрабатывать?

Алгоритм и ТЗ скинул в файл

мда, вот на счёт реального мсштаба времени и под вин32 это наверное сложно. вообще из ТЗ не понял как вы организовали тракт данных на ПК. где-то есть буфферизация? если смотреть в сторону графического сопроцессора, то нужно учитывать, что это всё-таки плата расширения и гонять данные придётся через PCI-Express (~ 4ГБ/с при х16). естественно целесообразно гонять по ней большие массивыданных, потому что карточка работает по принципу SIMD (а точнее SPMD - single programm multiple data) то есть там стоит массив (десяток блоков) SIMD процессоров (по 16 голов в каждом) и естественно без параллелизации потоков данных игра не стоит свеч. может вы побольше расскажите как организована система, а то я обработкой сигналов не занимаюсь и в тему сходу въехать не могу

2CaPpuCcino
Буферизация есть на входе (принимается блок данных, осуществляется его преобразование к нужному формату и далее передается непосредственно на демодулятор). В самом демодуляторе работа организована потактно иначе не получится. Единственное где можно выиграть это только при фильтрации, когда осуществляется свертка входного сигнала с ИХ фильтра. Там как раз и обрабатываются довольно большие объемы данных на каждом такте и эти операции можно распараллелить. Во всех остальных местах обработка осуществляется на уровне элементарных арифметических операций и упростить их уже не получится. Вы с CODA сталкивались, какие впечатления от использования, стоит ли ее пробовать для оптимизации. Видяха есть в наличии ASUS nVidia 8800 GT. И спасибо за потраченное время

я вам своими словами пересказывать не буду, всё (что это архитектурно и как с этим работать) достаточно хорошо расписано на родном сайте http://www.nvidia.com/object/cuda_education.html (первые ссылки вообще видео тьюториалы). субъективные впечатления - в самом компиляторы есть незначительные глюки, но версии достаточно быстро обновляются (например в CUDA 1.1 компилер, кажись, спотыкался на многострочных макросах в 2.0 это уже убрали). алгоритмы с возможностью распараллеливания данных ускоряются раз в 10 без особой SIMD оптимизации за счёт распараллеливания на массиве мультипроцессоров SPMD. по синтаксису это Си надстроеный директивами и макросами, процесс привыкания от нескольких недель до месяца.