-
Notifications
You must be signed in to change notification settings - Fork 4
Myriad.ecs #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Myriad.ecs #4
Conversation
|
hi, thx for PR.
I leave this decision up to you. For now I will add a footnote. Somtehing like
Make sense. We can add
I dont't want split Add & Remove component. Two reasons in this case and in general:
Okay - why not. But doing this was not my original intention. As Doraku's bechmarks already focus large data sets. |
|
Will update the benchmark results on Tuesday. |
|
Thanks for the fast turnaround!
In that case I'll leave it as-is until there are more
Those are good points, I don't think keeping them together will obscure the results very much and more benchmarks is always a problem for projects like this! |
Just implemented the following benchmarks for Myriad
While simplifying benchmarks I got an overall view of all benchamrks. I also added a note to Benchmark constrains in the readme.
|
|
Fair enough. Personally I would split out the tests into buffered and non-buffered groups, so there's a more direct comparison. I know there's always a desire to keep the number of benchmarks minimal in projects like though, so I understand if you'd rather not do that! Aside from buffered, I do think there's an issue in the way the entity creation benchmark is setup at the moment which could easily be fixed. Many of the frameworks create an entity directly in an archetype (e.g. Friflo, Arch). Presumably just giving those new entities the With the current setup you could get a really fantastic benchmark score by locating the correct archetype (during setup, so that's free) and then the actual benchmark would just bump the entity count by 100! Not very useful though 😆 In my opinion it would be better to specify values that all of those components have to have. Since every component contains an As a brief explanation of why Myriad doesn't generally support non-buffered operations. I used to use Arch as my ECS, if you use non-buffered operations during a query it can work but it's very risky and might break the query or corrupt the entire world state. It's a frequent issue that comes up on the Arch Discord. When implementing Myriad I decided to just sidestep the entire issue by not supporting non-buffered operations. |
… in applications. Follow up of feedback in #4 (comment) Before components had default values.
|
thx for your response. Bulk create entitiesI agree created entities must be created with individual component values. Btw: fennecs also support bulk creation.
In case of friflo components are defaulted. For Arch I don't know. I guess I will add a non bulk create entities. Use required command buffer in Basic benchmarksThe Basics benchmarks I don't want to change. Without these benchmarks / operations a world will always be empty. |
The Myriad one there executes the buffer twice (once in the |
Added basic support for
Myriad.ECS.There are a couple of issues here I want to raise:
Myriad doesn't support adding/removing components or creating/deleting entities without using a
CommandBuffer. Right now I haven't implemented those benchmarks (especially since there's a separate category forCommandBufferbased operations). Do you think I should implement them, using aCommandBuffer?Alternatively, we could expand the category of
CommandBufferoperations to cover all these things - right now there's just one benchmark that does adding and removing components with a buffer, which feels a bit weird. This could be expanded into:Another thing, this isn't an issue with Myriad specifically, is that the entity counts seem very small. For example the query benchmarks (
QueryT1,QueryT5,QueryFragmentedT1) all operate over just 100 entities. Can I suggest parameterising this and running it at e.g. 100 and 10,000 entities? That way we can see better how the different options scale.