How can I achieve higher entity counts?

[AmbulantRex]

The Question(s)

As the title says, I would like higher entity counts in the 10s and 100s of thousands. What is the best way to do that in Stride? Is there a known ceiling?

What should be possible

The following videos show two scenarios where I've attempted to stress the limits of .NET and Silk.NET's OpenGL native wrapper using a very basic ECS engine of my own. I saw very high entity counts with minimal burden on the GPU (RTX 3060 - 6GB) or CPU (i9 12900 @ 2.9 GHZ) with 10-20% and 0.5% utilization respectively. However, I can't explain the relatively low framerate despite barely taxing my resources.

The implementation is a somewhat naive, custom ECS pattern using .NET 7 and an approach similar to how EntityProcessor works in Stride. I also created an actor-based job system using Akka.NET and the memory apis. It heavily relied on model instancing (hence only cubes). This primarily served as an un-optimized POC so the below numbers should not be construed as a ceiling. Without my actor-based job system, I could only achieve a couple thousand entities. Although, due to the similarities in the technology choices, it would seem that comparable high entity counts should be achievable in Stride (possibly leveraging the Dataflow TPL stuff?).

I should note that entity counts as high as 25,000 comfortably achieved 60 FPS, I aimed the counts higher to compare performance to boid examples using Unity's ECS patterns. Those typically hit 20-30 FPS with ~100,000 entities.

Orbitals - (100k entities @ ~10-20 FPS)

The orbital example performs state calculations against orbital elements (not N-Body).

orbits.mp4

Boids - (100k entities @ ~10-20 FPS)

The boids example uses an octree BST and boid separation, cohesion, and alignment calculations in a simplified N-body example.

boids.mp4

[IXLLEGACYIXL]

https://www.youtube.com/watch?v=ZXA6VOcz6Y4
Doprez achieved 10k entities with their own navigation

1. Batch your stuff together, dont let each entity update on its own
2. use GPU instancing
   as a barebones guideline

one of the main problems are the draw calls from the processor to the GPU

[BenjaBobs]

If it is to run locally, I suggest maybe looking into more hardcore ECS with optimized data layout, such as https://github.com/genaray/Arch.
You can use a single script on to trigger all the relevant methods.

[tebjan]

You need to use instancing, there are 3 ways to do that in Stride:
#741 (comment)
https://github.com/tebjan/StrideTransformationInstancing

Also have a look at the Svelto source code examples:
https://github.com/Doprez/Awesome-Stride#ecs-examples

It does exactly what you are trying to do...

[AmbulantRex]

Awesome! Thank you. My goal now is to try and recreate what I've done in Stride and do some in-depth benchmarking. The other answers were good too, but focused more on external libraries.

As far as ECS goes, I know stride has the EntityProcessor concept. I think it is a sufficient stand-in, but many would balk at that due to lack of memory layout considerations. Since all components are going to be reference types, mapping blittable types and structs for passing to a job system was likely always going to be required. This has seemingly produced GC pressure in my simple example, but I'll need to get more specific measurements to confirm.

What I was really hoping for was an existing job system that could facilitate this. It may be achievable using the existing events system since these are coarse grained actor-based flows and de-qeueing events may be sufficiently controlled as a sort of "inbox" for parallel workers. I'll experiment further, but a general solution provided by the engine could be nice here.

[manio143]

If GPU and CPU load is minimal then it's most likely IO pressure and since I doubt you're working the disc, it means memory based operations are at fault. This could be down to CPU operations waiting on memory to be available or GPU waiting on memory transfer between RAM and VRAM.
In my understanding the second one is very costly if not batched properly and Stride doesn't do much for you here out of the box. But it potentially could. Phr00t mentioned once that for his fork he implemented some basic batching and thus even without full instancing (which is even more efficient because it removes the need to copy the same model many times) he was achieving higher framerates.

[manio143]

Would be good to see how this article translates for Stride
https://unity.com/how-to/gpu-optimization

[AmbulantRex]

GC pressure is highly possible in my case as well. I'm constructing a fresh batch of structs to pass down for processing every single frame. I use the memory APIs and pass by ref inside of parallel processes, but this is a major thumb on the scale I'm sure. However, without copying data with blittable types and structs, I run a very serious risk of shared resource problems when components are used in other entity processors.

That article was a good read! How much of that do you think Stride already has?