Задачка на производительность

[once_again_abc]

есть некий генератор массивного потока данных (примерно 8МБ/сек.).
программа считывает эти данные из сети. необходимо сделать следующее:

1. записать _все_ полученные данные (с несложной предварительной обработкой) на диск;
2. обработать актуальные данные несколькими разными способами для разного графического представления в реальном времени (т.е. пришли данные - фильтры - отображение актуальной информации и т.д.).

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

понятно, что графики в реальном времени целостность всех данных не важна - что успеваем то и отображаем, если скажем накопилась значительная задержка (например пол секунды или 100 миллисекунд) - сбрасываем буфера и берем самые свежие данные - полученные только что.
для файла же наоборот, важна запись именно всех данных, без потерь.

[Bepec]

Вопрос многопоточности стоит? Или у вас всё будет однопоточно?

По идее задачка интересная, только нет моментов - какие фильтры, какие данные, какая обработка. (я и при 115200 скорости могу на пять минут обработку сделать )

[Igors]

По-моему здесь простейшая схема: одна нитка читает и помещает новые задачи в контейнер. N др ниток извлекают задачи из контейнера. Помещение/извлечение защищены локом - вся любовь

[once_again_abc]

Вопрос многопоточности стоит? Или у вас всё будет однопоточно?

По идее задачка интересная, только нет моментов - какие фильтры, какие данные, какая обработка. (я и при 115200 скорости могу на пять минут обработку сделать )

ничего особенного. спектральный анализ на FFT, усреднение, простые алгебраические операции над массивом float. т.е. не на 5 минут =) ну может быть миллисекунд 50 на 4х ядерном в несколько потоков. вообще я думаю это неважно для данной задачи... 50 мс. или 5 минут.

[once_again_abc]

По-моему здесь простейшая схема: одна нитка читает и помещает новые задачи в контейнер. N др ниток извлекают задачи из контейнера. Помещение/извлечение защищены локом - вся любовь

что имеется ввиду под задачами и контейнером?

[Bepec]

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

[once_again_abc]

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

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

[Bepec]

Эммм... Чистить - это и есть сброс в файл/поток обработки/память/другой контейнер.
И потребитель данных - один. Это поток обработки.

Можно вообще пойти по пути упрощения - обновлять информацию на графике раз в 200-300 мс. Человеческий глаз не заметит разницы, зато в разы уменьшается время на обработку и прочая.

[once_again_abc]

Эммм... Чистить - это и есть сброс в файл/поток обработки/память/другой контейнер.
И потребитель данных - один. Это поток обработки.

Можно вообще пойти по пути упрощения - обновлять информацию на графике раз в 200-300 мс. Человеческий глаз не заметит разницы, зато в разы уменьшается время на обработку и прочая.

данные идут неприрывно со скоростью 8 МБ/сек. что делать с данными, которые пришли во время сброса заполненного буфера в файл? копировать в другой буфер? тогда это и есть кусочный кольцевой буфер...

оффтоп: 200-300 мс. на графике очень хорошо заметно по дерганьям картинки =) идеально для меня 20 мс. есть к чему стремиться =)

[Bepec]

Сбрасывать можно спокойно и в отдельном потоке А то, что пришло в тот момент опять таки будет попадать в буфер.
Долго можно филосовствовать. С таким подходом вам нужно 3-4 буфера.
1 - приём
2 - данные на обработку
3 - данные для сброса в файл
4 - ?

[once_again_abc]

Сбрасывать можно спокойно и в отдельном потоке А то, что пришло в тот момент опять таки будет попадать в буфер.
Долго можно филосовствовать. С таким подходом вам нужно 3-4 буфера.
1 - приём
2 - данные на обработку
3 - данные для сброса в файл
4 - ?

4. Профит!!!!111

 

буду експерементировать.

[Akon]

Единый кольцевой буфер на всех потребителей. Голова для всех потребителей одна, хвост у каждого свой. Ячейка в буфере помечается свободной, когда обработана всеми потребителями. Размер буфера выбирается исходя из того, чтобы не допустить потерю записи в файл. Отрисовка данных может быть реальным тормозом, поскольку выполняется из GUI потока, поэтому необходимая порция самых свежих данных копируется из буфера.

[Igors]

FFT (да и практически любая обработка) требует фиксированного кол-ва точек сигнала. Поэтому возникает единица (chunk) данных. Читающий должен прочитать N измерений в буфер. Когда все N прочитаны этот буфер помещается в контейнер буферов. А с контейнером уже как хотите так и крутите - сливаете в файл, рисуете, пропускаете куски и.т.п.

[Akon]

У разных потребителей разные чанки.

[Igors]

У разных потребителей разные чанки.

Входные - одни и те же. А как потребитель их использует (или во что конвертирует) = его личное дело