obust
MModular
•Created by samufi on 1/9/2025 in #community-showcase
Larecs: a performance-centred archetype-based ECS
I suppose the ECS components could be stored as SoA as well.
I can see an argument for queries to prefer acting on AoS, but the systems likely would be more efficient on SoA so you can do SIMD.
16 replies
MModular
•Created by samufi on 1/9/2025 in #community-showcase
Larecs: a performance-centred archetype-based ECS
Right. So you can store all your components in:
- an Array of Structs: [{x: 0.0, y: 1.0}, {x: 2.0, y: 3.0}]
- a Struct of Arrays: {x: [0.0, 2.0], y: [1.0, 3.0]}
If your batch query returns a SoA then
16 replies
MModular
•Created by samufi on 1/9/2025 in #community-showcase
Larecs: a performance-centred archetype-based ECS
as long as all
z are the same size then you can pack them into an array.
SoA means you have 1 struct with as many arrays as you have struct fields.16 replies
MModular
•Created by samufi on 1/9/2025 in #community-showcase
Larecs: a performance-centred archetype-based ECS
Do you have toy example of a component with components of different sizes ?
16 replies
MModular
•Created by samufi on 1/9/2025 in #community-showcase
Larecs: a performance-centred archetype-based ECS
I am guessing that SIMD becomes relevant when you work with multiple entities (batches).
Then batch queries return struct of arrays (SoA) on which you can do vectorized operations.
Pushing this to the limit you can make all queries batch queries and always work with SoA. Then everything is a vector and there is only one paradigm.
That is pretty much what mojo does with its scalars. Where
Int16 is just an alias for SIMD[int16, 1]
https://docs.modular.com/mojo/stdlib/builtin/simd/16 replies