День добрый.
Необходимо сформировать большой поток (в идеале >10 Мбит/с) в реальном времени и кидать его в UDP.
Формирователь состоит из источника данных, кодера, некая обработка над кодированными данными, добавление шума, формирование пакета.
Источник данных, кодер, добавление шума по отдельности работают ~ на 30 Мбит/с. А последовательно ~ 10 мбит/с при этом занято лишь одно ядро.
Внимание вопрос.
Можно ли организовать некий конвейер, когда источник данных занимает одно ядро, кодер другое, шум третье, а в UDP шлет четвертое?
Или это даже теоретически нельзя сделать?
Всем спасибо.

Надо на С писать (точно успеете).
А на Matlab - Вы на Simulunk или как, как написано, может все данные в таблицу занести и т.д. ........ ?
Может я и на Matlabe успел бы.

Пока этот вариант не рассматриваю. Может после того, как в Matlabe запущу на меньшей скорости буду думать про C.


*.m
В той реализации, что хочу использовать зациклить не получиться.

Смотрите хелп по Parallel computing. Распараллелить что-то можно, что-то нет.
Генерация вектором происходит? Или каждый сампл генерируется функцией и вызов функции в цикле?

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

doc 'parallel computing toolbox'

Это чтобы быстрее считать.

Если же затея - сделать на matlab систему реального времени с такой пропускной способностью, то это унылая затея.

Вектором.

UDP узкое место.
Вот вопрос можно ли как-нибудь по другому наладить скоростное взаимодействие между Matlab?

Так дважды посоветовали уже: parallel computing toolbox

- Дяденька милиционер, а можно я Вам анекдот расскажу.
- Ты что, я же милиционер!
- А я Вам два раза расскажу.


Спасибо.

1. Выкинуть нафиг этот долбаный матлаб (хотя, вообще, странно, что тупит: матлаб уже давным-давно даже Cuda умеет, не то, что тупо потоки).
2. Использовать pthreads, а хорошо распараллеливаемые сложные вычисления вообще на видеокарту загонять!

В матлабе из m-кода можно сгенерить Си код, скомпилировать тем же C++ компилятором и заставить крутиться на той же или другой платформе в реальном времени. Как правило, это ускоряет работу кода в разы. Смотрите http://nl.mathworks.com/products/matlab-coder/

Еще для DSP обработки в Матлабе пердусмотрены различные тулбоксы. Они обычно гораздо быстрее выполняют такие функции, так как оптимизированы самими программистами Матлаба.

На 100% не скажу, но по-моему это уже давно не так. Лет 5. Матлаб при запуске м файлов компилит их как-бы и исполняет в нативном коде.

Зависит всё от исходного m-кода. Если в нем содержатся в основном встроенные функции, а операции выполняются векторно, возможен даже проигрыш от перехода к C. Обычно выигрыш от генерации в 1,5-2 раза. Был у меня случай с реализацией MPA алгоритма, содержащего много вложенных циклов, когда выигрыш составил порядка 15-20 раз. Но это, скорее, исключение.

Тогда зачем им было писать это в описании?