You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 27, 2022. It is now read-only.
"Simple Insert" seems to test a scenario that is very rare outside of benchmarks, and yet can uniquely optimized for in a benchmark.
How often will anyone initialize 10,000 entities with exactly the same data? It seems far more common to initialize entities with slight variations. This benchmark favors ECS libraries that implement a specific function: "initialize the exact same thing a ton of times", and the benchmark will encourage other ECS libraries to do the same.
A more useful benchmark might be to add 10,000 entities with the position incremented by 1 for each entity. This would test something closer to real world scenarios, and not encourage a unique (but mostly useful for benchmarks) fast path.
The text was updated successfully, but these errors were encountered:
In addition to the above, we should also standardize on the source data layout. Currently, legion has data already in column-major layout, while every other ECS starts with row-major data, which is more work to transpose.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
"Simple Insert" seems to test a scenario that is very rare outside of benchmarks, and yet can uniquely optimized for in a benchmark.
How often will anyone initialize 10,000 entities with exactly the same data? It seems far more common to initialize entities with slight variations. This benchmark favors ECS libraries that implement a specific function: "initialize the exact same thing a ton of times", and the benchmark will encourage other ECS libraries to do the same.
A more useful benchmark might be to add 10,000 entities with the position incremented by 1 for each entity. This would test something closer to real world scenarios, and not encourage a unique (but mostly useful for benchmarks) fast path.
The text was updated successfully, but these errors were encountered: