Упаковка задачи

@Kertis138 · Регистрация: 25.02.2016

Студворк — интернет-сервис помощи студентам

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

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

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

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

). Так вот получается, что системный объект - та самая минимальная единица. И обработку объектов можно распараллелить, введя понятие Задачи.
Скажите, имеет ли деление на такие задачи некоторых действия? Оптимально ли это?

@gray_fox · 10.08.2017, 23:18

Сообщение от Kertis138

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

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

@Kertis138 · 10.08.2017, 23:39 **[ТС]**

Сообщение от gray_fox

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

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

@gray_fox · 10.08.2017, 23:41

Сообщение от Kertis138

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

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

@Tree depth · 10.08.2017, 23:51

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

@gray_fox · 10.08.2017, 23:53

Сообщение от Kertis138

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

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

@Kertis138 · 11.08.2017, 00:50 **[ТС]**

Сообщение от gray_fox

Думаю, разные подсистемы вполне могут эффективно работать параллельно как конвейер

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

Сообщение от Tree depth

http://twvideo01.ubm-us.net/o1/vault...he_Naughty.pdf

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

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

Если взять Лямбду, код которой меняет объект, то стоит вопрос удобства этого механизма.

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
template<typename Base>
class Task 
{
public:
   Task(Base *object, std::function<Base*> func) 
      : p_object(object), 
        p_func(func)
   {}
 
   void run() 
   {
        p_func(p_object); 
   }
  
private:
   Base *p_object;
   std::function<Base*> p_func;
};

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

@gray_fox · 11.08.2017, 01:20

Сообщение от Kertis138

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

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

Сообщение от Kertis138

Intel несколько лет назад описала похожую идею, откуда я взял довольно много интересных подходов.

Ну я примерно подобное и предлагал, но раз вы уже в курсе...

@Kertis138 · 11.08.2017, 01:38 **[ТС]**

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

.

Сообщение от Tree depth

http://twvideo01.ubm-us.net/o1/vault...he_Naughty.pdf

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

Очень интересно все это попробовать повторить.

@gray_fox · 11.08.2017, 02:11

Сообщение от Kertis138

gray_fox, Сейчас у меня нет такого понятия как Задача.

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

@Kertis138 · 11.08.2017, 02:46 **[ТС]**

Сообщение от gray_fox

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

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

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

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

C++
1
2
3
4
5
6
7
thread system[0]
...
thread system[N]
 
join system[0]
...
join system[N]

То есть запускает все системы в поток и ждет их.

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

@Tree depth · 11.08.2017, 03:10

Сообщение от Kertis138

Вот теперь бы разобраться, как представляется эта самая jobs кодом в с++

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

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@Kertis138 6 / 6 / 1 Регистрация: 25.02.2016 Сообщений: 342

	Упаковка задачи 10.08.2017, 23:00. Показов 1543. Ответов 11 Метки нет (Все метки) Здравствуйте! Подскажите, каким образом можно упаковать некоторый алгоритм, чтобы сделать его через некоторое время. Например, некоторое время накапливается контейнер (Queue например) с задачами, а затем некоторый TaskController последовательно выполняет их или же распараллеливает в несколько потоков. Нашел варианты с std::future. Насколько это быстрый вариант? PS: Для опыта пытаюсь распараллелить самописный игровой движок и сделать это эффективно. Есть несколько систем (Рендерер, физическая система ...) и все они оперируют системными объектами (Универсальный объект является комбинацией всех системных объектов со всех систем. Что-то типа разложения объекта по осям ). Так вот получается, что системный объект - та самая минимальная единица. И обработку объектов можно распараллелить, введя понятие Задачи. Скажите, имеет ли деление на такие задачи некоторых действия? Оптимально ли это? 0

@Tree depth Заблокирован
	10.08.2017, 23:51
	Может будет полезным https://archive.org/details/GDC2015Gyrling_201508 http://twvideo01.ubm-us.net/o1... aughty.pdf 2