LINUX.ORG.RU

Библиотека/фреймворк для параллелизации задач

 


0

2

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

RGBImage img1;
RGBImage img2;
BWImage bw1;
BWImage bw2;
Camera cam1(1, img1); //вход - камера#1, выход картинка1
Camera cam2(2, img2); //вход - камера#2, выход картинка2
RGB2BW rgb2bw1(img1, bw1); //вход - картинка#1, выход ч/б#1
RGB2BW rgb2bw2(img2, bw2); // ...

OutType1 out1;
OutType2 out2;

Processor proc(bw1, bw2, out1, out2, [] (BWImage& bw1, BWImage& bw2, OutType1& o1, OutType2& o2) {
        // здесь происходит некая обработка bw1 и bw2, с записью результата в о1 и о2
        });

Viewer view(out1, out2);
run(cam1, cam2, rgb2bw1, rgb2bw2, proc, view);

И чтобы оно автоматически понимало зависимости выходных данных от входных и пускало соответствующие процедуры обработки на параллельных процессах? В моем примере это простой fork-join, но в общем случае граф может быть более сложным, например, результаты out1 могут подаваться в качестве обратной связи в cam1, чтобы соответствующая камера адаптировала свои внутренние параметры. При этом должен быть минимальный оверхед, т.е. никаких лишних копирований данных.

Или каждый раз писать велосипед?

★★★★★

Последнее исправление: seiken (всего исправлений: 2)
Ответ на: комментарий от cobold

смысл в том, чтобы не отвлекаться на низкоуровневые api параллелизации, синхронизации и проч, а сконцентрироваться на процедурах обработки данных. Либа предоставляла бы примитивы, типа, «процессор» с N входами и M выходами (например, камера в моем случае это процессор с одним входом и одним выходом), и всю работу по параллелизации выполняла либа.

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

seiken ★★★★★
() автор топика
Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от eao197

как доеду до дома, гляну. Спасибо

seiken ★★★★★
() автор топика
Ответ на: комментарий от seiken

не «процессор», а тред, ну или «воркер» в рамках одного процесса - задачи.

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

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

либ для этого миллионы, но у меня, как и подобает настоящему шизику, - своя.

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

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

по сути надо 3-4 «обьекта» всего в такой либе. тред, очередь, рекурсивный мьютекс. все это пишется на стандартных классах плюсов. потому и своя либа и ей тыща лет.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)

И чтобы оно автоматически понимало зависимости выходных данных от входных и пускало соответствующие процедуры обработки на параллельных процессах?

Такое есть в sycl. Будет автоматическая синхронизация. Как бонус сможешь запустить на gpu или ЦП на выбор. Код - обычный c++ (читай: НЕ opencl или cuda).

ox55ff ★★★★★
()
Ответ на: комментарий от alysnix

в моём случае вся обработка кадра происходит между получением двух соседних кадров, и очередь не нужна. Кадры идут с константной частотой и обработка а ля реалтайм.

seiken ★★★★★
() автор топика
Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от seiken

в моём случае вся обработка кадра происходит между получением двух соседних кадров.

значит очередь будет пустой и как только ты положишь туда данные, воркер из заберет. никаких лишних накладных расходов тут не будет.

alysnix ★★★
()

std::future? Ну или OpenMP

XMs ★★★★★
()

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

Norgat ★★★★★
()
Ответ на: комментарий от seiken

Если threads для вас это низкоуровнево, то смотрите в сторону python-а, обернув в него вычислительно-сложную часть на сяхплюсплюс

tvldslv
()
Ответ на: комментарий от seiken

см. Библиотека/фреймворк для параллелизации задач (комментарий)

вот точно надо обмазываться плюсами. А потом вот так отвечать, ага-ага.

Oldboy
()
Ответ на: комментарий от Norgat

Слово пайплайн не существует. Слово оверхед не существует. А вместо «товарищ» было бы логично написать «мистер ор миска».

Partisan ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.