5 ms·

I spun it up on my server (an FX-8350) and it seems the load is higher than the stock server w/ a view distance of 24. Mind you I'm only running one realm (we

I spun it up on my server (an FX-8350) and it seems the load is higher than the stock server w/ a view distance of 24. Mind you I'm only running one realm (we really only stay on the default world) because it's just my ~8 person gaming group. It is continually surprising to me that there are all these reverse engineered minecraft servers yet none of them seem to provide a significant performance advantage within a single world. Cuberite, Glowstone, etc. They provide a notable boost when your machine is serving many worlds, but it seems most still use a single thread per world model. At least cuberite offloads chunk generation to a second thread, but in their own documentation they claim they don't want to support arbitrary levels of multithreading for fear it would hurt performance on anything less than a quad core. Even though this is a bit of a misconception, I don't understand why they wouldn't make such a thing configurable.

SolarNet 9y ago
It's a trade off, my understanding is that Glowstone's trade off is providing customization through APIs and mechanisms that will last. E.g. simplicity and power at the cost of performance. As an aside they make a claim that will be familiar to many lisp programmers. Their claim is by providing better power they will improve the average performance in the long run for their users (e.g. people who like lots of mods). Look at it this way, if you use horribly buggy edge cases to build flying machines that's going to take a ton of work for the server to simulate (minecraft flying machines often use tick perfect timings arrived at through - effectively - busy loops); if instead you used a mod that provided flying mechanics, and flying control blocks (e.g. that knew when to inject their logic) you would save a lot of performance. They may not be able to have the fastest server around, but given the things their users will use it for, theirs will probably be faster than those efficient servers in those cases.
- nly 9y ago
  Also, writing a plugin system that plays nice with threads is going to be a pita.
  - SpaceManiac 9y ago
    This is the big one. Glowstone was designed to be a native implementation of the Bukkit API (back when it was still on top), and I assure you that that API, and thereby every plugin built against it, makes some heavy single-threadedness assumptions. Even if you conceive an API from scratch, Java hasn't the tools to prevent plugin authors from doing things they shouldn't in this regard.

SolarNet 9y ago

It's a trade off, my understanding is that Glowstone's trade off is providing customization through APIs and mechanisms that will last. E.g. simplicity and power at the cost of performance. As an aside they make a claim that will be familiar to many lisp programmers. Their claim is by providing better power they will improve the average performance in the long run for their users (e.g. people who like lots of mods). Look at it this way, if you use horribly buggy edge cases to build flying machines that's going to take a ton of work for the server to simulate (minecraft flying machines often use tick perfect timings arrived at through - effectively - busy loops); if instead you used a mod that provided flying mechanics, and flying control blocks (e.g. that knew when to inject their logic) you would save a lot of performance. They may not be able to have the fastest server around, but given the things their users will use it for, theirs will probably be faster than those efficient servers in those cases.

nly 9y ago
Also, writing a plugin system that plays nice with threads is going to be a pita.
- SpaceManiac 9y ago
  This is the big one. Glowstone was designed to be a native implementation of the Bukkit API (back when it was still on top), and I assure you that that API, and thereby every plugin built against it, makes some heavy single-threadedness assumptions. Even if you conceive an API from scratch, Java hasn't the tools to prevent plugin authors from doing things they shouldn't in this regard.