Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Testing a 1,000 player Minecraft server with Folia

cubxity.dev

Post reply on HN
Print view View original

151–160 of 166 posts

Re: Testing a 1,000 player Minecraft server with Folia

#151

Post by hu3 »

LeeroyWasHere wrote: post #99
lyu07282 wrote: post #72

Earlier quoted context omitted.

> Always fun to continue to see innovation within the Minecraft Java space. Just don't expect that innovation to come out of Mojang/Minecraft

Let's all remember that Notch didn't want any multiplayer and purposefully did everything he could to make it painful. Minecraft would be dead without the community devs and artists.

> Let's all remember that Notch didn't want any multiplayer and purposefully did everything he could to make it painful.

That's a big claim. Got a source?

Re: Testing a 1,000 player Minecraft server with Folia

#152

Post by Pannoniae »

kaba0 wrote: post #139
Pannoniae wrote: post #133

Earlier quoted context omitted.

Notchian code ran way better than modern MC - even though it used completely obsolete OpenGL 1.1 fixed-function calls. They've upgraded to OpenGL 3 and shaders now; but the game's memory and CPU usage is through the roof with inconsistent performance and huge lagspikes. Most of this is caused by utterly spurious and unneeded allocations; stream code on hot paths and complete overengineering and abstractions totally u…

Do you have any source for that? It seems questionable at best. Also, depending on where it is used, Java deals very well with indirect calls, it doesn’t have the same cost as, say, a C++ virtual call.

Source for which section? I am basing this on mostly my experience and codedigging - I don't think there are many written sources about observing this other than anecdotes on forums or reddit or whatever.

With that being said, I'm happy to investigate in detail if you can tell which parts you are interested in.

You are right, the JVM has many optimisations built in to de-virtualise calls and avoid allocations and the such, but if you abuse it, the JIT will give up. I don't think any JIT will de-virtualise or perform escape analysis on 5-6 layers of indirection with branching.

Re: Testing a 1,000 player Minecraft server with Folia

#153

Post by nottorp »

zimpenfish wrote: post #101
ghosty141 wrote: post #98

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.

> People on such big servers build farms ~Normally, yeah, but Folia is based on Paper which, AFAIK, is known for its unreliability when it comes to the technical aspects of Minecraft (ie redstone and farms.) Even your bog-standard simple item sorter is apparently a bit hit-or-miss on Paper.~ Edit: Possibly outdated info, things sound better re: technical Minecraft support on Paper now according to 'ocelotpotpie.

> Even your bog-standard simple item sorter is apparently a bit hit-or-miss on Paper.~

My simple sorters have been working just fine(tm) on Paper in the last (>5) few years.

I do hear co players having occasional problems with fancier set ups, but most automation just works.

Re: Testing a 1,000 player Minecraft server with Folia

#154

Post by nottorp »

josefrichter wrote: post #85

I know nothing about Minecraft servers, but has anyone tried to build one in Elixir/Erlang? Sounds like 1000 players should be a piece of cake.

It may run faster than java but it will have the same problems with close enough players having to be processed together in the same thread.

Re: Testing a 1,000 player Minecraft server with Folia

#155

Post by polski-g »

madduci wrote: post #122
viraptor wrote: post #38

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

I've tried different JVMs, different garbage collectors, etc, etc. They all make negligible difference.

Re: Testing a 1,000 player Minecraft server with Folia

#156

Post by intelVISA »

kaba0 wrote: post #138
intelVISA wrote: post #109

Earlier quoted context omitted.

Well, Java isn't really used for perf critical workloads to be fair.

Java is absolutely used for perf critical workloads, hell, I am fairly sure that there are no runtime in existence that would handle that load of memory pressure better - of course the problem is sort of self-made, not every allocation should have to be done in the first place in this case. But Java is heavily used in high-frequency trading, is the backbone of many cloud infrastructures and it is such a large platfor…

True, though in any competitive shop it's still second to C++, as they can afford it.

Re: Testing a 1,000 player Minecraft server with Folia

#157

Post by kaba0 »

intelVISA wrote: post #156
kaba0 wrote: post #138

Earlier quoted context omitted.

Java is absolutely used for perf critical workloads, hell, I am fairly sure that there are no runtime in existence that would handle that load of memory pressure better - of course the problem is sort of self-made, not every allocation should have to be done in the first place in this case. But Java is heavily used in high-frequency trading, is the backbone of many cloud infrastructures and it is such a large platfor…

True, though in any competitive shop it's still second to C++, as they can afford it.

Isn’t the niche where truly insane latencies are required absolutely dominated by ASICs and a general purpose CPU is way out of the picture?

Re: Testing a 1,000 player Minecraft server with Folia

#158

Post by winrid »

viraptor wrote: post #91
winrid wrote: post #68

Earlier quoted context omitted.

This is not an issue with the runtime. If anything, the JVM is handling this really well. The problem is code like: while(game_running) { position = new Box(x,y,z) } instead of reusing objects: while(game_running) { position.set(x,y,z) } plus, Minecraft is not static! There are many thousands of other things moving and changing state in the world.

> This is not an issue with the runtime Yes. But no. But yes. The code couldn't been written better to allocate less. But the runtime encourages cheap allocations you don't think about. But the runtime could provide/encourage tooling that makes it hard to make that mistake. But ... It all overlaps. Sure, JVM is cool and handles it, but also what JVM is influenced how people instinctively used it.

Most people don't write Java games this way. If you look at any libgdx code examples people cache objects and use polling - you don't know how modern a VM the user will have especially on Android.

Re: Testing a 1,000 player Minecraft server with Folia

#159

Post by intelVISA »

kaba0 wrote: post #157
intelVISA wrote: post #156

Earlier quoted context omitted.

True, though in any competitive shop it's still second to C++, as they can afford it.

Isn’t the niche where truly insane latencies are required absolutely dominated by ASICs and a general purpose CPU is way out of the picture?

I believe so

Re: Testing a 1,000 player Minecraft server with Folia

#160

Post by gjsman-1000 »

Kuinox wrote: post #143
ghosty141 wrote: post #98

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.

Thousands of items is small. Factorio doesn't need that amount of RAM when it routinely handle dozen of thousands of items every ticks.

Remember Minecraft is written in Java, not C++. The Bedrock version is written C++ but has only experimental, very rough native server software that is almost never used.
Post reply on HN