Is Cuberite Multi-threaded? A short explanation.

[Greaper88]

Yes. But then again, so is the regular Java server. Let me elaborate on all of this.

Threads vs Cores
You will see "thread" and "core" used interchangeably, but what is the difference?
A thread is a single pipeline of instructions being executed. A core is a physical CPU core. Before multi-threaded processors, thread performance was core bound. While this is no longer strictly true, is still holds enough weight to not worry about this (IMO anyways).

Java Multi-threading
Java is multi-threaded, but it is so poorly implemented, you would be hard pressed to spot the difference if it wasn't. All worlds (dimensions are worlds) run on a single tick thread. All mobs and entities are also handled by this same thread. In fact, most anything involving the world and entities/players are on the tick. This is why you see/hear that singlethread performance is VERY important. The multi-threading comes into play for networking and garbage collection. These are insignificant for the CPU to handle however, so would appear as any of the other random activity you see on a CPU usage chart.

CubeRite Multi-threading
Cuberite starts out the box by not being written in Java, but rather C++ which is inherently faster. In fact, even if the code worked the same way as Java, it'd still be approximately 3x better in theory and handle accordingly. But it does do things a bit differently. Each world runs in a separate thread, network is handled in separate threads, world generation, saving and loading each gets a separate thread. This allows for a lot of optimization that grants more than just a 3x performance increase. Infact, a first gen Raspberry Pi can handle 8 players without much fuss. The software has been real-world tested with over 100 players without any performance loss software-side. I have personally had 450 console clients on a server with TPS dropping to just a stable 17.6 TPS.

[NiLSPACE]

This is a nice writeup, but it lacks sources and details. Do you have any sources to backup the claim that C++ is 3x faster than Java? And if you have a source, is there evidence that that speedup is the same if you compare other types of code? I have no doubt that most of the time C++ is faster than Java as it's AOT vs JIT, but claims like X is 3x faster than Y always make me sceptical.

Having 100 players or 450 players isn't a big deal if all clients stay in the same place and the view distance is low. Xoft gave a writeup on a worst case scenario when allot of people are online with no chunk overlap: https://forum.cuberite.org/thread-1888-p...l#pid19670 He gave the server the advantage that the viewdistance would be set at 4 chunks, which is really small. I'd say 8 chunks is the minimum for a nice experience which would mean instead of every player having 81 chunks around them they would have 289. In reality, there would be allot of chunk overlap, but it would only take one player who goes exploring and you have more 289 chunks in memory which have to be ticked.

Even if I'm a bit critical here, I do like these kinds of writeups. They explain how different Cuberite and the Java edition are in terms of their underlying architecture. I just think that the claims in the post should have sources to back it up and give more details on the benchmarks which were run.

[Greaper88]

This is a nice writeup, but it lacks sources and details. Do you have any sources to backup the claim that C++ is 3x faster than Java? And if you have a source, is there evidence that that speedup is the same if you compare other types of code? I have no doubt that most of the time C++ is faster than Java as it's AOT vs JIT, but claims like X is 3x faster than Y always make me sceptical.

Having 100 players or 450 players isn't a big deal if all clients stay in the same place and the view distance is low. Xoft gave a writeup on a worst case scenario when allot of people are online with no chunk overlap: https://forum.cuberite.org/thread-1888-p...l#pid19670 He gave the server the advantage that the viewdistance would be set at 4 chunks, which is really small. I'd say 8 chunks is the minimum for a nice experience which would mean instead of every player having 81 chunks around them they would have 289. In reality, there would be allot of chunk overlap, but it would only take one player who goes exploring and you have more 289 chunks in memory which have to be ticked.

Even if I'm a bit critical here, I do like these kinds of writeups. They explain how different Cuberite and the Java edition are in terms of their underlying architecture. I just think that the claims in the post should have sources to back it up and give more details on the benchmarks which were run.

I got that number from here, simple google search

https://www.forbes.com/sites/quora/2015/...er-than-c/

"As a rule of thumb, when you convert optimized C++ to Java, the code is about 3x slower."
"As a rule of thumb, when you convert Java to C++, the code is about 3x slower."

If this is true, then the inverse would be true as well.  In this case, the code isn't being "converted," but is in theory "optimized C++" code.

Maybe not the best reference to pull from, but I was just looking for a tangible number to use. The horrendous performance of the Java servers makes it easily believable too.


As for the 100 players, the entire world was force-loaded, and was the size of a LARGE lobby server, as it was used for an event.

[_XxFedexX_]

I thought C++ was faster than Java....
BUT even if it is much faster, the server stays at 16 TPS on Windows because of a bug...

[NiLSPACE]

Yeah, for some reason the sleep function isn't acurate on Windows. I think it's not that important though as long as it's consistent.