@Kertis138

Здравствуйте!

Подскажите, каким образом можно упаковать некоторый алгоритм, чтобы сделать его через некоторое время.
Например, некоторое время накапливается контейнер (Queue например) с задачами, а затем некоторый TaskController последовательно выполняет их или же распараллеливает в несколько потоков.

Нашел варианты с std::future.
Насколько это быстрый вариант?

PS: Для опыта пытаюсь распараллелить самописный игровой движок и сделать это эффективно. Есть несколько систем (Рендерер, физическая система ...) и все они оперируют системными объектами (Универсальный объект является комбинацией всех системных объектов со всех систем. Что-то типа разложения объекта по осям ). Так вот получается, что системный объект - та самая минимальная единица. И обработку объектов можно распараллелить, введя понятие Задачи.
Скажите, имеет ли деление на такие задачи некоторых действия? Оптимально ли это?

0

@gray_fox

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

1

@Kertis138

Допустим, на 4 ядра будет 4 потока. И если задач больше 4, то контроллер просто подождет пока первые 4 задачи завершатся, а затем запустит следующую пачку.
Это будет оптимально?
В таком случае необходимо каждую пачку задач запускать в новых потоках? Или можно как нибудь сохранить старый, добавив туда новую задачу? Время создания нового потока занимает много времени, верно?

0

@gray_fox

Думаю, разные подсистемы вполне могут эффективно работать параллельно как конвейер: в качестве задачи подсистема может принимать набор объектов.
Краеугольный камень тут, как я вижу - минимизировать точки синхронизации между разными стадиями, иначе от "параллельности" будет мало толку. Так же надо учитывать latency конвеера (т.е. сколько занимает выполнение всех стадий).
Но я не сильно знаком с игровыми движками и подобным, так что это мнение "со стороны"

1

@Tree depth

Может будет полезным
https://archive.org/details/GDC2015Gyrling_201508
http://twvideo01.ubm-us.net/o1... aughty.pdf

2

@gray_fox

Ну threadpool по сути так и работает.
Как конкретно распределить выполнение задач разных подсистем по потокам я вам не скажу. Думаю, как минимум будет проблематично, если возможно, мигрировать вывод графики по разным потокам ОС.
Можно выделить по потоку на каждую подсистему (так проще, я думаю), выполнять несколько подсистем в одном потоке и т.д., тут уж как решите как лучше (и как вообще можно))

1

@Kertis138

Да, все системы уже работают параллельно, оперируя системными объектами. В то время как Универсальный Объект - контейнер всех системных объектов.

Вот! Тут та самая идея с очередью задач и контроллером этих задач.
Intel несколько лет назад описала похожую идею, откуда я взял довольно много интересных подходов.
Ссылка на статью
+ перевод

По Вашим статьям еще более совершенная оптимизация - они собирают Task-и не в одну очередь, а делят ее на несколько очередей по приоритету. Как они пишут - Job выполняется в рабочем потоке и Job может поставить в очередь другие Jobs. Это все отлично. Вот теперь бы разобраться, как представляется эта самая jobs кодом в с++
Если взять Лямбду, код которой меняет объект, то стоит вопрос удобства этого механизма.

Получается такой прототип:

Тогда такие Задачи я помещаю в очередь и собственно получается что-то рабочее.
Что думаете? Разумная реализация или есть другие варианты?

0

@gray_fox

Хм, т.е. решение уже есть и нужно его оптимизировать? Потому что, судя по 1-му посту, выглядит, как будто вы только подступаетесь к задаче. My bad
Ну я примерно подобное и предлагал, но раз вы уже в курсе...

1

@Kertis138

gray_fox, Сейчас у меня нет такого понятия как Задача. Параллельное выполнение в данный момент - это самое обычное foreach systems[i].Frame();. А после добавления Задач я могу вводить понятие - очереди задач, дробления задач на подзадачи в случае некоторых реализаций...

. Тут используется указатель на функцию - в принципе то, что нужно. Весьма полезная статья оказалась. Кроме того, там еще и Fibers и куча других вкусных плюшек
Очень интересно все это попробовать повторить.

0

@gray_fox

Ну саму задачу (как что-то атомарное, где-то исполняющееся) можно представить просто как ф-ю (std::function<void ()>, например, или как указатель на ф-ю, если нужно и т.д.), которая может делать что угодно, так что с этим уж проблем вроде быть не должно.

1

@Kertis138

Спасибо! Теперь с задачами разобрался. Появился вопрос, как разделять задачи по тактам?
Если брать статью, то там предлагают 2 варианта параллельного выполнения систем - свободный и жесткий пошаговый. В первом каждая система сама выбирает сколько ей нужно тактов до синхронизации, а во втором для каждой системы заранее отведенное время на работу. Я не совсем понял, что они имеют ввиду под тактом? Если считать, что такт - это время выполнения какой-то задачи для какой-то системы, то время здесь разное (зависит от задачи). Не знаете, что подразумевается под делением на такты? И каким образом система может выбирать, если ей тоже неизвестно время работы той или иной задачи?

Добавлено через 14 минут
Пока сделал следующий вывод (не знаю насколько он правдив):

Жестко пошаговый режим:
Что-то из разряда
То есть запускает все системы в поток и ждет их.

Свободный режим:
Здесь сложнее. Так же идет запуск всех систем в потоках. Далее, как пишут Intel, идет опрос систем: "Сколько тебе нужно тактов?". Каким образом это происходит - не очень понятно

0

@Tree depth

https://www.reddit.com/r/gamed... og_engine/

2