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

mikasa76
Откуда идет поток и в каком формате? (железо)
И насчет скорости потока - фиксированная?

mikasa76 Ничего не понятно, есле честно. Что такое 1,5 Мсим/с символьной скорости в реальном масштабе ? Это полтора милиона символов в секунду? Это простите 1,5 мегагерц тактовой. Много это или мало? Хз, для дискрета 48000 герц это помойму блеск. У вас какая задача вообще? Но надо еще быстрее сколько надо то? Для чего? На чём пишем? Чего демодулим? ФМ-2,4,8,16? Сигнал откуда? Реальный эфир или проводной канал, девайсы какие, карта или спецплата? Схема дема какая? Общие вопросы опимизации описаны у Тяжева, Окунева, Марпла и у ещё десятка авторов, но каждая задача имеет свои резервы. Не вникая в задачу и не зная конечной цели об чём можно говорить? В том виде в каком вопрос задан, это просто хочу что б было быстро, чего быстро, куда быстро, как быстро хз. Не наезда ради, но это, как то надо со стороны читать. Вам всё понятно, другим, есле вы сами не расказываете оно головоломка и напряг ненужный. Ну так гдето. Без обид.

2Mesh,NextDoor
Алгоритм и ТЗ скинул в файл. Теперь по-сути.
1. Диапазон символьных скоростей до полутора млн. символов (тактов, бод, Гц и др) в сек. для одного потока на Intel Core2Duo 2,4 GHz. Чем больше тем лучше чтобы еще осталась вычислительная мощность для решения других задач. Обработка ведется в режиме реального времени.
2. Частота дискретизации (скорость входного оцифрованного потока) произвольная (в рамках теоремы Котельникова с учетом крутизны спада АЧХ формирующего фильтра). Хотя в этом случае правильнее было бы говорить об отношении частоты дискретизации входного сигнала к тактовой. Сигнал берется с внешнего устройства АЦП через USB 2.0. Формат входного сигнала знаковые и беззнаковые I/Q квадратурные отсчеты 8/16 бит.
3. Канал можно рассматривать в первом приближении как канал с АБГШ. Замирания отсутствуют.
4. Манипуляция абсолютная фазовая ФМ2,4,8 и офсетная ФМ4.
5. Демодулятор выполнен по схеме оптимального квазикогерентнного приемника с адаптивной коррекцией МСИ (схема в прилагаемом файле).
6. ОС Win32 XP SP3, компилятор C от Intel совместно с Intel integrated performance primitive. Поэтому использовать ассемблер нет смысла. Арифметика с плавающей точкой.
7. Если еще нужны какие-либо комментарии - плз. Надеюсь что незря все это писал.

Извиняюсь что лезу, но постоянно вижу ситуацию, когда программы не понимают что процессоров более одного и грузят одно ядро, второе ничего не делает, очень глупо это выглядит на серваке с общим числом ядер 8. Такой проблемы нет случайно?

mikasa76
Еще один вопрос, чтоб точнее понять суть затеи - ок?
Если не секрет - для каких целей используется линк?
Раз в описании нет передатчика, это скорее всего
прием телеметрии. Случаем это не для HRPT ли затея?

Sergey4565
Есть такое дело. Признаюсь тоже недоумеваю зачем тогда многоядерность. Единственным выходом является распараллеливание процессов, поэтому чтобы обойти эту проблему надо либо запускать несколько потоков (для этого надо переделывать всю структуру демодулятора с соответствующей синхронизацией всех обрабатываемых потоков, что само по себе трудно реализуемо) либо использовать какие-либо сторонние библиотеки (например AMD (Stream) и Nvidia (Cuda) для видеокарт или rapidmind) в которых эта возможность заложена.
NextDoor
Секрета нет, просто отработка модели и алгоритмов.

mikasa76 Надеюсь что незря все это писал Конечно не зря, по крайней мере первая мысль у меня, ну ни фига себе задачка. :) Я конкретно пас, вникать надо глубоко, вплоть до конкретных реализаций отдельных модулей. Непонятно зачем ару в каждом канале, когда по условию канал без замираний? Может как нить это на узел АЦП повесить или совсем убрать? На таких скоростях экономия на простых операциях существено влияет.

Mesh
На таких скоростях - декодер можно и аппаратный сделать, а уже поток
данных лить в USB интерфейс. Примеров такой реализации достаточно.

Mesh
АРУ нужно для приведения сигнала к необходимому уровню для принятия решения в решающем устройстве. На АЦП повесить эту функцию (тем более совсем ее убрать) затруднительно так как само АЦП, а точнее приемник с АЦП являются внешними законченными устройствами. Что касается простых операций это действительно так и есть на самом деле, даже простые арифметические операции или операции сравнения существенно тормозят общую производительность, поэтому где можно было все тривиальные операции были по возможности устранены. Тем не менее достигнутые на данный момент скорости составляют 1,5 Мсим/сек

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

mikasa76 Вам конечно виднее, но это несколько страно. В ФМ по умолчанию все посылки одного уровня, даже есле уровень и плавает, то меняется только длина вектора, угол то остается тот же. Хз конечно как там у вас решающее устроено. Но так то ж не совсем понятно, чего это даёт. Какие прелести. Для кам да желательно крайне иметь постояную среднуюю амплитуду иначе всё разьедется, для ФМ хз, вроде не так уж и необходимо.

Mesh
Как тогда принимать решения и осуществлять дальнейшую подстройку фазы и частоты сигнала по несущей и тактам если уровни сигнала не приведены к "эталонным" значениям (длина вектора, т.е. амплитуда, как раз и определяет величину ошибки для подстройки коэффициентов ФАПЧ по несущей, а также величину ошибки для подстройки коэффициентов адаптивного корректора и, если АРУ убрать, то динамический диапазон по входному уровню сигнала будет настолько широк, что никакие подстройки мы не сможем осуществить или же тогда ДД узлов демодулятора должен соответствовать ДД входного сигнала), т.е. АРУ необходимо и это существенно облегчает реализацию демодулятора. ФМ сигналы это сигналы с постоянной огибающей и АРУ для них несколько проще в реализации нежели в сигналах с КАМ. Тем не менее АРУ необходимо как для ФМ так и для КАМ. Кроме того для КАМ система АРУ должна быть линейной в отличие от ФМ сигналов, где можно использовать и нелинейные схемы.

mikasa76 Ну я хз, у вас на РУ завязаны функции подстройки по несущей. Хотя формально, для ФМ дема постояноство амплитуд не есть необходимое условие, так как основная задача его получить текущую фазу посылки. Конечно есле на плоскость выводить точки с разной амплитудой то ето некрасиво, но для получения имено угла это неимеет значения. Да и сомнения что точки пляшут в диапазоне 60 дб, канал то без замираний, ну 6 дб, ну 9 и чего тут страшного? Мы ж про оптимизацию, я не говорю что это правильно, но что то в етом есть, зачем держать амплитуду насильно есле на угол это не влияет? Может и тупиковый путь, надо проверять. И кстате, разве адаптивный коректор амплитуду не выравнивает, вроде это его ж задача также? Тут не масло маслянное получается?

Mesh
Основная задача адаптивного корректора это борьба с МСИ особенно при использовании сигналов с большой спектральной эффективностью (ФМ8, КАМ). В небольшом диапазоне входных амплитуд он конечно амплитуду подтянет, но повторюсь, не его это задача. А так демодулятор довольно помехоустойчив (потери в режиме ФМ2,4 составляют 0,4 дБ, что сравнимо с промышленными образцами ведущих фирм производителей). Так что все узлы в отдельности и весь демодулятор в целом вроде как реализован достаточно неплохо и явных касяков нет, как говорится проверено временем и .... мною :-). Единственной проблемой остается увеличение производительности над чем в данный момент и голову ломаю.

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