ECS Worlds overhead

[knotty brook]

Do Worlds have a lot of overhead? are 500 or 1000 worlds to much for a match based game server?

[zinc hawk]

Hey Elfhild! The answer is: It depends.

There will be overheads, but an overhead doesn't imply a bottleneck. The best thing you can do is to create a prototype and profile a dedicated server build on your target hardware.

Presumably you want to throw 1k worlds into a single process to reduce server costs? That is absolutely viable. "Unity Transport Package" supports multiple drivers, and we've heard from users that "Netcode for Entities" can support multiple independent worlds.

You may need to use a custom matchmaker or orchestration approach, but that's doable too.

I've personally never tried that scale of Worlds, but I've tried a couple hundred (for thin client testing) and it seems to work. I'd be interested to see how far you can push it.

[white forum]

@crimson bane have you ever tested this concept out with character controller? I'm testing it now, and i think theres a fairly significant overhead when adding in the physics systems to the new worlds. Will test in a build as well but locally its pretty heavy

[crimson bane]

Can't say I have tested a large amount of worlds either. Some overhead is natural though, because let's say a typical world has 50 jobs running, with 1000 worlds that gives us 50000 jobs to schedule every frame. That amount of jobs will definitely have a noticeable overhead, just for the scheduling cost alone

[onyx drift]

Honestly if this is your goal feels like you should not bother scheduling and just run 1 world per thread and run all your work

I haven't tested since 0.17 but worlds in own thread worked fine back then if you replace the call to unity engine time and didn't schedule work

I believe elfhild doesn't use netcode and instead runs his own network solution

If you did this you could also turn on simple dependency management, which I believe still works, and remove all dependency overhead as well

[knotty brook]

How do i run one world per thread? everything on a single job?

[onyx drift]

I wouldn't really recommend this and as I said I haven't tested a couple of years but

Basically just create a thread, create a world in it and just manually call update on it

What I would personally do is create 1 server per process

If you knew you were thing this only ever with multiple processes I'd compile with simple dependency and disable workers

If you wanted option for users to self host 1 process per machine I'd leave dependency management on

So they can still use workers properly

(sorry if this isn't clear, typing this on a phone while navigating the city)

[knotty brook]

This is clear yeah. If i can disable workers it looks fine

[onyx drift]

I can't remember what it is off top of head but there is command line to disable workers in build

Seperate processes going to have their own overhead

So it's probably just something you'll need to test

Headless unity instances are ok though

[knotty brook]

Yeah but the overhead is fine in linux (not much more than a thread).

Thank you

[knotty brook]

But it is hard to beliable jobs have more overhead than a process. Need to benchmark

[onyx drift]

it's not about the overhead of the job system

IF you have 1 worker and 1 main vs just running it on all main thread

It will not be 2x faster with the 1 worker

Even well paralleled work will often total computation over 3+1 threads will only be about twice as fast as just running it on the main thread

4 separate processes with no workers on 4 cores is going to be better throughput than 4 processes each with 3 worker threads which are trying to contend with themselves but also each other

[knotty brook]

managing processes is a thing id like to avoid (even with docker) but it can be worth it

And it can scale to multiple machines too

This is a thing pure ecs can`t

[knotty brook]

is using multiple physics worlds but a single world fine? not many jobs but separate collision detection

[white forum]

everything is basically just running on the main thread. each world is running as fast as expected but ofc when you get 100s of them it'll get really slow

since many of the systems in the simulation group have to run on the main thread, it really does seem like tertles recommendation here seems to be the way to go