Комментарии 12
Следующий коммент написан для людей, которые только планируют открыть себе славный мир ECS.
Из-за таких статей создается ложное впечатление, что основной плюс ECS — производительность, но это совершенно не так. Выигрыш в производительности лишь приятное последствие этого архитектурного паттерна. ИМХО, основной его плюс — удобство работы с ним в рамках архитектуры проекта(ессесно, только когда начнешь им думать, а не пробовать), он решает те же проблемы, что и SOLID, но иным образом.
Из-за таких статей создается ложное впечатление, что основной плюс ECS — производительность, но это совершенно не так. Выигрыш в производительности лишь приятное последствие этого архитектурного паттерна. ИМХО, основной его плюс — удобство работы с ним в рамках архитектуры проекта(ессесно, только когда начнешь им думать, а не пробовать), он решает те же проблемы, что и SOLID, но иным образом.
Абсолютно согласен — производительность не есть основная причина для использования ECS. И если причина выбора этого подхода — архитектурное удобство — стоит смотреть в сторону сторонних фреймворков, ибо Юнитевский пока сыроват, и за счет работы со структурами — не шибко удобен.
Плюсую. Юнитеховский фреймворк пока далек от удобной разработки. Без ссылочных типов в компонентах очень больно работать, особенно в нынешнем рантайме Unity. А в будущем это добавит геморрою при использовании кастомных C#-либ.
Мне больше всего в работе зашел фреймворк от Leopotam, но тут на вкус и цвет. Лучше попробовать все, чем позже решить, что выбранный чем-то не устраивает.
Мне больше всего в работе зашел фреймворк от Leopotam, но тут на вкус и цвет. Лучше попробовать все, чем позже решить, что выбранный чем-то не устраивает.
Тоже его использую в домашних проектах, привет Leopotam ;)
IJobParallelForTransform используется не совсем как надо. Он работает по принципу Root per thread соответственно если перемещаемые объекты не раскиданы по нескольким рут трансформам они будут обновляться на одном worker thread, а значит никакого параллелизма тут не будет. Раскидай их на группы (например 50к разбей на 5 групп по 10к — просто вложи их в пустой GO вместо того чтобы они были в корне сцены) что увеличит текущие цифры в ~xКОЛИЧЕСТВО_РУТОВ раз.
А сами проверки производились в редакторе? Какая версия редактора была? (UPD: пропустил, оказывается есть в статье) Была ли включена настройка Editor Attaching? Были ли отключены проверки безопасности для нативных коллекций и вообще?
Я считаю что самый правильный способ сравнивать эти цифры, это делать сборку на целевую платформу, выключив все проверки и development build option, тогда вариант 3 станет эффективнее на порядки раз, судя по замерам моей команды. Хотя мы не с Actors, а с Entities тестируем.
Забавно, но мы столкнулись с другой проблемой, хоть вариант 3 самый эффективный, в редакторе на большом проекте работать все равно нормально невозможно так как всё тормозит. А галочка Editor Attaching работает только с перезапуском редактора, что неудобно, дебагер нужно подключать всегда не вовремя.
Я считаю что самый правильный способ сравнивать эти цифры, это делать сборку на целевую платформу, выключив все проверки и development build option, тогда вариант 3 станет эффективнее на порядки раз, судя по замерам моей команды. Хотя мы не с Actors, а с Entities тестируем.
Забавно, но мы столкнулись с другой проблемой, хоть вариант 3 самый эффективный, в редакторе на большом проекте работать все равно нормально невозможно так как всё тормозит. А галочка Editor Attaching работает только с перезапуском редактора, что неудобно, дебагер нужно подключать всегда не вовремя.
В профайлере можно увидеть как по воркер тредам делится если не в корне сцены и как запускается на одном треде если все трансформы в руте сцены. (скрины с редактора с оверхедом Safety\Collections Checks, просто чтобы показать порядок разницы)
50k 5 рутов
50k 1 рут
50k 5 рутов
50k 1 рут
Спасибо за комментарии. Делал для себя и был сильно удивлен и разочарован производительностью Jobs.
Соберу дополнительную информацию и вероятно будет перетест отдельно третьего пункта с учетом замечаний.
Соберу дополнительную информацию и вероятно будет перетест отдельно третьего пункта с учетом замечаний.
Здесь проблема не самих джобов и бёрста скорее, а сама синхронизация MonoBehaviour трансформов + оверхед самих трансформов как таковых. В pure DOTS нет такой проблемы и вся работа с позицией\вращением на несколько порядков быстрее. Чтобы это работало производительно то и Data Layout должен быть производительным (==линейным, с минимумом cache misses) :) Тогда и раскрывается вся мощность Job System и Burst.
Статья очень понравилась.(написал в комменте, так как не могу плюсовать)
А какая разница в производительности на моб. устройствах?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Unity, ECS, Actors: как поднять FPS в своей игре в десять раз, когда оптимизировать уже нечего [с правками]