Я закладываю основу для того, что может стать игрой сверху вниз, которая обрабатывает 3D-поиск пути.Независимо от контекста, проблема заключается в распараллеливании запросов на поиск путей потенциально десятков или сотен агентов в одном кадре. Вот видео для справки .
Каждый запрос асинхронного поиска пути включает в себя следующие аргументы: координаты отправления и назначения, возможности перемещения агента (может ли он ходить, летать, плавать и т. Д.)размеры карты и, что наиболее важно, сама карта поиска пути.Некоторое время назад я извлек из исходной трехмерной сетки данные, которые будут запрашиваться в запросе поиска пути.Однако, когда я распараллелил его с библиотекой dask, он предупредил меня, что карта нахождения пути весила около 8,5 МБ, и что я должен ее разбросать.Таким образом, тот же экземпляр также будет использоваться для следующих запросов поиска пути в том же кадре.Поэтому я реализовал его с помощью следующего кода:
if 'pathfindingMap' not in self.__bigArgumentsToParallelize:
self.__bigArgumentsToParallelize['pathfindingMap'] = self.__client.scatter(taskData['pathfindingMap'])
taskData['pathfindingMap'] = self.__bigArgumentsToParallelize['pathfindingMap']
future = self.__client.submit(wrapCreatedPath, taskData)
routeRelatedLogic.setPathfindingRequest(FutureWrapper(future))
Однако разброс данных полностью замораживает цикл на несколько секунд.Я предположил, что это можно сделать в фоновом режиме.Если да, есть ли метод dask, который решит эту проблему?
Альтернативой, которую я попробовал, было принятие того факта, что я не смогу отправлять запросы на поиск пути другим процессам без лишних затрат на зависание игры.Таким образом, я инициализировал клиент dask с помощью Client (process = False), который теоретически использовал бы общую память основного процесса для выполнения запросов.Однако та же проблема с накладными расходами сохраняется при разбрасывании карты нахождения пути, и если я не рассею ее, мне придется подождать, пока накладные расходы будут выбраны один раз, но умножены примерно на дюжину агентов.
Единственное другое решение, которое я рассмотрел, - это просто принять накладные расходы на все вопросы многопоточности / обработки и каким-то образом сохранить будущее карты нахождения пути при ее создании, поэтому разброс ее для многопроцессорной обработки станет частью генерации карты.Тем не менее, это звучит совершенно необоснованно, учитывая, что карта изменится в будущем (со зданиями и т. Д.).
Любая помощь?