141–150 of 166 posts
Earlier quoted context omitted.
But each has to do a lot of stuff. People on such big servers build farms with hundreds of mobs dropping thousands of items which then go through redstone sorting systems.
The kind of mental gymnastics that people do here to justify needing 8 GB of RAM with a turnover of 3 GB per ~minute~ second to handle 1000 users.
I know this isn't the point of Folia's test, but: > During the period when 1,000 players were online, we reached a maximum of ~7.9GB/s heap allocation and our GC was hovering around 2-3GB/s when averaged over a minute. As someone who dealt with soft-realtime telephony stuff, this makes me want to scream in horror. It seems like the platform really hurts the performance here. In an average second with that many player…
Has anyone already tried to use GraalVM with it? Cool would be trying to do a native compilation and compare the performance
Earlier quoted context omitted.
> Each player loads in a lot of living entities (monsters/animals/...) and block entities (furnaces, redstone, ...) that all need to update. Sure, but that list of entities in the area is close to static (apart from crazy redstone magic). One would expect them to be pooled and not have many allocations for each tick.
But each has to do a lot of stuff. People on such big servers build farms with hundreds of mobs dropping thousands of items which then go through redstone sorting systems.
Earlier quoted context omitted.
Ultima Online is sharded. Biggest shard is ATL, with maybe 150 players.[1] Planetside 2 got up to 2000 or so, and may hold the record for a seamless land world MMO. [1] https://www.reddit.com/r/ultimaonline/comments/tr1r6j/uo_atl...
Planetside 2 has them on on huge map, but as soon as more player are nearer in one area the system got problems too. Lags, Jumps and wrong running clocks (different speeds an the map). They shard within a server. But PS2 Networking is really good and optimized, better as most current games, and Planetside 1 + 2 (and parts of the Engine) are 20 years old. Most new games are overwhelmed with 64 Players. PS2 can handle…
Earlier quoted context omitted.
Pooling would have been more overhead than allocation + deallocation? Do you have any relevant readings? No idea how to do it in java but a few pointers ought to be enough. You can also omit clearing the memory area between allocations for things that aren't security sensitive, if that is done in java, which I would assume.
For short lived objects, heap allocation is probably about as fast as allocating on the stack. By pooling you can end up moving objects out of the fast eden space into older generations. I worked on optimising a java library a few years back and one of the bigger speed ups was removing all the object pooling code.
I know this isn't the point of Folia's test, but: > During the period when 1,000 players were online, we reached a maximum of ~7.9GB/s heap allocation and our GC was hovering around 2-3GB/s when averaged over a minute. As someone who dealt with soft-realtime telephony stuff, this makes me want to scream in horror. It seems like the platform really hurts the performance here. In an average second with that many player…
Do you think a minecraft server (and multiplayer game servers in general) can benefit for running on a soft-realtime OS like Linux with the PREEMPT_RT patch? Games often use their tick rate (iterations of the event loop per second) as a quality metric, and an rt OS should favor preemption and low scheduling latency over throughput... so maybe that should give a more fluid experience? But the bottleneck for minecraft…
This is interesting. I am interested in multithreading and parallelism. So I have a journal entry to explore which is about deliberately desynchronizing and resynchronizing game loops for performance. * For the number of clients can use epoll or liburing. * Can multiplex multiple sockets per thread my epoll-server does this. * Can split out recv and send across threads so you can send while receiving and receive whil…
> deliberately desynchronizing and resynchronizing game loops for performance. > latch on each thread for partial causality between game loops. This sounds like a recipe for misery. You have to start thinking about ""light cones"" if causality propagates at finite speed. Do all observers in the game universe witness events in the same order? What if they don't? You get a little bit of this with rollback netcode, on t…
Your comment made me amused because it made me think of a game world where retrocausality was in effect, it would be absurd.
Is the bottleneck for networked games the network of broadcasting updates? Or the CPU usage of updating object states?
Sharding or instancing means you have fewer clients to broadcast stream updates to.
Different game loops interacting with eachother, that's interesting.
How else do you scale a game engine across threads?
I know this isn't the point of Folia's test, but: > During the period when 1,000 players were online, we reached a maximum of ~7.9GB/s heap allocation and our GC was hovering around 2-3GB/s when averaged over a minute. As someone who dealt with soft-realtime telephony stuff, this makes me want to scream in horror. It seems like the platform really hurts the performance here. In an average second with that many player…
> In an average second with that many players, most (all?) of them will not do any action apart from changing their position The world is not static though. Each player loads in a lot of living entities (monsters/animals/...) and block entities (furnaces, redstone, ...) that all need to update. There's some overlap of course, though in a game like Minecraft where there's a near infinite world to explore that overlap…
There were 113 regions in one of the pictures- call it 9 players per region, with ~927 live unique chunks (8x8 chunks for 9 players ~=566, plus a 19x19 area around the world origin thats always loaded). From what I can tell a Minecraft block is a bit over 10 kB. So ~10 MB per region.
If each thread is allocating 10 MB for each region on each tick (which the screenshot shows is 8 ticks per second) *that would work out to 8.6 gigabytes per second*. IMO, that's too close to be a coincidence- I'm thinking there are a lot of shared chunks per region, but the threads are copying significant amounts of data by value or they just have an absurd overhead.
Earlier quoted context omitted.
> deliberately desynchronizing and resynchronizing game loops for performance. > latch on each thread for partial causality between game loops. This sounds like a recipe for misery. You have to start thinking about ""light cones"" if causality propagates at finite speed. Do all observers in the game universe witness events in the same order? What if they don't? You get a little bit of this with rollback netcode, on t…
Thank you for your reply. Your comment made me amused because it made me think of a game world where retrocausality was in effect, it would be absurd. Is the bottleneck for networked games the network of broadcasting updates? Or the CPU usage of updating object states? Sharding or instancing means you have fewer clients to broadcast stream updates to. Different game loops interacting with eachother, that's interestin…
Bit of both depending on precisely what's happening.
Ultimately the problem is that, for N "agents" (players or NPCs or active blocks or monsters, etc) in a space, if you're not careful you end up with O(N ^ 2) checks of the form "has X collided/interacted with Y". Octree systems can spread this out, but you're still vulnerable to "what if all the players go to the same spot?"
Instancing lets you back off the worst-case situation by limiting the maximum number of players in a particular spot.
I know this isn't the point of Folia's test, but: > During the period when 1,000 players were online, we reached a maximum of ~7.9GB/s heap allocation and our GC was hovering around 2-3GB/s when averaged over a minute. As someone who dealt with soft-realtime telephony stuff, this makes me want to scream in horror. It seems like the platform really hurts the performance here. In an average second with that many player…
Do you think a minecraft server (and multiplayer game servers in general) can benefit for running on a soft-realtime OS like Linux with the PREEMPT_RT patch? Games often use their tick rate (iterations of the event loop per second) as a quality metric, and an rt OS should favor preemption and low scheduling latency over throughput... so maybe that should give a more fluid experience? But the bottleneck for minecraft…