Ну как по мне это все очень классно в теории и синтетических расчетов позиций или примитивной математики для большого кол сущностей, на практике же мне даже не приходят в голову кейсы под такое, если у вас куча систем по одним и тем же данным то что-то тут не так. А что касается SIMD то опять же, подходит только для малого количества кейсов, в реальных системах будет куча логики, ветвлений и прочего, для конкретных оптимизаций конечно спору нет, но в разрезе архитектуры самого ядра ECS опять же не понятно. Ну разве что симуляцию частиц делать или подобные технодемки, но там проще на GPU переключиться опять же) Если у вас есть какие то примеры реального повсеместного применения, то поделитесь, будет интересно.
Как раз корректно сравнивать одинаковые по логике кейсы и выполнение систем, а не синтетику на миллионы сущностей с SIMD обработкой, которой в реальном проекте не будет в 99 процентов кейсов.
Я согласен касательно архетипов, мне тоже они видятся очень ограниченными за счет постоянных миграций и менеджмента. Не смотря на то что существуют вариации где не происходит копирование данных компонент, а только перебросы индексов. И мне нравится что вы ищите альтернативные решения. Явное указание это неплохо.
Но как в случае итерации по [B|F|M] при существовании секторов [A | B | C], [D | F | G] и отдельного [ M ] будет происходить отбор сущностей? Идентификатор сущности напрямую указывает на элемент компонента в чанке или имеет промежуточный маппинг (Sparse?).
Я все еще не понимаю как это помогает при расширении проекта: например популярный запрос Position + Velocity помещен в сектор, но таких "популярных" комбинаций может быть не 1 и даже не 10. Например вы добавили новый модуль с 3 новыми компонентами, и систему которой требуется Position и "Новый компонент". Получается в этом случае не получить бонуса от секторов потому что сектора просто не будет и будет замедление за счет участия сектора и обычного хранилища?
Правильно я понимаю что тем самым вы заставляете пользователя заранее размечать сектора, а это значит что модульность страдает, так как чтобы определить сектор нужно заранее знать все типы компонентов которые в него должны войти? И как по вашему это не превратится в ад менеджмента в большом проекте использующем разные фичи\модули и тысячи разных типов компонентов?
И что будет когда например у вас сектор [A | B | C] и сектор [D | F | G] и вам потребуется проитерировать все сущности с компонентами [B | F ] ? Кажется что стандартный Soa подход где каждый тип компонента в своем векторе в данном кейсе будет быстрей?
Могу я спросить, что вы нашли "ненормального" в данной статье? Хотелось бы услышать конкретику в ответ от человека (а не LLM текст), который полностью прочел статью, а не только заголовки.
Да доступно в любом движке с поддержкой .NET, просто установите из Nuget или скачайте с Github.
Ну как по мне это все очень классно в теории и синтетических расчетов позиций или примитивной математики для большого кол сущностей, на практике же мне даже не приходят в голову кейсы под такое, если у вас куча систем по одним и тем же данным то что-то тут не так. А что касается SIMD то опять же, подходит только для малого количества кейсов, в реальных системах будет куча логики, ветвлений и прочего, для конкретных оптимизаций конечно спору нет, но в разрезе архитектуры самого ядра ECS опять же не понятно. Ну разве что симуляцию частиц делать или подобные технодемки, но там проще на GPU переключиться опять же) Если у вас есть какие то примеры реального повсеместного применения, то поделитесь, будет интересно.
Как раз корректно сравнивать одинаковые по логике кейсы и выполнение систем, а не синтетику на миллионы сущностей с SIMD обработкой, которой в реальном проекте не будет в 99 процентов кейсов.
Я согласен касательно архетипов, мне тоже они видятся очень ограниченными за счет постоянных миграций и менеджмента. Не смотря на то что существуют вариации где не происходит копирование данных компонент, а только перебросы индексов. И мне нравится что вы ищите альтернативные решения. Явное указание это неплохо.
Но как в случае итерации по [B|F|M] при существовании секторов [A | B | C], [D | F | G] и отдельного [ M ] будет происходить отбор сущностей? Идентификатор сущности напрямую указывает на элемент компонента в чанке или имеет промежуточный маппинг (Sparse?).
Я все еще не понимаю как это помогает при расширении проекта: например популярный запрос Position + Velocity помещен в сектор, но таких "популярных" комбинаций может быть не 1 и даже не 10. Например вы добавили новый модуль с 3 новыми компонентами, и систему которой требуется Position и "Новый компонент". Получается в этом случае не получить бонуса от секторов потому что сектора просто не будет и будет замедление за счет участия сектора и обычного хранилища?
Правильно я понимаю что тем самым вы заставляете пользователя заранее размечать сектора, а это значит что модульность страдает, так как чтобы определить сектор нужно заранее знать все типы компонентов которые в него должны войти? И как по вашему это не превратится в ад менеджмента в большом проекте использующем разные фичи\модули и тысячи разных типов компонентов?
И что будет когда например у вас сектор [A | B | C] и сектор [D | F | G] и вам потребуется проитерировать все сущности с компонентами [B | F ] ? Кажется что стандартный Soa подход где каждый тип компонента в своем векторе в данном кейсе будет быстрей?
Мы не о чем не спорим, здесь нет места спору вообще.
Прочитайте свою же ссылку еще разок и подумайте, и не вводите людей в заблуждение.
Вам в последней ссылке белым по черному написано:
https://learn.microsoft.com/en-us/dotnet/standard/clr
https://learn.microsoft.com/en-us/dotnet/api/system.missingmethodexception?view=net-9.0
https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/jit/ryujit-overview.md#execution-environment-and-external-interface
Могу я спросить, что вы нашли "ненормального" в данной статье? Хотелось бы услышать конкретику в ответ от человека (а не LLM текст), который полностью прочел статью, а не только заголовки.